Real Time Executable starting time at Reboot on cRIO

[Sil3nc3r]

Hello,

I'm actually working with LV 2009 SP1 and Real Time and FPGA modules to develop on cRIO 9014 and 9024 controllers for CAN Bus applications.

I'm surprised by the cRIO executable starting time after reboot. I would like the sat the time between the status (orange, yellow) LED finish blinking and the first action made by the real time executable. To evaluate this time i just use the user LED turning ON at the starting VI initialization. The time between status LED OFF and user LED ON correspond to the starting time. For my own CAN Bus application i evaluate this time around 16 seconds on 9024 and 35 seconds on 9014 !!!

I tried to go further to investigate and i made simple executable that just turn ON/OFF the user LED alternatively each second.

You could understand even better looking at the block diagram below :

After deploying executable and reboot i could evaluate starting time around 9 seconds on 9024 and 16 seconds on 9014.

For information i made test with and without Ethernet link and results are the same i don't use scan engine but i installed CAN Frame Channel conversion dll.

So i have the following questions :

• Is there standard process that the executable not start instantly after reboot ? What happen between reboot and executable start ? (Loading drivers ? initializing something ?)
• Why the starting time aren't the same and depends on executable size ?
• Is it possible to correct cRIO configuration to improve starting speed ?

Hope someone could help me i really need the cRIO start as fast as possible !

[Sil3nc3r]

I just add some details

I just realized that it's not usual that the Status LED Flash yellow during 2 or 3 seconds ...

cRIO specification indicate it must be errors on controller configuration when status LED flash that way but the RT exe work really fine. I really don't understand why the status LED flash. Is there a link with the starting time ?...

I'm just still looking for explanation on starting time ... I really need my exe start just after cRIO boot.

[BenjaminR]

Hello Sil3nc3r,

Thanks for posting on National Instruments forum.

One possibility is that the OS takes a long time to come up find, load all the drivers, and find a network address, etc., before the actual RT EXE is started.

Here you will find the information about the Status LED flashing. What I can suggest you is to use MAX to reconfigure your cRIO, reinstall the software on the cRIO and download again you application (set to Run as start up).

Hope this helps,

[Sil3nc3r]

Thanks for tyring yo help me Benjamin.

But what is your opinion about the 9 and 16 seconds startup time to run a so simply LED Loop executable 9014 or 9024 ???

You surely could reproduce easily this kind of application and tell me if it's normal to wait such a long time before executable start running.

I'll try to re-install CRIO software and drivers. but i already did it before the previous test.

Hope you'll help me to find a solution. i would find sad that cRIO targets are so slow to start.

Romain F. | CLD

______________________________________________________________________________

PS : Tu peux me répondre en français si ça t'arrange.

[Sil3nc3r]

I tried to Install in cRIO various Software distributions to evaluate the impact on my simply LED Loop application.

I improved significantly the boot time using the minimal install configuration. Boot time around 3 seconds instead of 9 with complete usual one.

But it's still so much time to boot for a so tiny application.

And the bad news is that my CAN Bus application that needs NI Serial and CAN Frame to Channel conversion Library still start around 14 seconds after reboot with the lighter software installation.

I could conclude that the start time after reboot depend on :

- Software/Drivers distribution

- Size of the executable

My apps need to start really fast after boot ... where i could find a solution ?  maybe it just doesn't exist 😞 ...

[Sil3nc3r]

7 years later ... 

I tried the same test on cRIO 9033.

CRIO BOOT TIME  : 13,2 s

APP BOOT TIME : 6,8 s

TOTAL BOOT TIME : 20 s

My client ask me why devices as dSpace MicroAutobox could boot whithin few seconds and with cRIO you have to wait 20 seconds ! 

[CFER_STS]

Why are you rebooting your CompactRIO so often?  Embedded systems should be able to run for months without a reboot.

The FPGA program should begin executing very quickly after power-on, so if you need to have active control, output safe states, or other code active with minimal delay following a reboot, you should implement it there rather than in your real-time executable.

Rebooting, in general, clears device memories and performs a self-diagnostic on the hardware, looks up and verifies the device configuration (system settings, network settings, date and time), starts communication servers (like the shared variable engine, datasockets, WebDAV, etc) and then loads and executes the configured startup .rtexe file.

You might gain a bit of speed by configuring your cRIO target with a static IP address instead of using DHCP, and by eliminating resource intensive communication methods between the real-time target and your host.  The better solution though, is to look at why you are requiring reboots at all, and instead handle any required reset logic programatically without actually exiting your executable.  Reboots should be an exceptional event - not implemented purposefully by design. 

[Sil3nc3r]

The cRIO is used in automotive application.

You turn the key on you power up the cRIO.

You turn the key off you power down the cRIO.

The cRIO has too high power consumption to stay powered.

Maybe you just would like to say cRIO is not a good device for embedded automotive application ^_^.

[CFER_STS]

Depends on the application.  If you're trying to capture data immediately at power-on, then I'd look at implementing some data buffering on the FPGA, so you start acquiring data and outputting safe states etc. ASAP at power on, and then can process that data when the .rtexe finishes startup and comes online.  You might also look into using low-power "sleep" modes that may be available with your hardware, which will reduce the power consumption, enabling you to run in hot standby, and only actually powering down when the input battery voltage drops below some threshold.  I would also examine the possibility of using other inputs to trigger power-on (alarm disabled, door open, driver restraint connected, etc.) in advance of the ignition switch, which could save a few seconds.