Replication and Deployment Utility (RAD)

[Mads]

I wanted to make a downscaled version of the deployment tool - to allow our support engineers and customers to simply select an image file and a target - and deploy. I've done this using the System Configuration API and it works fine, however I've run into a problem when trying to support the lvappimage-files generated by RAD. The lvappimage-files obviously have a different structure than the files generated by the "Get Image"-function on the SC-palette; but I'm extracting the sysimage-zip file, and use that file as the source for the "Set System Image"-VI.

This seems to work fine, the Set System Image-VI does not complain during the transfer, however when it restarts the controller at the end it ends up waiting a very long time - and then tell me that there was an error with the encryption password. Now as far as I can see in the RAD-code there is no encryption password...so why this error? I've noticed that the image generated by RAD contains one file that the Get Image-image does not; namely "nisyscfg.niauth.bin". The name of the file seems to indicate that it is indeed used to authenticate something...so perhaps that's where the error comes from?

It would be very nice to be able to support images that has been grabbed with RAD. Is there a way to get rid of the described problem?

The full error message is as follows:

Error -2147220369 occurred at nisyscfg.lvlib:Set System Image (Folder).vi:1

Possible reason(s):

NI System Configuration: (Hex 0x8004046F) The encryption passphrase when applying an image was not the same as when the image was created.

Complete call chain:
nisyscfg.lvlib:Set System Image (Folder).vi:1
nisyscfg.lvlib:Set System Image (File).vi:1
main_CSDT.vi

[JoshuaP]

The niauth file contains all of the user and permission information from the target that is typically only used with the web configuration and monitoring support when you point a web browser at the target.

In order for the Set Image to place the file you need to allow the Set Image to automatically reboot.  If that option is set to False you may get an error, because we can only deploy that file when the system is in run mode.  In addition, you may run into issues if you have already changed the admin password on the target, but didn't supply the admin user name and password when you called set image.

[Mads]

As mentioned the error comes after the reboot. There is a reboot prior to applying the image, and a reboot afterwards.

No admin password (or other passwords) have been applied. The image actually gets deployed fine, but the Set Image VI returns this error. I could just add code to ignore that error, and everything would run OK.

[JimMacD]

I have not used the RAD utility yet, but am considering it. This is what NI says about the tool in their whitepaper:http://zone.ni.com/devzone/cda/epd/p/id/5986#toc3

"Imaging is an effective tool for managing the software deployments of real-time (RT) targets.  However, building a robust application to automate application deployment and management of real-time targets with imaging APIs is not a trivial undertaking.  The Replication and Deployment (RAD) reference utility provides a turn-key solution for automated RT image deployment, replication, and management. It is built using functionality provided by the System Configuration VIs."

Now, from reading through this discussion board, it seems like there are a number of on-going issues with this tool. Is the general consensus that this tool is a robust and turn-key solution for imaging RT devices? If not, when is NI going to provide an easy to use solution for their products (and why is it taking so long).

[S1ack]

Been using Labview and cRIO targets for about a year. So I am a newb. And yet, using this tool I have succesfully made images, in effect cloning a rack, with much less hassle than whiping out MAX, installing the software payload, launching Labview, compiling, deploying, run as startup etc....

So yeah, in my opinion it's pretty turn key. I think I posted in this thread twice, and although I saw some errors that prompted those posts - the racks were cloned and worked fine.

[ePower-ahp]

Hi!

I am using sbRIO 9612 in an OEM application, and then I use RAD to do the initial setup of the sbRIO's. I also want to have the sbRIO locked as much as possible, no right to do anthing on the sbRIO without a password. 

It is possible automatically to setup the password and user right with RAD? -that would help me a lot

Thanks!

Anders Pedersen

ePower Technology ApS

Denmark

[Burt_S]

If you retrieve an image from a controller that is password protected, deploying that image to a new target will automatically apply the image's password settings to that target.

Attempting to programmatically interact with a controller that is password protected will throw an error unless the proper password is applied to the API functions used.  The RAD includes a feature that catches this error, and then pops up a password dialog.  Once a password is entered, the RAD will retry the operation using that password.  If the password is successful, the RAD will store it until the application closes so that it only needs to be entered once per session.  If unsuccessful, the password dialog will pop up again.

As a result, I believe the RAD will support your use-case.  Give this a try and feel free to post back on this forum if you run into any issues.

[JimMacD]

From the testing I have done, it appears that the RAD utility does not copy the users or passwords stored in the cRIO for logging on using NI-Auth (the web-based login system). Can anyone else confirm/deny this?

[ePower-ahp]

Yes, JimMacD, it was exactly what I experinted. And why I wrote, because the passwors settings was not copied with the image to the target. 

Does anybody have a succesfull way to have the user permission setting stored?

/Anders

[JoshuaP]

The new version of the RAD should do what you are asking.  Please make sure you are using the latest versions of the RAD and also ensure the controller you take the image from is in a normal running mode when you take the image with the RAD.  Also ensure the target isn't in user defined safe-mode when deploying the image.  It is fine if it is in safe-mode (no software installed).  

The reason for all of that is we can only get the username and passwords (NI-Auth) from a target via a protected web service when the target is in a normal running mode.  In addition, we can only transmit the NI-Auth stuff once the image has been transmitted and after the target boots up into a normal running mode.