NI Home > Community > NI Discussion Forums

Real-Time and Control Applications

Showing results for 
Search instead for 
Do you mean 
Reply
Member
Jason Stallard
Posts: 37
0 Kudos

Re: LabVIEW Real-Time Application Deployment

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.
Active Participant
Christian_L
Posts: 660

Re: LabVIEW Real-Time Application Deployment

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.

Christian Loew, CLA
Principal Systems Engineer, National Instruments
Please tip your answer providers with kudos.

Any attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system,
or for use in hazardous environments. You assume all risks for use of the Code and use of the Code is subject
to the Sample Code License Terms which can be found at: http://ni.com/samplecodelicense
Member
Jason Stallard
Posts: 37

Re: LabVIEW Real-Time Application Deployment

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.
Member
hathello
Posts: 1
0 Kudos

回复: Re: LabVIEW Real-Time Application Deployment

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

Member
Jason Stallard
Posts: 37
0 Kudos

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

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.
Active Participant
Christian_L
Posts: 660
0 Kudos

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


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.

Christian Loew, CLA
Principal Systems Engineer, National Instruments
Please tip your answer providers with kudos.

Any attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system,
or for use in hazardous environments. You assume all risks for use of the Code and use of the Code is subject
to the Sample Code License Terms which can be found at: http://ni.com/samplecodelicense
Member MKr
Member
MKr
Posts: 13
0 Kudos

rtcp not reliable

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

Active Participant
Brian_K.
Posts: 242
0 Kudos

Re: rtcp not reliable

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. 

Brian K.
Member MKr
Member
MKr
Posts: 13
0 Kudos

Re: LabVIEW Real-Time Application Deployment

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 

Member
NI-Bob
Posts: 79
0 Kudos

Re: LabVIEW Real-Time Application Deployment

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!

 

Thanks!
Bob H
Applications Engineer
National Instruments