Replication and Deployment Utility (RAD)

[fblerg]

Hi Efthymiou,

I don't believe that we capture that information by default with RAD. There is the Packet Detection and Polling Interval methods in the Hardware Property Node of the System Configuration API that allows you to change this setting. You potentially modify RAD and add in these methods. Pleas see below for more information.

What cRIO model are you using? 

Network Adapters: TCP/IP: Packet Detection

http://zone.ni.com/reference/en-XX/help/373107F-01/nisyscfg/property_node_hardware/

Property Node (Hardware)

http://zone.ni.com/reference/en-XX/help/373107F-01/nisyscfg/property_node__hardware/

[bargings123]

Hello Christian, 

Thank you for your quick reply. We are using the cRIO - 9074.

Best

[fblerg]

Hi Efthymiou,

I modified the Set Real-Time System Image shipping example to call the Packet Detection and Polling Interval properties after setting the system image. I was able to run the Set Real-Time System Image with Packet Detection VI on a cRIO-9074 and change the Packet Detection to polling. If you have an existing image, you can point the program at the image and set RT system images (you can also get a RT system image). This example doesn't implement the full features of RAD but would be a place to start using Packet Detection property.

[cgibson]

Hi Lucian,

I have the same issue you were having over a year ago with a cRIO 9038. Since we are looking at RAD for use by our technicians who may not have NI Max or any other NI tool, this is a showstopper for us.

When you look in the code there is a very clear spot were the cRIO is being forced into Safe Mode. The VI rad_ForceSafeMode.vi is called from the dynamically loaded rad_Deploy Image Wrapper.vi. The dynamically loaded VI is called in rad_Deploy Images in Parallel.vi, but the value that controls entering safe mode is set in rad_Deploy Images with Progress.vi, where it is hard coded.

I can't find the reverse code. I can't find a VI that undoes the safe mode setting and then writes it to the cRIO. I can't find where it would be called in the RAD application and I can't find an obvious opposite of rad_ForceSafeMode.vi

I am guessing that for Pharlap and vxWorks targets the safe mode is cleared by rebooting while in safe mode. But this is apparently not true for the Linux RT targets.

FWIW, I just tried the same utility on a 9074. The 9074 winds up in run mode when it is all finished. I think the 9074 has vxWorks, but certainly not the Linux RT.

So anyway, since your original post on this was a year ago, I assume you have since found a solution. Possibly you found the perfect spot to force the RT out of safe made right before the final reboot?

[LucianM]

Hi @cgibson

I have not found a solution to disable 'Force Safe-Mode' and didn't even bother to look inside RAD source code. I am now including a component definition file with my build and my clients use MAX to deploy on the cRIO (I made a small piece of code which copies the RT.exe files to the right location and starts MAX automatically). When the situation requires that an image must be written, the client uses MAX to unselect 'Force Safe-Mode' from MAX and performs another reboot.

Search for Building and Deploying a Stand-Alone Real-Time Application in LabVIEW help (Deploying from outside of the LabVIEW Development Environment section to find out more about component definition files).

Deploying using component definition file was an issue with cRIO 64bit Linux that seemed to be solved in LabVIEW RT 2015 SP1 so make sure you have this version or later before using this method!

Regards,

Lucian

[fblerg]

Hi cgisbon and Lucian,

The cRIO-903x booting into safe mode after imaging is a known issue that we are working on. cgibson is correct about the location where controllers are forced into safe mode. I believe that a potential fix is setting the ForceSafeMode System Hardware property node to false and rebooting after setting the device image (essentially adding the oppostie operation of rad_ForceSafeMode.vi section of code after the Set System Image.vi). This issue is limited to Linux RT Intel-based cRIOs. Linux RT ARM-based, vxWorks and Pharlap controllers are not affected. I will post more info once I have confirmed fixed for the issue. 

[cgibson]

Hi Frank,

I made a change to my version that seems to work. I am sure there is a better way to do this, but it seems to work for me.

I added a state in rad_Deploy Images with Progress.vi called "Check Safe Mode"

For each RT Deployment Target, this state opens a session, checks if safe mode is asserted for the target. If safe mode is true, then clear the safe mode state (by doing the opposite of the force safe mode VI) reboot and then close the session.

This state is inserted before exit, which means "Apply Network Settings Check" and "Reboot No Wait" states go here instead of exit. The state then calls "Exit" next.

In the attached snippet, I created a couple of VIs. One checks for safe mode and the other clears safe mode.

 

