LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to safely shutdown a compactrio

Hi,

 

I have an application where a compactrio (sbrio 9636 actually) must shut itself down regularly. When the compactrio is not doing anything, it sends a message to an external microcontroller that will cut the power off and wait a certain amount of time before powering up the compactrio again.

 

However I do experience what seems like a corruption of the file system of the compactrio:

- my application does not boot on start

- the compactrio forgets every parameters I had configured (network configuration,...)

- the only solution to this situation is to redeploy my application

 

So I guess I'm doing something wrong when I shutdown the compactrio. 

 

Is there a recommended procedure for safely shutting down a realtime target? Isn't the compactrio supposed to be able to sustain power cutoff?

 

Best regards,

 

peper

 

 

 

 

0 Kudos
Message 1 of 10
(2,854 Views)

By "shutdown" do you mean exit the startup application?

0 Kudos
Message 2 of 10
(2,800 Views)

Yes, you should be able to unplug the RIO without losing your startup app. How are you detecting that your application doesn't start? You should get an error log that might be usefull. Can you create a simple application that does start reliably? Also, monitor the console to make sure there's no errors there.

0 Kudos
Message 3 of 10
(2,791 Views)

By shutdown, I basically mean removing the power cord from the compactrio.

In my application, the compactrio takes 1 measure every 1 hour and is shutdown between each measurement to save battery power.

 

I think I'm experiencing what is described in this white paper: http://www.ni.com/white-paper/6546/en/

" In rare occasions. shutting down abruptly can cause a FAT corruption, which in some cases can cause parts of the real-time OS or drivers to become corrupted."

 

However, the paper does not decribe what the safe shutdown procedure is. Do I just need to exit my vi?

Meanwhile, I'll check the error logs.

0 Kudos
Message 4 of 10
(2,765 Views)

This is the error log of my compactrio. I have a bunch of them in the "tmp" folder.Does this make sense to any of you?

 

####
#Date: TUE, NOV 29, 2016 08:53:49 AM
#OSName: VxWorks
#OSVers: 6.3
#OSBuild: Oct 30 2015, 09:50:40
#AppName: /c/ni-rt/system/lvrt.out
#Version: 13.0.1
#AppKind: AppLib


starting LabVIEW Execution System 1 Thread 0 , capacity: 24 at [3563254445.11839151, (08:54:05.118391577 2016:11:29)]
starting LabVIEW Execution System 1 Thread 1 , capacity: 24 at [3563254445.11839151, (08:54:05.118391577 2016:11:29)]
starting LabVIEW Execution System 1 Thread 2 , capacity: 24 at [3563254445.11839151, (08:54:05.118391577 2016:11:29)]
starting LabVIEW Execution System 1 Thread 3 , capacity: 24 at [3563254445.11839151, (08:54:05.118391577 2016:11:29)]
starting LabVIEW Execution System 6 Thread 0 , capacity: 24 at [3563254445.13303709, (08:54:05.133037210 2016:11:29)]
starting LabVIEW Execution System 6 Thread 1 , capacity: 24 at [3563254445.13303709, (08:54:05.133037210 2016:11:29)]
starting LabVIEW Execution System 6 Thread 2 , capacity: 24 at [3563254445.13303709, (08:54:05.133037210 2016:11:29)]
starting LabVIEW Execution System 6 Thread 3 , capacity: 24 at [3563254445.13303709, (08:54:05.133037210 2016:11:29)]
starting LabVIEW Execution System 16 Thread 0 , capacity: 24 at [3563254135.85030556, (08:48:55.850305712 2016:11:29)]
starting LabVIEW Execution System 16 Thread 1 , capacity: 24 at [3563254135.85030556, (08:48:55.850305712 2016:11:29)]
starting LabVIEW Execution System 16 Thread 2 , capacity: 24 at [3563254135.85030556, (08:48:55.850305712 2016:11:29)]
starting LabVIEW Execution System 16 Thread 3 , capacity: 24 at [3563254135.85030556, (08:48:55.850305712 2016:11:29)]
starting LabVIEW Execution System 21 Thread 0 , capacity: 24 at [3563254135.86350584, (08:48:55.863505645 2016:11:29)]
starting LabVIEW Execution System 21 Thread 1 , capacity: 24 at [3563254135.86350584, (08:48:55.863505645 2016:11:29)]
starting LabVIEW Execution System 21 Thread 2 , capacity: 24 at [3563254135.86350584, (08:48:55.863505645 2016:11:29)]
starting LabVIEW Execution System 21 Thread 3 , capacity: 24 at [3563254135.86350584, (08:48:55.863505645 2016:11:29)]
starting LabVIEW Execution System 11 Thread 0 , capacity: 24 at [3563254159.95296669, (08:49:19.952966582 2016:11:29)]
starting LabVIEW Execution System 11 Thread 1 , capacity: 24 at [3563254159.95296669, (08:49:19.952966582 2016:11:29)]
starting LabVIEW Execution System 11 Thread 2 , capacity: 24 at [3563254159.95296669, (08:49:19.952966582 2016:11:29)]
starting LabVIEW Execution System 11 Thread 3 , capacity: 24 at [3563254159.95296669, (08:49:19.952966582 2016:11:29)]
starting LabVIEW Execution System 306708506 Thread 0 , capacity: 1 at [3563254171.22827387, (08:49:31.228273965 2016:11:29)]
starting LabVIEW Execution System 306708507 Thread 0 , capacity: 1 at [3563254184.13569450, (08:49:44.135694267 2016:11:29)]
0 Kudos
Message 5 of 10
(2,744 Views)

