Now that I have the Modbus issue under control, I’ve moved on to the HMI side of things. I’ve set up a fairly simple screen with some LED icons, switches, and a bar-graph indicator. After a few minutes of running, the screen stopped responding. I tried to close it but it was unresponsive. Upon opening the task manager, I saw that the memory was almost maxed out (~98%). Stopping PAC Display from the Applications tab didn’t free up the memory, but killing the process returned the used memory to a more reasonable level (~44%). I fired PAC Display back up to verify the behavior, and sure enough, it started creeping back up. I took a screen shot just after killing the process (again) to show the behavior trend:
Is there something I should/shouldn’t be doing here? I found an issue with a memory leak related to tables of strings, but I’m not doing anything like that (as far as I know).
I’ll attach my code just as soon as I figure out how to manage attachments.
I’m sorry you’re having trouble with PAC Display. Sounds like something we’ll need to have our Product Support Group help you with. Most likely, they’ll need the archive of both your PAC Display project and your PAC Control project. In both programs, go to File > Archive Strategy and that’ll create a zip file will ALL the files needed.
You don’t happen to be running Windows XP SP 2, do you? Because there’s this known Windows issue (the fix is to get Service Pack 3). Besides that old issue w/tables of strings you mentioned, I’m not finding any other currently known memory leak issues that might be related.
I’m running Win7 Enterprise x64, SP1. I’ll get those zipped up and ready to go. I’m assuming that the support ticket that just showed up in my email is for this?
Will do. I was very pleased with the level of support I got on the Modbus issue, and was glad to see that it could be resolved in short order. I updated the first post in that thread, but couldn’t change the title to include “solved” at the front. Perhaps you could work some Super Moderator Magic on that one?
I think I did, thanks for that update. Not sure any super magic was involved, but I did seem to need to click the “Go Advanced” button to make the title and the message both show us as editable!
Well, it seems to be isolated to my laptop: tech support was unable to duplicate the “leak” on their hardware with my code, and a second workstation here also does not duplicate the error. Since the other workstation here is the deployment environment, I’m not too worried about getting it running on my laptop. That, and there are too many variables to isolate. I consider this one “unsolved” but still closed.
Looks like I spoke too soon: the leak is now showing up on the deployment platform. The task manager doesn’t show any process as consuming memory, but terminating the display runtime process immediately freed up over 1GB (yes, GIGAbyte) of RAM. The leak got that big in only about 20 minutes, so this isn’t something we can “live with” long-term. The other problem is that we are running Win7 Enterprise, which isn’t supported by Opto22. Not really sure where to proceed from here, but any input is welcome.
Please keep working with PSG. If the ticket has been closed, please email them and re-open it asap.
(The forums are more for brain storming than trouble shooting, PSG is way better set up for that sort of thing than the rest of us).
All that said, the only thing I can think of off the top of my head is that there must be something rather unique about your setup.
We have a LOT of customers running PAC Display and none of them have this issue… so to try and drill down and find the combo that is causing the issue is going to be…ah… fun, to say the least.
Are you using the URL window to view a video stream (IP camera or other) or web site?
Got any trends or data logging happening?
They are the two things that spring to my mind when looking for something that slowly gets bigger and bigger.
From your first screen shot, I see around 20% CPU, but it does not drop when pac display shuts down… Whats chewing up the CPU like that? Again, I’m thinking combinations of things that might be causing issues…
At this point I don’t plan to re-open the ticket, as the support tech I spoke with told me that they would not support any issues on Win 7 Enterprise (which is the deployment OS). If there is some exception or change to this policy, then I would consider re-opening it.
That said, I’ll try to answer your questions as best I can.
There’s no URL windows, trends, data logging or the like. Just images of buttons/switches from the library used to represent the discrete I/O points, and text/rectangles to represent the analog input.
The CPU usage is likely from running the HMI and whatever background stuff runs on my laptop. It’s getting a bit long in the tooth, and our IT has a lot of supervisory/maintenance/antivirus-type software installed. It normally runs around 15-20%, so it’s not unexpected. On the deployment target (shiny new i7 quad-core) the cpu usage is much lower, with only one or two virtual cores showing any real usage.
I took another swing at the HMI this morning and found something interesting: the analog input was configured as 8196 for the max value, but it’s reading a 13-bit input register (meaning the max value should be 8191) I don’t think that should matter for a 32-bit integer, but it’s a possible source of discrepancy.
I also deleted all of the analog input elements and replaced them with a single text field and rectangle. At this point, there is no more of the strange behavior with the HMI (no corrupted desktop graphics, no window spasm when clicking on the HMI, etc.) that was present yesterday. It doesn’t appear to be leaking memory anymore either, but I’ll hold back on claiming that it’s fixed (for now).
I do remember adding a trend widget to the HMI at some point before discovering the leak, but deleted it prior to the leak showing up. I don’t know if there could have been some leftover debris from the trend widget, but that may have influenced the problem.
Anyway, I’ll keep an eye on the problem and post any updates or solutions that I come across.
I hope you’ll report back what you find out!