topic Re: LabVIEW Real-Time Application Deployment in Components

Replication and Deployment Utility (RAD)

Christian_L — Wed, 12 Feb 2025 02:05:42 GMT

Note: The reference design was previously called LabVIEW Real-Time Application Deployment (RTAD).

This thread is intended for discussion and feedback regarding examples, functions/VIs, and tools for deploying LabVIEW RT applications to different targets systems including PXI, CompactRIO, and Compact FieldPoint. If you have any feedback, suggestions, or questions on this topic, please post them here.

One current set of functions available for RT application deployment are the RT System Replication tools.

I am currently developing a reference design and turn-key utility for RT application deployment and will post a beta version in this thread to receive feedback. In the mean time if you have a list of requirements for such a tool, please post them here.

Re: LabVIEW Real-Time Application Deployment

Armen — Mon, 28 Jul 2008 07:49:07 GMT

Hi,

My RT application runs in compact FieldPoint. It has 3 loops: low priority, high priority and client-server communication loop to send and receive data with host PC. It also have remote panel server, to see the front panel from network. It works perfectly when I start it from project. We have all data on host computer. But when I create an executable to run from start-up, I still see and control my application on network, but communication is broken. I suspect that need to set special settings in build specification. The application itself is okay, I have checked it many times. Any hint and help would appreciate

Re: LabVIEW Real-Time Application Deployment

Christian_L — Mon, 28 Jul 2008 14:29:06 GMT

Hello Armen,

Your question is better suited for the general LabVIEW support forum. Please repost it there. I would encourage you to include some of the code, especially the communication loop if that is the piece that isn't working. Since you can access the front panel of the RT application usding Remote Panel, you can also display more debugging information on the front panel that tells you more about what is going on in the communication loop.

This forum is designed for discussion on the tools referenced above and in the future, specifically automated tools for deploying RT applications. For these tools we assume that you have a working RT executable application.

Re: LabVIEW Real-Time Application Deployment

dwisti — Mon, 28 Jul 2008 17:25:28 GMT

I use the Real-Time Target Replication tools quite often. My company is an OEM and the end user does not have Labview or MAX. Without the replication tools, this would not be possible. However, I've run into one situation where my end user is stuck. If they have a hard drive failure, they must format and install with the Desktop PC Utility USB Drive. How can my customer create the Desktop PC Utility USB Drive?

Re: LabVIEW Real-Time Application Deployment

Christian_L — Tue, 29 Jul 2008 16:28:58 GMT

David,

I think you may have already received your answer from the PSE through your local sales person. Here's a summary for the forum.

The end customer can not directly create the necessary USB drive as the code for it is part of MAX and the LV RT installation on the development machine. Options include:

1. Create the USB drive on the development machine and ship the USB drive to the customer.

2. Create the USB drive on the development machine. Then zip up the contents of the USB drive and e-mail the ZIP file to the customer. The customer must format their own USB drive to be a bootable drive. Then they will place the contents of the ZIP file on the empty USB drive. Now they have a bootable USB drive to start their PC in RT.

Re: LabVIEW Real-Time Application Deployment

dwisti — Wed, 12 Feb 2025 02:06:07 GMT

Christian,
Thanks for the response. When we deploy RT systems we purchase a deployment license for standard PC's ETS(RTOS) NI Part #777849-03. Inside this product is a CD, National Instruments Real-Time Target Software v2.1 which allows you to install MAX and the ability to create the bootable USB drive utility. However, it only supports up to Labview 8.2. Why doesn't this CD support 8.5.1? What is the purpose of this CD?

David

Re: LabVIEW Real-Time Application Deployment

Riconquistiamola — Wed, 12 Feb 2025 02:06:42 GMT

Hi David,

The TargetCD was a tool for installing Real-Time software on targets from a host that does not have the LabVIEW Real-Time Module.

