Labview: Waiting for Real-Time target to respond

[masterwho]

Hello, I am now using compactRIO 9025 to do a project. I met a problem when I use NI 9871 to log data from an accelerometer, and also sometimes when I use other modules in FPGA mode.  A small window keeps coming out and saying 'waiting for Real-Time target to respond' during the running of my vi, as following

Could I ask is there any reason that make this happen? Could it be because I use the probe window to watch the data coming in?

Thank you very much for your help.

[JackDunaway]

You'll often get this message when the RT target has a very high CPU load (>90%).

I can't remember the exact menu, but there's a tool called something like "RT System Manager" under the "Tools" menu of the IDE. There are three tabs: on the second tab, uncheck something called "Track VIs", and on the first tab uncheck "Memory" and check "CPU Usage". Set the time interval between 1-5 sec. After you have deployed and are running your VI, once you click "Start Monitoring", a chart shows the distribution of tasks segmented by priority.

If you're able to complete my shoddy instructions (sorry!), report back on what the CPU usage is. I expect it will be pretty high, at which point we can start looking at code to determine how to decrease CPU utilization!

[Herlag]

Where is the "Real-Time System Manager" in LabVIEW 2010?!

It doesn't appear anymore in the "Tools" menu... (cf. RTSM_2010.GIF)

Is there something else to monitor the running VIs on a RT Target as "Real-Time System Manager" did? (cf. RTSM_8.2.GIF)

Thanx,

HL

[Wayne.C]

Herlag,

Pretty sure that tool is now called 'Tools>Distributed System Manager'.  Should show up directly under the Shared Variable.

[Herlag]

I've found the "Distributed System Manager"... but not how to monitor with this tool the VIs running on a RT target as "Real-Time System Manager" did - cf. RTSM_8.2.GIF in my previous message 😞

Any idea ?

HL

[Wayne.C]

Expand the network items and select the target.  You should then be able to select the VI States tab.

[kgolden]

Just a note on the distributed system manager: If the CPU load is 100%, you may not be able to connect to the RT target there either if you're using priority loops on the real time system and a priority thread is what is consuming the CPU. In fact, pings won't even come back if that's the case! This is because the RT priority is with the thread that's running and nothing else. 

If all else fails, reboot in safe mode and search for the thread that's taking all the CPU in your code (it's the one that has no delay in it and runs continuously without triggering a stop condition). If you still can't find it, there are VIs in the RT toolkit that report things like CPU usage. Place those in each priority loop and if CPU goes above 90%, have them write to a log denoting what thread they're in, the CPU use, and then have a trigger to exit the program so you'll be able to access the ftp on the RT device and be able to pull the log file.

[megu2013]

Hello,

I'm having the same issue with the lost of "real time target to respond". 

I already checked the CPU usage and it is not abouve 90% (it is around 80%).

I am using the cRIO 9074 to control the position of a servo motor with the module NI9505. I don't have the issue when I use small degrees values but if I increase the reference, I loose the comunication between the cRIO and the computer.

Any hint?

Thanks!

[Craig_]

This thread is really old and probably is reflecting a different issue than the one you are describing, could you make a new thread? People will be more able to assist you this way!