Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched. Close

Target, Webvisu Session Interference/Undesired Interactioins

rickj
4 days ago
2 days ago
  • rickj

    rickj - 4 days ago

    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:

    1. 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?

    2. Is there a workaround to prevent interference between sessions? Do you have examples?

    3. Is this an issue codesys will adress in a future version?

     
    • Fless

      Fless - 2 days ago

      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.

       
  • m.prestel

    m.prestel - 4 days ago

    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

    • 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?

    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

    • 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 4 days ago
  • rickj

    rickj - 3 days ago

    "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 3 days ago
  • rickj

    rickj - 2 days ago

    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:

    1. 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?

    2. How are screen variables VAR, VAR_IN_OUT, VAR_INPUT, and VAR_OUTPUT affected when the screen is called from a Frame element?

    3. Is it the case that only variables declared on the main screen (i.e. screens opend with "CHange Shopwn Visu")?

    4. 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?

    5. 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

     

Log in to post a comment.