AHMI appears to respond slower and slower over time

[Shark13]

I shared a copy of one of my solutions to the support email. Hoping someone else has an idea while I wait.

I have 2 nearly identical AHMI's running currently on our machines. When I open up the AHMI at the machines, everything works quickly and accurately with the response time one would expect. However, after being open for a week or longer for example, a delay starts to occur that appears to get worse the longer the AHMI is open. If the file is closed and reopened, everything works fine again. Any ideas? Has anyone experienced anything like this before? Almost seems as though the AHMI is retaining data over time and is being bogged down.

I'm running my AHMI on a Beckhoff IPC currently, and communicating to an older SLC 5/05 using the EthernetIPforSLCMicroCom driver.

[Archie]

Have you checked the Task Manager to see if the memory usage keeps growing?

[Shark13]

Task manager says 32.8MB on the application. If I close the application and reopen it starts at 17MB but climbs to around 20-21MB after loading.

[timryder]

Are you using all stock tools of the AHMI or have you written your own custom code which makes use of their libraries?
If you're using just standard controls then I don't really see how this can be an issue... if you have some customizations then you'll need to explain more.

[Shark13]

I identified the problem to be on the 3rd page of my quick tab display. Once I swapped to that page which was an I/O & Fault summary page with a lot of ahmi led indicators, the refresh rate slowed way way down. About a 7-9 second delay on refresh. I'm working through it now to narrow down the exact root cause. We tried using a 2nd coms instance just for that page alone, however the delay would still happen. I currently have that page disabled at the machines to not cause any issues, while I work through it.

[Archie]

Because of the nature of the SLC/Micro addressing, any time you use I/O addresses directly the driver is not able to optimize those reads. Once you display IO addressing, it will have subscribed to those addresses and increased the number of packets necessary to read everything.

One solution is to copy the IO addressing to a bit table and reference those bits in AdvancedHMI.

Another solution is to use a separate driver instance only for the IO addresses. For this to work, the DisableSubscriptions has to be set to True when the IO addresses are not being displayed. This is how multiple forms work when using the sample code snippet that is part of the default MainForm.