Scan Engine power up time

[pjackson59]

We have supplied a customer with a Labview/cRIO system. There is a realtime program running with the Scan Engine, and a UI on the host.

Everything is working fine except for that they are observing very long powerup times, in the 2 minute range. In particular, after being powered off for several days, it take 4 minutes. Part of the time is because of the Ethernet extender modems which take 35-40 seconds to connect with each other.

I have ran some tests here, without the modems, and have observed that after applying power:

1. I can ping the controller after 5 seconds.

2. The system is operational after 35-40 seconds. This was measured both by the user interface being able to read Shared Variables, and the System manager reconnecting and reading Shared Variables. I let it sit overnight and this time went up to 50 seconds, so there does appear to be a correlation between how long it was powered down and how long it takes to power up.

I searched the NI forums but couldn’t find any discussion on this. Does anyone have any ideas?

[Roryriffic]

Hey pjackson59,

Quite a strange problem I must agree! Here's some of my ideas for you to try...

1) In the Distributed System Manager, navigate to the cRIO on the network.  Choose NI_SystemState >> Memory >> Available (you may also want to take note of the values for the other three variables there as well).  Notice that when you click on that a Trend Line appears on the right.  Leave this up and running overnight and check it in the morning.  If the trend line is going down, this means you're losing available memory and could have a memory leak in your realtime VI, which could effect startup time.

2) In MAX, find the cRIO under Remote Systems and click on the System Settings tab.  Under the System Monitor section, take note of the Free Drive Space.  If this value gets smaller and smaller over time, say dangerously close to no free disk space, then it's definitely possible it could be affecting start-up time. 

3) Ethernet communication is at the lowest priority on a real-time system.  That being said, if your real time VI is doing some hardcore processing, especially more and more as time goes on, then the CPU isn't going to publish data out the Ethernet port as regularly as it should be. This would explain why reading those shared variables takes a long time to update.

4) You could have a combination of the three things, in which case you'll probably (unfortunately) need to resort to some more intensive debugging and troubleshooting techniques - i.e. using the Real-time Execution Trace Toolkit

Rory