Nixter (Customer) asked a question.
My customer is asking me to re-boot a CM5-T22W (f/w 9.01) HMI panel periodically to make the HMI panel more responsive. The HMI panel's response gets slower and slower with time and a re-boot fixes it (for a while). It's an ongoing problem and my customer asked me if I could put a re-boot HMI button on a maintenance screen so he doesn't have to keep asking me to re-boot it for him. I don't think a button object exists that would allow him to do that.
I have a few trend graphs in the HMI project. Could these trend graphs be the cause of the gradual slowing down that my customer is experiencing? I think they run in the background if they aren't currently being displayed.
I have read messages that indicate that event logging could cause a gradual HMI panel performance decrease, so I'm a little worried that the "slowing down" problem will worsen the problem if I add that to the HMI program.
Is there a list of potential causes of this type of performance slow-downs and a list of best-practices that will avoid or minimize it?
Your re-boot from the HMI question, one possible way could be to have an HMI button that turns off a PLC bit, that turns off a PLC output, that controls power to the HMI. After a time delay (to allow time to fully power-down the HMI), the PLC timer logic would turn on the output to power-up the HMI.
But of course you want to solve the real problem, and not re-boot the HMI.
When connected to the HMI with C-more software, review Connected Panel Information (>Panel >Panel Information). Does the error list or memory usages provide clues to the problem? This info will be helpful for tech support.
The Trend Data Logging Calculator in the Help files can calculate logging memory requirements.
Also, how is the HMI communicating with the PLC? Ethernet? Serial? Are other devices communicating on the same network as the PLC? Are other communication networks connected to the HMI? Any Remote Access connections to the HMI? This will also be helpful for tech support.
In our C-more projects, we have not experienced any of this HMI "slowing down". The only slow response problem we have experienced was with slow Remote Access on the remote computer side only.
It's good to hear that you have not experienced this gradual slow-down in response with your C-more projects.
I made a change that I think may have solved the problem (have to wait for a while to see if that is indeed the case). I had a number of trend graphs in the project with excessively large data buffers (close to 64k data points). As I have set up data logging in the StrideLinx Cloud, we don't need more than a few screens of data buffer size, so I have reduced the data buffer size considerably. What I suspect was happening was that as the large data buffers were being filled, it placed an increasing load on the HMI panel to shift the data inside the data buffers. At this point, I'm not sure that was actually the cause of the problem, but it seemed like a possibility and it was a quick and easy change to make.
To answer your questions: The HMI is communicating with the PLC via an Ethernet connection. Remote connections are rare, just when I connect over a VPN for a short time to see what is on the HMI screen. The slow-down is local to the equipment, as it is my customer who complained about it. Until my customer mentioned it, I was unaware of the issue.
Your analysis and your solution makes sense to me. Hopefully that will fix the problem. When we needed to log large amounts of data, we used local computers connected to the PLC using SCADA or Data Logging software. Most recently, we used the StrideLinx Cloud, as you are using. Unfortunately, ADC got out of the SCADA and Data Logging software business.
I initially set up the large data buffers in the HMI panel before I had the StrideLinx Cloud data logging set up... and then I forgot about it and didn't think about it until my customer complained about the gradual slow-down of the HMI panel over time. The complaint was recent because earlier on, I was downloading updated HMI programs to the panel fairly regularly. However, as the development nears completion, downloading of updated HMI programs became much less frequent and that allowed time for the data buffers to be filled and presumably affected the response time of the HMI panel. Hopefully, I solved the problem by greatly reducing the data buffer size for the trend charts.
I do have a RevPi Core SE (a DIN rail industrial form factor computer) in the control panel, but I haven't gotten to the part of the project where I will begin to program and use it as a local SCADA system and trouble-shooting tool. I intend to put the system manuals and drawings (PDF format) on the RevPi Core and provide access to them via a local web server - as a convenience for the maintenance department.
I'm finding the StrideLinx Cloud a very nice solution, both for myself as the developer and also for my customer.
Interesting how a number of factors, over time, came together to cause the problem. Good ideas to provide the customer with manuals and drawings, and local data logging. On one project we collected data on the HMI USB stick and the StrideLinx platform. That proved useful when they needed the data during the time the Stride connection was down. We also liked the StrideLinx for the easy, low-over-head setup and operation. Thank you for posting your solution.