I have a navigation system where the main menu uses the "Change Shown Visualization" mechanism to switch screens. Each of these screens have a sub-menu that uses the Frame switching mechanism to switch sub-screen content. This used so that function block and other references can be passed to the selected screen.
The frame switching variable is declared as part of the main screen (i.e. the one displayed via "Change Shown Visualization") and is called Frame (for obvious reason). Navigation buttons simply write the desired frame number into the Frame variable. Ok, so far so good.
It has been recently discovered that all sessions, TargetVisu and WebVisus, apparently share the same variable space. The result is pushing a navigation button to select a different frame affects all sessions displaying the associated main screen. Clearly it's undesireable and unexpected thart one visualization session should have any affect on another. I have several questions regarding this issue:
We are using CrossControl XM controllers which run on SP9, and they have no intention of upgrading. Has the above issue been addressed in more recent versions and if so how?
Is there a workaround to prevent interference between sessions? Do you have examples?
Is this an issue codesys will adress in a future version?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The frame switching variable is declared as part of the main screen (i.e. the one displayed via "Change Shown Visualization") and is called Frame (for obvious reason). Navigation buttons simply write the desired frame number into the Frame variable. Ok, so far so good.
Instead of writing a frame switching variable. Try the action "Switch Frame Visualization" for each button. Use "Switch to any visualization" select your frame-element in your screen visualization and write the index of your sub-screen.
Then frame changes of different Visus should not interact.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think you are mixing some stuff up here, so I try to clear this up here:
Each input action is in itself client dependent
If you write on a variable with shared with all clients (e.g. GVL), it becomes client independent
For the input action Switch to visualization, if not configured (CURRENTVISU in the visu manager), this is client independent
Variables declared in a visualization are shared between all clients since there is only one instance of the specific visualization (disregard visualizations used in frames for now) --> Therefore you are writing to a variable shared variable
To your questions:
We are using CrossControl XM controllers which run on SP9, and they have no intention of upgrading. Has the above issue been addressed in more recent versions and if so how?
Since this is an application error, it cannot be addressed by a codesys update. You have to adjust the application. Even if, you would not have to update the runtime, just use a more recent codesys and a more recent visualization profile in most cases.
Is there a workaround to prevent interference between sessions? Do you have examples?
Is this an issue codesys will adress in a future version?
As said before I consider this an application error, therefore this cannot be adressed in the future.
Best regards,
Marcel
Last edit: m.prestel 2021-06-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"The correct way is to declare an ARRAY OF INT and use the CURRENTCLIENTID to write to a clientspecific index"
If I understand correctly, it's entirely up to us to provide and manage the context for each each session. It would be necessary for all frame interface variables (i.e. VAR_IN_OUT) to also be arrays. Upgrading screens for the current and future projects would be a non-trival task requiring significant effort. Can you confirm this is the case or otherwise opine on the subject?
It's difficult to understand how not providing and instance specific environment/context for each session (as has been common practice for half a century) is of any benefit to anyone or otherwise has merit. I suppose it would be interesting to hear an explanation, although I suppose unlikely.
Marcel, I do appreciate your tyimely response and your sincere desaire to help me and other forum members. Thank you very much.
Last edit: rickj 2021-06-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I appologize for showing my frustration in the previous post. My client is currently in the field comissioning the project and this is an inconvenient time to find out this issue.
I would like to learn more about this so I can evaluate how deeply the current project is affected. My concerns are as follows:
Coding ability within the context of a screen is very limited. How would the Frame element check CURRENTCLIENTID against the array's upper boundary? Where in the Frame element to put this code and what would/could it do when the boundary is exceeded?
How are screen variables VAR, VAR_IN_OUT, VAR_INPUT, and VAR_OUTPUT affected when the screen is called from a Frame element?
Is it the case that only variables declared on the main screen (i.e. screens opend with "CHange Shopwn Visu")?
Is there a way to set a max number of clients or is there a built-in limit? Is there a global variable containing the value of this limit?
Is there a document with all the details?
I hope you have a pleasant Sunday and I look forward to hearing from you on Monday.
Best Regards
Rick
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you got me there with an unlucky timing. I was on a extended vacation.
"If I understand correctly, it's entirely up to us to provide and manage the context for each each session. It would be necessary for all frame interface variables (i.e. VAR_IN_OUT) to also be arrays."
That depends completly on your project.
There are simply two options: My data is client independent My data is client dependent
By default every variable used is client independent.
Think of it like a GVL, there is only one GVL and therefore only one instance of a variable.
A frame is not that different from a normal visualization.
If you are using one variable in the visualization, you write the changed value to this specific variable and all clients updated to the new value.
So the question is what variables are independent and which arent.
"Can you confirm this is the case or otherwise opine on the subject?"
No I cannot since I dont know your project, your design considerations and what you are trying to display differently between clients
"It's difficult to understand how not providing and instance specific environment/context for each session (as has been common practice for half a century) is of any benefit to anyone or otherwise has merit. I suppose it would be interesting to hear an explanation, although I suppose unlikely."
The reason is pretty simply, it is memory consumption and data consistency.
Imaging an ARRAY [0..1000] OF ARRAY[0..1000] OF STRING(255) being declared in a GVL.
You want to display this array in a table using the frame interface.
If all variables would be automatically client independent, this would result in the following issues: You would have to allocate this array for each client dynamically, even if you are simply displaying the values without editing/changing them What to do if one clients writes a single value in the array? How do you merge it back into the GVL? Should or should you not update the other clients to the same value? How can you achieve any consistency?
At the end of a day, you are writing to one specific variable in your PLC. So the only right thing is to use use this specific variable all the way (that is also the trick with the CURRENTCLIENTID, it still writes to a specific variable, but the index differs between clients).
"Coding ability within the context of a screen is very limited. How would the Frame element check CURRENTCLIENTID against the array's upper boundary? Where in the Frame element to put this code and what would/could it do when the boundary is exceeded?"
If you check the example, there are two additional super global constants used, which you can use to declare your array.
The frame does NO additional checks in regards to the size of an array, it is simply an array index access for the element.
"How are screen variables VAR, VAR_IN_OUT, VAR_INPUT, and VAR_OUTPUT affected when the screen is called from a Frame element? "
To be honest I dont really understand the question.
"Is it the case that only variables declared on the main screen (i.e. screens opend with "CHange Shopwn Visu")?"
I think the issue for your project is, that you declared the variable in the interface.
As @Fless recommended, you could try not to use this variable.
I have a navigation system where the main menu uses the "Change Shown Visualization" mechanism to switch screens. Each of these screens have a sub-menu that uses the Frame switching mechanism to switch sub-screen content. This used so that function block and other references can be passed to the selected screen.
The frame switching variable is declared as part of the main screen (i.e. the one displayed via "Change Shown Visualization") and is called Frame (for obvious reason). Navigation buttons simply write the desired frame number into the Frame variable. Ok, so far so good.
It has been recently discovered that all sessions, TargetVisu and WebVisus, apparently share the same variable space. The result is pushing a navigation button to select a different frame affects all sessions displaying the associated main screen. Clearly it's undesireable and unexpected thart one visualization session should have any affect on another. I have several questions regarding this issue:
We are using CrossControl XM controllers which run on SP9, and they have no intention of upgrading. Has the above issue been addressed in more recent versions and if so how?
Is there a workaround to prevent interference between sessions? Do you have examples?
Is this an issue codesys will adress in a future version?
Instead of writing a frame switching variable. Try the action "Switch Frame Visualization" for each button. Use "Switch to any visualization" select your frame-element in your screen visualization and write the index of your sub-screen.
Then frame changes of different Visus should not interact.
Hello @rickj,
I think you are mixing some stuff up here, so I try to clear this up here:
Each input action is in itself client dependent
If you write on a variable with shared with all clients (e.g. GVL), it becomes client independent
For the input action Switch to visualization, if not configured (CURRENTVISU in the visu manager), this is client independent
To your questions:
Since this is an application error, it cannot be addressed by a codesys update. You have to adjust the application. Even if, you would not have to update the runtime, just use a more recent codesys and a more recent visualization profile in most cases.
The correct way is to declare an ARRAY OF INT and use the CURRENTCLIENTID to write to a clientspecific index
https://forge.codesys.com/prj/codesys-example/global-client-m/home/Home/ contains an example on how to use CURRENTCLIENTID
As said before I consider this an application error, therefore this cannot be adressed in the future.
Best regards,
Marcel
Last edit: m.prestel 2021-06-11
"The correct way is to declare an ARRAY OF INT and use the CURRENTCLIENTID to write to a clientspecific index"
If I understand correctly, it's entirely up to us to provide and manage the context for each each session. It would be necessary for all frame interface variables (i.e. VAR_IN_OUT) to also be arrays. Upgrading screens for the current and future projects would be a non-trival task requiring significant effort. Can you confirm this is the case or otherwise opine on the subject?
It's difficult to understand how not providing and instance specific environment/context for each session (as has been common practice for half a century) is of any benefit to anyone or otherwise has merit. I suppose it would be interesting to hear an explanation, although I suppose unlikely.
Marcel, I do appreciate your tyimely response and your sincere desaire to help me and other forum members. Thank you very much.
Last edit: rickj 2021-06-12
I appologize for showing my frustration in the previous post. My client is currently in the field comissioning the project and this is an inconvenient time to find out this issue.
I would like to learn more about this so I can evaluate how deeply the current project is affected. My concerns are as follows:
Coding ability within the context of a screen is very limited. How would the Frame element check CURRENTCLIENTID against the array's upper boundary? Where in the Frame element to put this code and what would/could it do when the boundary is exceeded?
How are screen variables VAR, VAR_IN_OUT, VAR_INPUT, and VAR_OUTPUT affected when the screen is called from a Frame element?
Is it the case that only variables declared on the main screen (i.e. screens opend with "CHange Shopwn Visu")?
Is there a way to set a max number of clients or is there a built-in limit? Is there a global variable containing the value of this limit?
Is there a document with all the details?
I hope you have a pleasant Sunday and I look forward to hearing from you on Monday.
Best Regards
Rick
Hello @Rickj,
you got me there with an unlucky timing. I was on a extended vacation.
"If I understand correctly, it's entirely up to us to provide and manage the context for each each session. It would be necessary for all frame interface variables (i.e. VAR_IN_OUT) to also be arrays."
That depends completly on your project.
There are simply two options:
My data is client independent
My data is client dependent
By default every variable used is client independent.
Think of it like a GVL, there is only one GVL and therefore only one instance of a variable.
A frame is not that different from a normal visualization.
If you are using one variable in the visualization, you write the changed value to this specific variable and all clients updated to the new value.
So the question is what variables are independent and which arent.
"Can you confirm this is the case or otherwise opine on the subject?"
No I cannot since I dont know your project, your design considerations and what you are trying to display differently between clients
"It's difficult to understand how not providing and instance specific environment/context for each session (as has been common practice for half a century) is of any benefit to anyone or otherwise has merit. I suppose it would be interesting to hear an explanation, although I suppose unlikely."
The reason is pretty simply, it is memory consumption and data consistency.
Imaging an ARRAY [0..1000] OF ARRAY[0..1000] OF STRING(255) being declared in a GVL.
You want to display this array in a table using the frame interface.
If all variables would be automatically client independent, this would result in the following issues:
You would have to allocate this array for each client dynamically, even if you are simply displaying the values without editing/changing them
What to do if one clients writes a single value in the array? How do you merge it back into the GVL? Should or should you not update the other clients to the same value? How can you achieve any consistency?
At the end of a day, you are writing to one specific variable in your PLC. So the only right thing is to use use this specific variable all the way (that is also the trick with the CURRENTCLIENTID, it still writes to a specific variable, but the index differs between clients).
"Coding ability within the context of a screen is very limited. How would the Frame element check CURRENTCLIENTID against the array's upper boundary? Where in the Frame element to put this code and what would/could it do when the boundary is exceeded?"
If you check the example, there are two additional super global constants used, which you can use to declare your array.
The frame does NO additional checks in regards to the size of an array, it is simply an array index access for the element.
"How are screen variables VAR, VAR_IN_OUT, VAR_INPUT, and VAR_OUTPUT affected when the screen is called from a Frame element? "
To be honest I dont really understand the question.
"Is it the case that only variables declared on the main screen (i.e. screens opend with "CHange Shopwn Visu")?"
I think the issue for your project is, that you declared the variable in the interface.
As @Fless recommended, you could try not to use this variable.
"Is there a way to set a max number of clients or is there a built-in limit? Is there a global variable containing the value of this limit?"
Limit is configured in the project using the maximum client number ("Maximum number of visualization clients" https://help.codesys.com/webapp/_visu_obj_manager;product=core_visualization;version=3.5.17.0)
"Is there a document with all the details?"
Which details are you talking about?
As explained there is an example available.
Best regards,
Marcel