11-28-2016 04:05 AM
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
11-28-2016 01:25 PM
By "shutdown" do you mean exit the startup application?
11-28-2016 01:47 PM - edited 11-28-2016 01:48 PM
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.
11-29-2016 02:26 AM - edited 11-29-2016 02:29 AM
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.
11-29-2016 06:34 AM - edited 11-29-2016 06:35 AM
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)]
11-29-2016 12:23 PM - edited 11-29-2016 12:31 PM
@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.
11-29-2016 12:39 PM
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.
12-04-2016 09:22 AM
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):
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
12-05-2016 08:03 AM
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?
12-07-2016 03:49 AM
I'd stand by what Bob_Schor and tyk007 said.
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