In version 2.1 and previous, the LabVIEW Real-Time Target Software CD contained the necessary embedded software to run LabVIEW Real-Time on any National Instruments real-time controller. The purpose of this CD was so our end-user RT customers that may not have the LabVIEW Real-Time development software could still have the embedded software to be able to reinstall RT to the target. The CD installation allowed a customer to choose which target they are using and which version of LabVIEW Real-Time. The software was installed on the host computer and then could be installed to the target through MAX as if the LabVIEW Real-Time is installed.

Version 2.2 (for LabVIEW Real-Time 8.5) no longer has this functionality. The updated purpose of the CD is to provide older LabVIEW Real-Time version support for newer controllers, which would be unnecessary to ship with a deployment license.

The reasoning for the change is if someone were to require the ability to install Real-Time software to a target without installing the LabVIEW Real-Time Module, we would recommend the Real-Time Target System Replication Toolkit. The VIs can be built into an executable (or installer with the LabVIEW RTE) and provided to your an end-customer with a customized imaging process.

Cheers.

Message Edited by Riconquistiamola on 07-29-2008 02:09 PM

Re: LabVIEW Real-Time Application Deployment

dwisti — Tue, 29 Jul 2008 20:08:37 GMT

Maybe I'm missing something... Real-Time Target System Replication Toolkit can apply an image to an unconfigured target. Unconfigured target meaning the Labview real time bootloader is running in that target. How can the Real-Time Target System Replication Toolkit install the bootloader onto a brand new harddrive? My end-user RT customers do not have the LabVIEW Real-Time development software but still need to be able to reinstall RT to the target.

Re: LabVIEW Real-Time Application Deployment

Riconquistiamola — Wed, 30 Jul 2008 14:44:34 GMT

Hey David,

You are correct System Replication cannot format a new HDD.

In that case you could ship your end customer a Desktop PC Format Hard Drive Disk or Desktop PC Utility USB Drive instead of providing them the TargetCD.

Cheers.

Re: LabVIEW Real-Time Application Deployment

dwisti — Wed, 12 Feb 2025 02:07:23 GMT

When you go to the download link for LabVIEW Real-Time System Replication Tools it says:

LabVIEW Real-Time Module for PharLap -- System Replication Tools

But these tools work for VxWorks targets too? I been using them with VxWorks for some time know and just want to be sure this is a typo on the website.

Re: LabVIEW Real-Time Application Deployment

Jason Stallard — Fri, 03 Oct 2008 15:08:12 GMT

I have been trying to use the example replication utility under labview 8.6 against a cFP-2220 which used the Vx-Works OS and the took keeps locking up my PC at random places. I'm beginning to doubt the current version of the replication tools actually support VxWorks.

Re: LabVIEW Real-Time Application Deployment

Christian_L — Mon, 06 Oct 2008 21:33:14 GMT

Jason,

The RT System Replication tools do work with the VxWorks targets, as well as Pharlap. I just tested the tools in LabVIEW 8.6 with a cFP-2220 controller without any issues. The Get and Set Target Image VIs do take several minutes to complete. If you call one of these VIs they will not respond for a few minutes and it may seem that the computer is locked up.

Re: LabVIEW Real-Time Application Deployment

Jason Stallard — Tue, 07 Oct 2008 11:52:28 GMT

Yeah, I just confirmed this with application engineering yesterday, and since this post my PC has locked up in other situations like when using MAX or running in the development system with the controller targeted. I'm now thinking my problem is other than the replication tools.

回复： Re: LabVIEW Real-Time Application Deployment

hathello — Mon, 13 Oct 2008 01:45:13 GMT

christian,
thank you for your wonderful job to make this useful tool.There are some issues when i'm using it.I have tried the tool on three types of RT target.they are PXI-8196 with RT,cfP-2120,cRIO-9014,cRIO-9004.I just used replication.vi to replicate RT target to my host PC and the result is that all of them except cRIO-9004 can not be replicated.I wonder if there are some special requirements that i don't know?like the type and version of RTOS,the network safty software (firewall,Rising)and so on?
PS:

