08-31-2016 09:05 AM
I have spent some considerable time debugging a new application, after we decided to migrate it to new architecture. When most ordinary coding mistakes where weeded out, the application started running smoothly for short periods before suddenly freezing up to the point where connection to the RT target was lost.
I finally figured out that a subVI that returns system data (memory use, cpu load, etc) took so long to execute that the queue feeding that consumer loop filled up with tasks, eventually causing the memory to fill up. I did some testing of the subVI separately and noticed that "RT Get CPU Loads.vi" takes forever to execute the first time it's called after a target restart, and then executes quickly on subsequent calls.
Is this known behaviour? Any other ways to solve this, except calling "RT Get CPU Loads.vi" during initialization?
Solved! Go to Solution.
08-31-2016 09:34 AM
09-01-2016 02:07 AM
Thanks!
Your tips made me dive one level deeper into the system session node, where I found the necessary information.
The old .vi does not have a session in terminal, but based on its behaviour it seems like it initializes a session on its first call. I have eliminated that now, and will turn my subVI into an action engine that I can initialize during the overall initialization.
Necessary code to obtain CPU load in attached snippet. My old version used the shipped subVI that is available on the Real-Time pallette.