[QFang]

Perhaps my use case or workflow is different than most, but that difference lead me to have a persistent and perplexing issue for a looong time (years because it was never sufficiently important to get to the bottom of it).

If you feel you get unexplained errors (after reboot) on image deployment, or during image retrival, if you install the web interface but get an error message when you try to access the target in IE, if MAX will not let you adjust the time even thoguh you installed the appropriate software modules on the target; then ask yourself: Did I change or delete the root tmp folder and reboot the target?  -> If you did, you screwed the pooch. 

As part of my workflow to create "production" images, and sometimes as part of NI directed trouble-shooting tips of deployed targets, I remove/blacklist the c:\tmp folder.  For images, the reasoning was always that 'this folder is used for temporary system status files' and take up space and take up time both during retrival and deployment.. best to blacklist it so we don't suck it into the image we create, and during deployment, so we don't change/alter any error messages or tracelogs that may reside in the production target.  During trouble-shooting, the NI support reasoing was to clear out old error log and trace log files to more clearly show when/where things were going wrong on the target.. Turns out both are pretty bad reasons for messing with the tmp folder.

It turns out that THIS has been the issue of "all"(?) my strange "web interface worked in development but not after deployment with RAD" as well as "image deployment failed?" etc. etc.  It seems to also explain why I would get an error info code in MAX when I wanted to update date/time of a target, even though I had all the modules installed...

So, headsup everyone: The content of the c:\tmp folder is

a) critical!! to several modules,

b) not automatically and fully reconstructed or recovered if you remove the folder,

and c) Not temporary at all.

You have all been warned. 🙂

[SKauth]

@QFang: I want to add something to your confusion, which I actually share as well. I recently started using webservices, too, so now I end up with the webmethod VIs in /tmp after deployment. So if I want to create an Image, I need to copy /tmp/webservices manually. As I still consider a webinterface part of my application, I copied that to my project folder. So now LabVIEW sees conflicts, as i reuse subVIs of my main application in the WebMethods.

So what's the proper way of imaging a target with webservices?

[cgibson]

RAD and I have had a bad day. I have found 4 bugs in the course of trying to write documentation for our techs.

1. cRIOs (specifically the 9014 and 9074, but probably others) wth their network setting set so that the IP address is 0.0.0.0 fail to program if you select "Apply the Network Configuration Found in the Image" option in the Target Configuration Options dialogue. This dialog is available when you click the Target Deployment Settings button on the Deploy Application Images dialog.

The issue appears to be that the main VI responsible for deploying an image will not deploy to a cRIO with the all 0 IP address. This is awkward since that is how the older cRIOs come out of the box. The statemachine that handles deployment takes this into account *IF* you are applying a static IP address, but not if you want to apply the IP settings from the image.

This one looks rough. The obvious answer is to apply the image's IP address and details prior to doing the deploy, but these are not available in the various data structures. So you have to go find it in the appimage. Or maybe apply a temporary one. Of course find a temp address not on the network first. (I resolved this by storing the details in the appimage along with the other metadata.)

The workaround I have found that works is to deploy twice. The first time I set a static IP address via the dialog mentioned before. The second time I set the option to get the IP from the image. This works, but leads to issue 2.

Alternately you should be able to configure the IP from the top most panel using the Configure dialog.

2. It is possible to get the Deployment Targets table to list a target twice. How? Well if you deploy to the same target twice with different IP addresses, that appears to do it. I haven't looked at the code yet, but I suspect it has to do with using both the MAC and IP addresses as a key to a key/value pair lookup table. Change the IP address, get a new entry, even though it is the same device.

3. Maybe not really a bug, but certainly an issue. With the 903x cRIOs there is a type B USB plug that can serve as a way to communicate with the device. From my experience, this connector is the only way to work with a new out of the box 903x. So what happens if you are trying to run RAD on a PC that has not had the USBLAN driver installed? RAD will never see this brand new cRIO and there will be no indication why. It apparently is not straightforward to get just an installer for this driver as the formidible Altenbach recounts:

https://forums.ni.com/t5/Real-Time-Measurement-and/How-to-include-the-usb-lan-driver-with-an-install...

4. RAD displays a login and password prompt when a device it is trying to communicate with has been disconected. I found this out because after getting a list of available targets, I had connected my computer to another network. Not thinking about this, I tried a deploy and got the Login/Password prompt. Yes, I can't expect it to work in this case, but I can expect it to fail better.