@peper2001 wrote:

By shutdown, I basically mean removing the power cord from the compactrio.

In my application, the compactrio takes 1 measure every 1 hour and is shutdown between each measurement to save battery power.

 

I think I'm experiencing what is described in this white paper: http://www.ni.com/white-paper/6546/en/

" In rare occasions. shutting down abruptly can cause a FAT corruption, which in some cases can cause parts of the real-time OS or drivers to become corrupted."

 

However, the paper does not decribe what the safe shutdown procedure is. Do I just need to exit my vi?

Meanwhile, I'll check the error logs.


Yes, just exit your VI. This will leave the RTOS Idle and safe for power removal. You may get FAT corruption if you lose power during your VI execution and it is performing particular activities (eg. writing measurements to disk).

 

And there is nothing wrong in those logs.

0 Kudos
Message 6 of 10
(2,723 Views)

FYI, you don't have any errors there. You still might want to check the console. A simple way to check if you are being affected by the white paper would be to disable the measurement write and see if you have the same issue.

 

 

0 Kudos
Message 7 of 10
(2,715 Views)

I can understand that "pulling the plug" on your cRIO could leave the system in an unstable state.  What should be safe is to do the following (which is what I do for my RT systems):

  1. Determine that we want to turn the Remote System off.  In my case, we determine this from the Host, but if you are running a Headless System, it can also be determined by the Remote.
  2. Send the Remote a "Shutdown" command.  The Remote should respond to this by going through an orderly process that may include closing files, setting Hardware in a "safe" condition, saving (to disk) any configuration data that may be needed for the restart, etc.
  3. Get the Remote to do a System Reboot.
  4. In your case, you seem to have a Host program that controls the Power and is doing the timing.  When the Host tells the Remote to enter its ShutDown routine (which, as the above steps indicate, is really a "Shutdown and Reboot" routine), the Host can (and should) monitor the Remote to detect when it stops responding to TCP/IP requests, suggesting that the Shutdown is in progress.  This should be an indication that it is safe to turn off the power.  You may want to do a little experimentation to see if there is any critical timing here -- it may depend, in part, on how the Remote Software is written.

I'm assuming that your Remote Software is written as Deployable Software that runs as the Remote's Startup Routine, so that the mere act of powering on the cRIO will start its software running.  If this is not true, you might want to think about configuring it this way.  If you do, then (from the Host perspective) all you have to do to start it up again is have the Host turn its power back on.

 

Incidentally, this (minus the controllable Power to the Remote code) is how our RT system works.  When the Remote starts, it runs its RT code, which does a "Wait until the Host connects" (which, depending on circumstances, can take days or weeks).  Once the Host does connect, we have a working system and we do our tests.  When our Host program is ready to stop, it tells the Remote, which does the sort of shutdown described above, ending with rebooting itself.  The Host, in our case, doesn't monitor the Remote once it tells it to shut down, but instead does its own "program shutdown" and returns to Windows.  If we immediately restart the Host code (which the Remote is rebooting), we may have a 5-10 second "wait" while the Remote gets itself running again and can respond to the Host's Request to Connect, but so what?

 

Bob Schor

Message 8 of 10
(2,663 Views)

Hi,

 

If I understand you correctly, you are suggesting to initiate a software reboot of the crio and remove the power while the reboot process is on-going?

 

 

0 Kudos
Message 9 of 10
(2,643 Views)

I'd stand by what Bob_Schor and tyk007 said. 

 
I know that this module supports a low-power sleep mode. Support for sleep mode at the system level depends on the chassis that the module is plugged into.

 

 

If you're losing your network settings, you might want to double check your startup options in NI MAX. See p42 of the manual

 

http://www.ni.com/pdf/manuals/373378d.pdf

 

0 Kudos
Message 10 of 10
(2,618 Views)