Replication and Deployment Utility (RAD)

[Luke_W]

System Configuration 5.3.3 was released today and can be found here (or here for the run-time). This release fixed the above mentioned CAR. 

[Mads]

After upgrading to 5.3.3 the RAD utility no longer works. It gets stuck in the Discovering Targets stage (the initial automatic search for devices).

Debugging the application reveals that it all stops at the System Configuration API's Find.vi. It gets so stuck that stopping the calling VI will not do anything, the only way out is to terminate the LabVIEW process tree.

[Mads]

The above mentioned error might be related to the now retracted f2 version of LabVIEW 2012.

Installing System Configuration 5.3.3 on a computer running 2012 f1 works OK...

This side-effect of f2 does not seem to be documented anywhere though. Running a fix on the 2012 f2 installation does not resolve the issue.

[Burt_S]

I have used the RAD with 5.3.3 with LabVIEW 2010 and didn't see the behavior you mentioned.  Are you upgrading the RAD code to LabVIEW 2012 before running it, or does simply installing LabVIEW 2012 f2 cause this?

[Mads]

Seems to have been rather complex...It would freeze both in 2012f2 and 2011 after the installation of f2. Running a fix on 2012f2 from Programs and Features did not remove the issue, but installing RAD from the original installer posted here fixed it everywhere (the source code runs fine now in both 2011 and 2012f2). Perhaps 2012f2 touched a common component, and this component got fixed through the installation of RAD (the one distributed on ni.com, built in 2010?).

[MartinMeyer]

I have been trying to get RAD to work for a while now.  I am using LV2012f1, amc_2104_installer, rad_3001_installer, and have just installed syscfg533full.  I have been able to make images successfully but have not been able to deploy one yet.  (So maybe the images aren't so good either.)  I never installed f2 patch.

Originally I posted on this thread that I was having trouble with the deploy hanging while the status indicated it was enumerating files.  This appearred to be related to the ni-rt.ini file getting corrupted. 

With the updates I now get past the original problem, but I am still having an issue deploying.  The error message is attached.

I was working with NI tech support via email, but they have referred me back to the forum.  Any help would be appreciated.

[Sanjay_C.]

Hi Martin,

Luckily this is a known issue that was recently discovered. It so happens that the FPGA Flash Deployment VI's can't handle 2012 bitfiles. The easiest fix would be to download the source code for the RAD and navigate to the following directory in the project hierarchy:

RAD Source >> source >> subVIs >> App Images >> Deploy App Images >> RIOSystemReplication

In the RIOSystemReplication folder/hierarchy, you'll want to open and save the 5 VIs you find (technically, you only need two of them compiled for 2012 to make the fix, but to be safe, compile all 5 into 2012). The 5 VIs you'll be opening and saving are: Download Bitfile Dynamic, Download Bitfile, RIO Check, Set RIO Device Settings 2010, and Set RIO Device Settings Dynamic.

You should then format the target (in case you happen to have any corrupt files from previous attempts at deployment), take a new image using the 2012 source (after making the fixes, you can rebuild the EXE if you'd like), and deploy the image to the newly formatted target.

Let us know if something is still not working after following these steps. Unfortuanately, the VIs responsible for FPGA Flash Deployment need to be compiled for the version of LabVIEW that you are using.

[S1ack]

Installed this RAD utility today.

I see two problems.

1) Auto discovery fails: Error -2147467259 occurred at nisyscfg.lvlib:Find Systems.vi:1

Possible reason(s):

LabVIEW: (Hex 0x80004005) Unspecified error.
=========================
NI System Configuration: (Hex 0x80004005) Miscellaneous operation failure.

Complete call chain:
nisyscfg.lvlib:Find Systems.vi:1
rad_Get Target Info (Subnet) Wrapper.vi
rad_Refresh Target Information.vi
Replication and Deployment Utility.vi

I can manually add the targets, and RAD get's target info, and populates the Deployment Targets list.

I created image of my development rack (9074) to file: Reports success...

Dunno if this is relevant.....

My cRIO application uses the primary NIC as DHCP, and the secondary as static - non routable 192.168.1.xxx etc... My development laptop in my cube: RJ45 is local to that subnet, WiFi is DHCP'd to corp domain. The 'local' RJ45, cannot see corporate domain, as I get yelled at when I connect to many PLCs and cRIOs to the corporate WAN.

In any case, I tried disabling the wifi NIC, and refreshing the auto-discovery in RAD - still get the error.

2) Deployment failed on first attemt - neglected to get that code. I started the deployment again - and it reports success. 

However, the replicated rack has kept it's original secondary NIC IP address - I guess this is to be expected?

Labview 2011

RAD 3002 (rad_3002_installer.zip)

Runtime Engine 2012 (LVRTE2012f1std.exe, RAD did not seem to see this install, so I installed...)

Runtime Engine 2010 (LVRTE2010_SP1f5std.exe)

System Config Engine 5.3.3 (syscfg533runtime.exe)

Any ideas or suggestions greatly appreciated.

[Burt_S]

For problem 1, there was an older issue with the System Configuration driver where it would return error 2147467259 when it failed to discover any systems.  However I haven't seen this since before version 5.3.  I believe it attempts the discovery from the primary NIC.  It may be helpful to run a few tests with the Find VI selecting the 'Systems' polymorphic instance to see what gets returned.  It may also be worth a full install of the driver instead of just the runtime to see if that makes a difference.  As a workaround for the moment, you can simply disable the autodiscovery by going into Settings for the Target List and checking 'User Added Targets Only'. 

For problem 2, I don't know what to recommend for the deployment error without getting a specific error code, but it is possible that the issue is related to the discovery issue above.  As for the network settings, the RAD should deploy the same secondary NIC configuration found on the target that the image was created from.  For example, if you a retrieve an image from a target whose secondary NIC is configured as Static with 192.168.1.1, deploying that image to a different target should configure the secondary NIC with that same IP.  If you are seeing different behavior than this let me know.  If this is not the behavior you would like, it should be very simple to change by updating the image deployment VI in the RAD source code. 

[S1ack]

Thanks for the reply.

1. Yes I added it manually. I didn't download the source (which I beleive is what I'd need to investigate your Find.vi polymorphic instance suggestion)

2. My lone sample: the secondary NIC retained 192.168.1.4 despite being imaged from a file created with the secondary NIC as 192.168.1.9 (I could see this being the wanted behavior to avoid duplicate IPs on the subnet after imaging, and I can certainly live with it.).

I had some time to investigate RAD, and quickly verified it does what I need it to. If I have more time, I will investigate it further - but it's not time critical for me atm.