Strange behavior from "RT Get CPU Loads.vi"; first call takes very long time!

[JarleEkanger]

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?

[Sam_Sharp · Accepted solution]

Does the VI have a 'session in' input? If it uses the system configuration VIs, it might need to create a session on first call which you can do outside of your loop. If not, and you have the system configuration toolkit installed, you could try using the property nodes from that to get the CPU - in more recent versions of RT, I think the function you are using is deprecated.

Can you post a snippet of your code / the VI?

[JarleEkanger]

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.