Factory Talk SE Using VBA - Memory Problem

Good morning everybody. I am having an issue with my computer memory running high and I was hoping someone has had a similar issue or knows a thing or two about using VBA in factory talk.

I have a display that has a list box control that shows vehicle data from Magnemotion. On the current line, there are about 60 vehicles with 6 pieces of data(Barcode, Vehicle Status, etc). I load in the data from the PLC into one tag group, filter out vehicles with certain conditions, possibly sort, then load only 30 into the list box depending on what index the user is currently at in the list box(I do this because loading 60+ seemed to cause the list box to flicker).

Currently, I have the tag groups to update every 2 seconds, which if a change has occurred the change event is fired and the updated data is brought in and repopulates the list box(one always has because the position on path piece of data is always changing by a millimeter even if the vehicle is still).

I have noticed, if the display is left open for a couple hours, the memory for that client begins to run very high. I have optimized the code as much as I can under the circumstances.

My questions: has anyone ran into this problem? What were your solutions? Is there some way to speed up this VBA. I am almost positive my code runs faster then 2 seconds, so I do not know why the VBA is falling behind or causing the memory to run high for that matter when that is the update rate of the tags.

EDIT: I should mention, we do this from the HMI, not the PLC, because the customer wanted sorting and other functions that did not seem possible from the PLC

I've never seen that, but it wouldn't surprise me to see a memory leak in FactoryTrash SE. What happens if you close and re-open the display? Is the memory recovered?

If so, just programmatically shut it down and re-start it after some time period.

rdrast,

no the memory continues to run high. I have to shut down the client and restart. I learned that the VBA in Factory Talk se is single threaded and events will get put in a queue if other vba code is running. So my best guess is the vba event sare getting so backed up in the queue.

However this raises two questions for me.
1) I am am almost positive my code for the change event completes faster then the 2 second tag update rate. Maybe I am wrong and just an awful coder.

2)Why is it the display client process and not the vba process in my task list showing such a high memory usage.

Are you using any trend?

nhatsen,

No I am not. I actually just had to look up what that was in factory talk.

My next plan is to try to write code that prevents the change event from firing if it is already running that change event. I will leave the screen up overnight and see what if it works.