It appears that if a WebVisu keeps the same page up for a number of days it will eventually "lose" some of the page's elements. I have not figured out if the root problem is with the Codesys Visualization or with the Chrome browser. For this reason I am looking for a way to trigger a refresh of a webvisu client if the WebVisu hasn't been navigated away from for some period of time.
If it possible to have the FBChangeVisu function (https://help.codesys.com/webapp/t6Wggu4AU17ivuxOCz5MhwO5thc%2FFbChangeVisu;product=VisuUtils;version=3.5.12.0) reference the "CurrentVisuName" parameter of the current client as it works through the client filter?
Is there a better way to cause a refresh of the WebVisu on a timer?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll check to see if the behavior is browser agnostic and then report if necessary. In the interim there is an issue that I need to work around. Is there a way to reference the "CurrentVisuName" parameter of the current client as it works through the client filter (VU.IVisualizationClientFilter)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is a snippet of my code used for an "auto return to home screen" function. It's based off the codesys "Key Switch Login" example project which is also attached. It's a bit challenging in that there is no session execution context making it necessary to first get a reference to the session, which is more complicated than necessary and sparsely documented IMHO.
Is the official stance to no longer use the method proposed by Rick/illustrated in the sample? Is there a sample project you could point me towards that accomplishes the same using visu utils?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As written it will refresh any client on that visualization page not just one with an extended duration. I would have to have a different custom filter for every visualization in the project. Prior to posting my question I already had a customer VisuClientIteration and ClientFilter based on your recommendation in this thread (https://forge.codesys.com/forge/talk/Deutsch/thread/f14041c158/?limit=25#9c5f).
Do you see any issue with implementing the custom Iteration with the HandleClient method doing the refresh?
Marcel, Just wondering, wouldn't all this be much easier to do if one could attach code at session/client, screen, and element levels as many other HMI systems do. For example, to create a client timeout one would just put a timer and a change screen command in a program having context/scope within a client. Same for screens and for elements.
It would make all the "not calling from visu task crashes" go away, would it not?
Anyway thank you for the help it is so much appreciated.
Rick
Last edit: rickj 2021-03-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The solution CODESYS followed was to use the common behavior model and do it this way.
In general I personally think that if you can get the instance path to a variable, someone will simply read/write to it, because it is a quick solution.
Most people are not aware of multi tasking/threading issues.
Best regards,
Marcel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It appears that if a WebVisu keeps the same page up for a number of days it will eventually "lose" some of the page's elements. I have not figured out if the root problem is with the Codesys Visualization or with the Chrome browser. For this reason I am looking for a way to trigger a refresh of a webvisu client if the WebVisu hasn't been navigated away from for some period of time.
If it possible to have the FBChangeVisu function (https://help.codesys.com/webapp/t6Wggu4AU17ivuxOCz5MhwO5thc%2FFbChangeVisu;product=VisuUtils;version=3.5.12.0) reference the "CurrentVisuName" parameter of the current client as it works through the client filter?
Is there a better way to cause a refresh of the WebVisu on a timer?
It would be best if you are able to reproduce the issue and then report it!
Marcel,
I'll check to see if the behavior is browser agnostic and then report if necessary. In the interim there is an issue that I need to work around. Is there a way to reference the "CurrentVisuName" parameter of the current client as it works through the client filter (VU.IVisualizationClientFilter)?
Implement your own IVisualizationClientFilter.
Accept will be called with IVisualizationClient, which contains the property CurrentVisuName
Here is a snippet of my code used for an "auto return to home screen" function. It's based off the codesys "Key Switch Login" example project which is also attached. It's a bit challenging in that there is no session execution context making it necessary to first get a reference to the session, which is more complicated than necessary and sparsely documented IMHO.
Please use the visu utils and not .BeginIteration()
Marcel,
Is the official stance to no longer use the method proposed by Rick/illustrated in the sample? Is there a sample project you could point me towards that accomplishes the same using visu utils?
GetNextClient will produce a warning starting with SP17.
The problem is simple, most of the users access visu data outside of the visu task resulting in possible crashes.
Marcel,
As written it will refresh any client on that visualization page not just one with an extended duration. I would have to have a different custom filter for every visualization in the project. Prior to posting my question I already had a customer VisuClientIteration and ClientFilter based on your recommendation in this thread (https://forge.codesys.com/forge/talk/Deutsch/thread/f14041c158/?limit=25#9c5f).
Do you see any issue with implementing the custom Iteration with the HandleClient method doing the refresh?
In this case the IsAccepted method of the ClientFilterTargeted is checking
Again it would be way better for you to reproduce and report the issue.
Thanks Marcel and rckalex for all the info.
Marcel, Just wondering, wouldn't all this be much easier to do if one could attach code at session/client, screen, and element levels as many other HMI systems do. For example, to create a client timeout one would just put a timer and a change screen command in a program having context/scope within a client. Same for screens and for elements.
It would make all the "not calling from visu task crashes" go away, would it not?
Anyway thank you for the help it is so much appreciated.
Rick
Last edit: rickj 2021-03-27
The solution CODESYS followed was to use the common behavior model and do it this way.
In general I personally think that if you can get the instance path to a variable, someone will simply read/write to it, because it is a quick solution.
Most people are not aware of multi tasking/threading issues.
Best regards,
Marcel
Yes, examples would be very helpful.