Controller Series     RTOS
cFP-21xx             PharLap ETS
cRIO-900x             PharLap ETS
PXI[e]-81xx             PharLap ETS
cRIO-901x             VxWorks

Re: 回复： Re: LabVIEW Real-Time Application Deployment

Jason Stallard — Mon, 13 Oct 2008 12:27:08 GMT

I finally narrowed down the PC lockup to the firewall running on my system (zone alarm). After disabling the firewall, everything worked fine targeting a cFP-2220.

Re: 回复： Re: LabVIEW Real-Time Application Deployment

Christian_L — Mon, 13 Oct 2008 20:22:31 GMT

hathello wrote:
christian,
    thank you for your wonderful job to make this useful tool.There are some issues when i'm using it.I have tried the tool on three types of RT target.they are PXI-8196 with RT,cfP-2120,cRIO-9014,cRIO-9004.I just used replication.vi to replicate RT target to my host PC and the result is that all of them except cRIO-9004 can not be replicated.I wonder if there are some special requirements that i don't know?like the type and version of RTOS,the network safty software (firewall,Rising)and so on?
PS:
Controller Series     RTOS
cFP-21xx             PharLap ETS
cRIO-900x             PharLap ETS
PXI[e]-81xx             PharLap ETS
cRIO-901x             VxWorks

Can you be a bit more specific about any error messages, what didn't work, what did you try.

In general the RT System Replication tools do work with all of the targets you specify. As long as you can load and run the RT System Replication VIs, the version of LV RT should not matter. The Get and Set Image VIs only copy the contents of the harddrive on your selected RT target.

A firewall running on your PC can interfere with the communication used by the RT System Replication VIs, so for debugging purposes you may want to temporarily turn off the firewall.

rtcp not reliable

MKr — Wed, 15 Oct 2008 15:44:12 GMT

Hello!

We're manufacturing laboratory equipment with cFP2100 (in the future: cFP2200) CPUs inside. We use rtcp to initialize these controllers at our site before shipping the machines and likewise to give our customers the ability to perform software upgrades of their machines every now and then at their sites at a later point in time.

Whereas these machines are under our complete control during the initial use of rtcp, they of course won't be when our customers perform upgrades later. In particular, it just won't be possible for our customers to access the DIP switches at the cFP2xxx, let alone that our customers would not now how to use them.

This is important, because every now and then (about 20% probability), we must experience that rtcp will not get its job done correctly, but rather will abort the process somewhere in between. This seems to get even worse (i.e. more often) if the connection between the PC running rtcp and the cFP is via a company's network rather than using a crossover network cable (which we of course recommend).

If this happens, our customer has to re-initiate the transfer -- if he can: In about 10% of the above-mentioned 20% of all uses of rtcp, the controller's flash disk seems to be corrupted in a way that the controller is no longer accessible via network at all. Now, only a reformatting of the flash disk helps, which our customers can't perform since they do not have physical access to the DIP-switches of the controller (let alone that some of them won't be able to perform that task due to a complete unfamiliarity with LabVIEW).

So, these sporadic failures of rtcp generate a big problem for us: Currently, we do not know how to implement an upgrade scheme for our customer's machine's cFP-controllers that won't give us customers calling in from time to time (from far places!) wondering why their machines are broke and us wondering what in the world we now can do about it.

Any ideas?

Oh, by the way: We would have liked to give the internals of rtcp a closer look (maybe just some communication timeouts would need to be increased?), but the interesting VIs are all password protected (which quite many people dislike, as I can see on NI's related webpage).

We would appreciate any help a lot!

Best regards

Re: rtcp not reliable

Brian_K. — Fri, 17 Oct 2008 20:40:18 GMT

MKr,

1) How does the controller showup in MAX when it becomes corrupted?

2) When you lose communication, does that mean the you cannot FTP to the target. I ask because maybe you could try to make an image of the corrupted controller that would help in reporducing the issue.

