I'm having a bit of a struggle finding settings that will reliably maintain a connection between the webvisu and a touchscreen client. Every so often the HMI disconnects and will perpetually display the red spinning arrow with the "Error Happened, Will resume automatically" text. Power cycling the HMI to force a reconnect will re-establish comms. It seems to happen during periods of inactivity if that's a clue.
From what I've gathered so far this seems to have something to do with the webvisu update rate, buffer size as well as the visu task scan rate. We first tried the default settings as follows:
Webvisu Update Rate: 200 ms
Webvisu Buffer Size: 50,000
Visu Task Scan Rate: 100 ms Priority 31
Other Tasks for Reference:
Main Task Scan Rate: 100 ms Priority 1
Alarm Manager Scan Rate: 50 ms Priority 31
Ethercat Task: 4 ms Priority 1
This would disconnect some what regularly. We then made the following changes to try and stabilize:
Webvisu Update Rate: 150 ms
Webvisu Buffer Size: 75,000
Visu Task Scan Rate: 75 ms
Kept other tasks the same.
This seems to disconnect even more frequently. Also for reference the network is very small and only consists of the PLC, a small switch and the HMI. We're also not controlling frames from outside the visu program itself. The frame changes are all done natively.
Any suggestions to get this to stop disconnecting? Oh and whatever the issue is the log does not record it.
Figured I would ask here before opening a ticket.
Thanks in advance for your help!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We have seen this kind of thing before. I have two questions:
1. What kind of HMI are you using?
2. When this happens, are you able to connect using https, on port 8089?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The HMI is pointed to the URL which is assigned through u-OS. Basically when you log into the controller's webserver via browser you can view the installed apps. One of which is the Codesys runtime. When you click on that it takes you to the visualization. That corresponding url is what the HMI is looking for. I apologize I don't have that on hand as I'm in the office right now.
I don't think I tried connecting using the port you mentioned and https in lieu of the u_OS URL. I can certainly try. Out of the box the u-OS is set for HTTP. Since we're isolated I havent changed that yet.
When this has happened while logged on via chrome on my laptop, simply refreshing brings the visualization right back. In the case of the HMI in kiosk mode, we power cycle the HMI to force a reconnect, log back in u-OS and the visualization is back.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok, that's different than our issue then. We're using Schneider Electric M262 PLCs, and we've had it where certain web browsers cause the web server to only allow https connections, but it's not recoverable with a refresh. It usually requires a power cycle or even a full firmware flash.
Your issue might have more to do with the timing. I don't know if it helps you, but we normally run our visu task at 200mS, with an update rate of 200mS. Seems to work. I went through this: https://faq.codesys.com/pages/viewpage.action?pageId=112525371 but it really seems like trial and error.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ohhh OK. Yeah this seems to be timing like you said. Yeah I read through that document and came to the same conclusion. I haven't tried setting them both to 200ms. Maybe I'll give it a shot. Thanks so much for your input. Its greatly apreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey Everyone,
I'm having a bit of a struggle finding settings that will reliably maintain a connection between the webvisu and a touchscreen client. Every so often the HMI disconnects and will perpetually display the red spinning arrow with the "Error Happened, Will resume automatically" text. Power cycling the HMI to force a reconnect will re-establish comms. It seems to happen during periods of inactivity if that's a clue.
From what I've gathered so far this seems to have something to do with the webvisu update rate, buffer size as well as the visu task scan rate. We first tried the default settings as follows:
Webvisu Update Rate: 200 ms
Webvisu Buffer Size: 50,000
Visu Task Scan Rate: 100 ms Priority 31
Other Tasks for Reference:
Main Task Scan Rate: 100 ms Priority 1
Alarm Manager Scan Rate: 50 ms Priority 31
Ethercat Task: 4 ms Priority 1
This would disconnect some what regularly. We then made the following changes to try and stabilize:
Webvisu Update Rate: 150 ms
Webvisu Buffer Size: 75,000
Visu Task Scan Rate: 75 ms
Kept other tasks the same.
This seems to disconnect even more frequently. Also for reference the network is very small and only consists of the PLC, a small switch and the HMI. We're also not controlling frames from outside the visu program itself. The frame changes are all done natively.
Any suggestions to get this to stop disconnecting? Oh and whatever the issue is the log does not record it.
Figured I would ask here before opening a ticket.
Thanks in advance for your help!
We have seen this kind of thing before. I have two questions:
1. What kind of HMI are you using?
2. When this happens, are you able to connect using https, on port 8089?
Thanks So Much for the reply!
ok, that's different than our issue then. We're using Schneider Electric M262 PLCs, and we've had it where certain web browsers cause the web server to only allow https connections, but it's not recoverable with a refresh. It usually requires a power cycle or even a full firmware flash.
Your issue might have more to do with the timing. I don't know if it helps you, but we normally run our visu task at 200mS, with an update rate of 200mS. Seems to work. I went through this: https://faq.codesys.com/pages/viewpage.action?pageId=112525371 but it really seems like trial and error.
Ohhh OK. Yeah this seems to be timing like you said. Yeah I read through that document and came to the same conclusion. I haven't tried setting them both to 200ms. Maybe I'll give it a shot. Thanks so much for your input. Its greatly apreciated.