LabVIEW Real-Time Application Deployment

[johnnyLabVIEWlongtime]

The project is broken, missing VIs.

[KateA]

I am having a problem using the replication VIs creating an image of my CRIO  to my local host. It copied many log files from the CRIO, and seems to have created a copy of the directory structure, and then I get this error :

TCP Read in NI_InternetTK_Common_VIs.lvlib:TCP Read xTP Reply.vi:2
 ->NI_InternetTK_FTP_VIs.lvlib:FTP Get Command Reply.vi:1
 ->NI_InternetTK_FTP_VIs.lvlib:FTP Data Receive.vi
 ->NI_InternetTK_FTP_VIs.lvlib:FTP [RETR].vi
 ->Download RT File to Image.vi
 ->Get Target Image.vi
 ->RTcopy.vi->Image Replication.vi

(code 56).

Any thoughts on why this might be happening ?

[Burt_S]

Hello jBMW,

Have you installed all of the necessary dependencies for the source code?  If so, what VIs in particular are missing?

[Burt_S]

Hello KateA,

I don't think I've seen this behavior before, but I'd like to see if I can help.  Are you using the replication VIs directly or the RTAD Utility? Also, what are the network settings of both your target and your host PC?  Make sure that both systems are on the same subnet.  Finally, are any of the files copied over or is it just the directory structure that gets created?

[KateA]

Yes, some files were copied (323 .csv files). I don't know if all the files in the this log directory were all copied, since the system has since been updated and I didn't check it at the time). It just hung up for a little, and then reported the error.

[Burt_S]

Do you get the exact same behavior every time you try it?  What are the network settings for the controller and your computer?  Are you using the RTAD Utility or the deployment VIs?

[KateA]

Approx. the same, it just quits after about 200 files.

I was finally able to create an image without the startup.exe running. I think the server was being starved. I will plan on  using the NO APP switch in the future.

[Mads]

There should be a huge warning attached to the RTAD / System Replication Tools; "This might mess up the networking on your controller!"

I've just spent day and night for 1,5 weeks trying to figure out why one of two cFP-220 controllers would not boot up properly if it had both network ports connected, until I found that the netconf.ini file had been corrupted by the RTAD tool...and then I found the mentioning of a CAR ID #19078 in this thread: 

http://forums.ni.com/t5/Real-Time-Measurement-and/cRIO-with-scan-engine-System-Replication-does-not-...

Wow, that error has cost us a lot of money. 

What is the status of that disasterous bug? I believe I'm using the latest versions available so the error is still unfixed?

[JoshuaP]

Currious, when applying an RT image how do you expect the network settings to be handled? 

• Should we overwrite them with what is in the image
• Should we keep your targets current settings
• Should we keep your TCP/IP settings for your primary NIC, but overwrite the secondary NIC settings like EtherCAT with the ones in the image
• Something else?

[Mads]

Basically you should do whatever is necessary for system replication (not recreation on the same controller) to work.

Otherwise it will not be possible to automate the setup of multiple controllers, one of the main benefits of the replication tool - and certainly a feature necessary for anyone producing lots of NI-based systems.

In this case that would at least mean that MAC-address entries that were valid for the controller that the image was based on should be replaced with the corresponding addresses of the controller the image is being deployed to.

The source controller and the target are exactly the same model (cFP-2220, so the rest of the TCP setup is just fine. The user could be given the option to change these to a given set of values during deployment though, but there is a big difference between getting IP address collision issues that are easy enough to fix, and having corrupted MAC address references that cause abnormal and critical behaviour with hidden solutions...).

If the replication tool is unable to do this then RT itself should be made robust enough to correct and/or ignore invalid entries in the netcon.ini file.

Is the CAR I mentioned dead/declined?