3) Have you tried reporducing the problem with the source code instead of the built exe? Maybe then we could figure out which VI is causing the problem.

As a side note, you may want to look into this example:

http://zone.ni.com/devzone/cda/epd/p/id/5970

It would make upgrading your code as simple as switching out a USB stick. It might eliminate many problems.

Re: LabVIEW Real-Time Application Deployment

MKr — Sat, 18 Oct 2008 12:35:33 GMT

Hello Brian!

Thank you very much for looking into this and responding so quickly!

Regarding your questions:

1. It doesn't show up anymore at all.

2. FTP is also impossible then. The controller seems to be real dead. Only thing that helps is the safe mode DIP switch.

3. Not yet. Good idea, will try that asap. Provided that the necessary recompiling will work using LV 8.6...

And of course I gave http://zone.ni.com/devzone/cda/epd/p/id/5970 a look. Thanks for this reference!

However, I think that this won't help us, because:

a) Our controllers (cFP2100/cFP2200) don't have a USB port or any other port for plug-in memory

(the cFPs that have one are much too expensive for our application),

b) our customers would not have access to a USB port just like they do not have access to the DIP switches,

c) it might be an issue that we use cFP in the first place. This application has been made for

(and seemingly only tested with) cRIO,

d) in sum, it seems to be a rather complicated procedure -- I feel other possible problems, and

e) all it does (if I got that right) is take care of the user program. However, an upgrade -- if taking

place after us switching to yet another LV or RT version -- might very well comprise the

whole cFP operating system as well.

Regarding e): In fact, we have to do that right now, because we just had to switch to LV 8.6 which in turn brought a switch to FP 6.0.3.

So, A LOT of the SYSTEM files have to be updated. I doubt that this application can do that, or can it?

We tried to perform such an upgrade with simple FTP for a change (to check whether this would be an alternative to rtcp). We do a lot of file transfer from and to our cFPs with simple FTP (using the MS explorer or similar programs) but this time the controller (!) would simply not accept all files. I suspect that it won't accept files belonging to its operating system while that very system is running.

That's a pity for another reason: With 'normal' FTP, we never experienced any interrupted communication whatsoever. Which, by the way, seems to be another indication that rtcp has some kind of flaw when it comes to transferring the files.

I don't think that we should bother too long with the problem of the dead controller in case of an interruption during file transfer -- I think this might be inevitable every now and then when interrupting the transfer of important files (please correct me if I'm wrong!).

What should be focused on in my opinion is to avoid such interruptions in the first place. I just don't get it why this happes SO often with rtcp even when using a crossover network cable. There must be something wrong with the way the file transfer is handled. Much more so if one takes into consideration how reliable FTP file transfer usually is with all that error detection and re-sending stuff built in.

Thank you and kind regards

MKr

Re: LabVIEW Real-Time Application Deployment

NI-Bob — Wed, 12 Feb 2025 02:08:02 GMT

Hello MKr,

I have spoken with R&D on this issue and want they also recommended that we try to run the VI version in order to determine where the error is occurring in order to further troubleshoot the issue. It is also possible that your network communication could be "starved" by what is being executed on the target. There are a few different tools that we can use to help determine if this is an issue. Have you used the Real-Time System Manager or the Execution Trace Toolkit before? Both of these tools will help us determine how the controller is responding to the code that is executing on it.

Another thing that R&D mentioned was that they would like to try and have a copy of the image that you are using in order to try and replicate the behavior you are experiencing on our end. If you would prefer to not post this on the discussion forums I can give you a service request number so that we can ensure that the files are only sent to R&D.

Please just let me know if you have any further questions or updates on this issue and I will be happy to assist you. I look forward to hearing from you! Have a great day!