NI Home > Community > NI Discussion Forums
Reply
Member MKr
Member
MKr
Posts: 13
0 Kudos

Re: LabVIEW Real-Time Application Deployment

Helllo Bob!

 

Now for our test results transferring an image to cFP2200:

 

In short:  in contrast to transferring an image to cFP2100, this has a high probability of working correctly,  but the automatic reboot at the end of the process almost never works (just like with cFP2100).  The probablilty is for some reason higher when the controller is connected directly to the transferring PC via a crossover network cable than when PC and cFP are each connected to our company's network.

 

However, the good news is that in all our tests (cFP2100 and cFP2200) there has not been a single case of an interruption of transfer right in the middle of the process, which is a big problem with the 'old' rtcp and sometimes leaves the cFP's memory severely corrupted (which, consequently, did not happen once either).  Since this is THE major problem for us with the 'old' rtcp, the 'new' rtcp is a real step forward in this regard.

 

But, as I already laid out in my post from November 20, the 'new' rtcp is nevertheless unable to transfer an image correctly to a cFP2100.  This always fails.

 

(The fact that with both cFP2100 and cFP2200 the user has to power-cycle the controller because the automatic reboot hardly ever works, is a minor flaw for our replication scenarios.)

 

It is hard to specify exactly how the transfer to cFP2100 fails, because the behavior differs in many ways.  Every test is different, just the result is identical (cFP2100 won't run our program at all or at least won't run it correctly, see my post from November 20).  And I still suspect that the 'new' rtcp has a flaw in handling files or file types with regard to cFP2100.  I know that 'inside' the replication toolkit, there is quite a bit of logic regarding the handling of specific files and file types; (e.g. some are not transferred at all).  That makes me think that maybe this logic has been modified and maybe the people who did that did not take 'older' controllers into proper consideration?  cFP2200 internally is very much different from cFP2100: other CPU, other RT-OS!

 

Maybe I should remind you that during our tests we always transfer images that have been read from the controllers earlier using the 'old' rtcp.  This has been done because a) it shouldn't (and in my eyes mustn't) make a difference and b) we need that because we simply won't have the opportunity to re-read certain images from older controllers at our site using the 'new' rtcp..

 

Attached you find one example of the new rtcp's output when transferring to cFP2200 via company network NOT resulting in a correctly running controller (even after power-cycling) in file rtcpV8_cFP2200_network.txt.

As already mentioned, this happens sometimes when connected via network (and rarely when connected directly).  The output can differ considerably, however.

 

Also attached you find one expample of the new rtcp's output when transferring to cFP2100 via crossover cable NOT resulting in a correctly running controller (even after power-cycling) in file rtcpV8_cFP2100_local.txt.

As already mentioned, this happens all the time, but the output can differ considerably and the behavior of the controller can also differ considerably; still the best we ever got was a running application but somehow 'missing' (or severely misbehaving) network variables (which have to be deployed on the very same controller and are in the image).  Most of the time (and in this paricular expample), however, our application won't run at all.  See my post from November 20.

 

Since the exact behavior is so much different from test to test, it really would be best if you tried this at your site.  Hence, I'm still looking forward to receiving the service request number; I then would send both images rightaway so that you can reproduce our findings easily and analyse the reported behavior.

 

Thank you and best regards

MKr

Member
NI-Bob
Posts: 79
0 Kudos

Re: LabVIEW Real-Time Application Deployment

Hello MKr,

 

This is all very good information!  Thank you very much for creating such detailed notes.  I agree that the best option at this point is for me to try to replicate the behavior you are seeing on my end.  I have created a temporary service request for you so that we can take this off the forums.  When you get the chance please give me a call at 1-866-275-6964 and then enter your service request number 1293151.  You will be routed directly to my phone so that we can further troubleshoot this issue and make sure that I get your image file.  I look forward to hearing from you!  Have a great day!

Thanks!
Bob H
Applications Engineer
National Instruments
Member
Mike23
Posts: 16
0 Kudos

Re: LabVIEW Real-Time Application Deployment

Hello! I have made a image of the cRio9012. And then have tried to load it. But there is an error
Rebooting 172.16.2.40
Deleting files...
Uploading /.tfs0036.vi
Uploading /ni-rt.ini
Uploading /persist.pal
Uploading /ni-rt/system/config.cdf
Uploading /ni-rt/system/config.old
Uploading /ni-rt/system/config3.mx5
Uploading /ni-rt/system/config3.mxd
Uploading /ni-rt/system/config3.mxs
Uploading /ni-rt/system/config3.mxs.jnl
Uploading /ni-rt/system/criosd.out
Uploading /ni-rt/system/csserial.out
Uploading /ni-rt/system/ftpserve.out
Uploading /ni-rt/system/libappweb.out
Uploading /ni-rt/system/libespModule.out
Uploading /ni-rt/system/libexpat.out
Uploading /ni-rt/system/logosrt.out
Uploading /ni-rt/system/lvalarms.out
Uploading /ni-rt/system/lvanlys.out
Uploading /ni-rt/system/lvblas.out
Uploading /ni-rt/system/lvpidtkt.out
Uploading /ni-rt/system/lvrt.out
Uploading /ni-rt/system/lvuste.out
Uploading /ni-rt/system/max.ini
Uploading /ni-rt/system/max.mx5
Uploading /ni-rt/system/modbus.mnd
Uploading /ni-rt/system/mxs.mx5
Uploading /ni-rt/system/mxs.mxr
Uploading /ni-rt/system/mxs.out
Uploading /ni-rt/system/mxsdb.out
Uploading /ni-rt/system/mxsdd.out
Uploading /ni-rt/system/mxsin.out
Uploading /ni-rt/system/mxsjar.ini
Uploading /ni-rt/system/mxsjar.mx5
Uploading /ni-rt/system/mxsSchema.log
Uploading /ni-rt/system/mxssvr.out
Uploading /ni-rt/system/mxsutils.out
Uploading /ni-rt/system/nbfifo.out
Uploading /ni-rt/system/ni_emb.out
Uploading /ni-rt/system/ni_tagger_plugin_mxs.out
Uploading /ni-rt/system/ni_traceengine.out
Uploading /ni-rt/system/nids.out
Uploading /ni-rt/system/nilwpce.out
Uploading /ni-rt/system/nilxtcor.out
Uploading /ni-rt/system/niorba.ocm
Uploading /ni-rt/system/niorbs.out
Uploading /ni-rt/system/nipals.out
Uploading /ni-rt/system/nipspxts.out
Uploading /ni-rt/system/niriorpc.out
Uploading /ni-rt/system/niriosrv.out
Uploading /ni-rt/system/nirpcs.out
Uploading /ni-rt/system/niserial.dbs
Uploading /ni-rt/system/niserial.ini
Uploading /ni-rt/system/niserial.out
Uploading /ni-rt/system/nisvcloc.out
Uploading /ni-rt/system/nitaglv.out
Uploading /ni-rt/system/NiViSrvr.out
Uploading /ni-rt/system/NiViSv32.out
Uploading /ni-rt/system/niwd4c.out
Uploading /ni-rt/system/niwebsrv.out
Uploading /ni-rt/system/nvdata.bin
Uploading /ni-rt/system/registry.out
Uploading /ni-rt/system/rtapp.rsc
Uploading /ni-rt/system/rtvarnet.out
Uploading /ni-rt/system/rtvarsup.out
Uploading /ni-rt/system/settime.out
Uploading /ni-rt/system/sysstatepublisher.out
Uploading /ni-rt/system/taggerrt.out
Uploading /ni-rt/system/target.out
Uploading /ni-rt/system/tdms.out
Uploading /ni-rt/system/TgrDD.out
Uploading /ni-rt/system/TgrDDDD.mxr
Uploading /ni-rt/system/ts_dio.out
Uploading /ni-rt/system/ts_rtc.out
Uploading /ni-rt/system/ts_sntp.out
Uploading /ni-rt/system/tsengine.out
Uploading /ni-rt/system/visa32.out
Uploading /ni-rt/system/VisaCtrl.ocm
Uploading /ni-rt/system/VisaCtrl.out
Uploading /ni-rt/system/vx_exec.out
Uploading /ni-rt/system/vxWorks
Uploading /ni-rt/system/ws_runtime.out
Uploading /ni-rt/system/errors/English/analysis.err
Uploading /ni-rt/system/errors/English/labview.err
Uploading /ni-rt/system/errors/English/lvfpga.err
Uploading /ni-rt/system/errors/English/measure.err
Uploading /ni-rt/system/errors/English/nicrio.err
Uploading /ni-rt/system/errors/English/nimxs.err
Uploading /ni-rt/system/errors/English/niorb.err
Uploading /ni-rt/system/errors/English/nipal.err
Uploading /ni-rt/system/errors/English/niriofcf.err
Uploading /ni-rt/system/errors/English/reports.err
Uploading /ni-rt/system/errors/English/VISA.err
Uploading /ni-rt/system/errors/English/watchdog.err
Uploading /ni-rt/system/errors/French/lvfpga.err
Uploading /ni-rt/system/errors/French/nicrio.err
Uploading /ni-rt/system/errors/French/nimxs.err
Uploading /ni-rt/system/errors/French/niorb.err
Uploading /ni-rt/system/errors/French/nipal.err
Uploading /ni-rt/system/errors/French/niriofcf.err
Uploading /ni-rt/system/errors/French/VISA.err
Uploading /ni-rt/system/errors/French/watchdog.err
Uploading /ni-rt/system/errors/German/lvfpga.err
Uploading /ni-rt/system/errors/German/nicrio.err
Uploading /ni-rt/system/errors/German/nimxs.err
Uploading /ni-rt/system/errors/German/niorb.err
Uploading /ni-rt/system/errors/German/nipal.err
Uploading /ni-rt/system/errors/German/niriofcf.err
Uploading /ni-rt/system/errors/German/VISA.err
Uploading /ni-rt/system/errors/German/watchdog.err
Uploading /ni-rt/system/errors/Japanese/analysis.err
Uploading /ni-rt/system/errors/Japanese/labview.err
Uploading /ni-rt/system/errors/Japanese/lvfpga.err
Uploading /ni-rt/system/errors/Japanese/measure.err
Uploading /ni-rt/system/errors/Japanese/nicrio.err
Uploading /ni-rt/system/errors/Japanese/nimxs.err
Uploading /ni-rt/system/errors/Japanese/niorb.err
Uploading /ni-rt/system/errors/Japanese/nipal.err
Uploading /ni-rt/system/errors/Japanese/niriofcf.err
Uploading /ni-rt/system/errors/Japanese/reports.err
Uploading /ni-rt/system/errors/Japanese/VISA.err
Uploading /ni-rt/system/errors/Japanese/watchdog.err
Uploading /ni-rt/system/errors/Korean/nicrio.err
Uploading /ni-rt/system/errors/Korean/nimxs.err
Uploading /ni-rt/system/errors/Korean/niorb.err
Uploading /ni-rt/system/errors/Korean/nipal.err
Uploading /ni-rt/system/errors/Korean/niriofcf.err
Uploading /ni-rt/system/errors/Korean/VISA.err
Uploading /ni-rt/system/ethernet/netconf.ini
Uploading /ni-rt/system/Last/mxs.mxr
Uploading /ni-rt/system/Last/mxsdd.out
Uploading /ni-rt/system/Last/TgrDD.out
Uploading /ni-rt/system/mxsCheckpoints/20090423_141008.cpt/config3.mxs
Uploading /ni-rt/system/vxipnp/VxWorks/bin/NiEnAsrl.out
Uploading /ni-rt/system/vxipnp/VxWorks/bin/NiViAsrl.out
Uploading /ni-rt/system/vxipnp/VxWorks/bin/NiViEnet.out
Uploading /ni-rt/system/vxipnp/VxWorks/bin/NiViPxi.out
Uploading /ni-rt/system/vxipnp/VxWorks/bin/nivirio.out
Uploading /ni-rt/system/vxipnp/VxWorks/bin/NiViUsb.out
Uploading /ni-rt/system/vxipnp/VxWorks/NIvisa/visaconf.ini
Uploading /ni-rt/system/vxipnp/VxWorks/NIvisa/Passport/nivirio.ini
Uploading /ni-rt/system/vxipnp/VxWorks/NIvisa/Passport/nivisa.ini
Uploading /ni-rt/system/webserver/mime.types
Uploading /ni-rt/system/webserver/LVModules/lvauthmodule.out
Uploading /ni-rt/system/webserver/LVModules/lvrfpmodule.out
Uploading /ni-rt/system/webserver/modules/libcopyModule.out
Uploading /ni-rt/system/webserver/modules/libdirModule.out
Uploading /ni-rt/system/www/Beyond.htm
Uploading /ni-rt/system/www/Docs.htm
Uploading /ni-rt/system/www/favicon.ico
Uploading /ni-rt/system/www/Index.htm
Uploading /ni-rt/system/www/Overview.htm
Uploading /ni-rt/system/www/Services.htm
Uploading /ni-rt/system/www/Webtool.htm
Uploading /ni-rt/system/www/www.css
Uploading /ni-rt/system/www/images/Home.gif
Uploading /ni-rt/system/www/images/Homed.gif
Uploading /ni-rt/system/www/images/Lvwebsrv.gif
Uploading /ni-rt/system/www/images/Next.gif
Uploading /ni-rt/system/www/images/Nextd.gif
Uploading /ni-rt/system/www/images/Panel.gif
Uploading /ni-rt/system/www/images/Panldiag.gif
Uploading /ni-rt/system/www/images/Prev.gif
Uploading /ni-rt/system/www/images/Prevd.gif
Uploading /ni-rt/system/www/images/top.gif
Uploading /ni-rt/system/www/images/up.gif
Rebooting...
Error occurred:
FTP Transaction:
550 Could not open file
I use lv8.6. and replication.vi
Please help!
Active Participant
Christian_L
Posts: 644

Re: LabVIEW Real-Time Application Deployment

I have posted an update to the RT System Replication tools in the following DevZone Community entry. This update adds some extra Wait times in the processes which retrieves files from an RT target and places files on an RT target, in order to give the FTP server more time to free up used sockets for additional operations.

 

http://decibel.ni.com/content/docs/DOC-5102

 

This update resolves some issues when retrieving or placing a large number of files on an RT target using the RT System Replication Tools. Typical errors included either a TCP Timeout (56) or Timout while waiting for the RT target to reboot.

Christian Loew, CLA
Principal Systems Engineer, National Instruments
Please tip your answer providers with kudos.
Member
Jason Stallard
Posts: 37

Re: LabVIEW Real-Time Application Deployment

Hi Christian,

 

Over all, nicely done!  Much improved from the previous version!

 

I just gave the RT Replication tools a test drive using the included reference application.  I found a couple of things you might want to look into.

 

1)  The application loads settings from rtad_config.ini but exits writing to adu.ini.

 

      I edited the VI so that on exit, it writes to rtad_config.ini.

 

2)  When downloading the image from the controller (cFP2220), it does not boot into safe mode.

 

3)  When uploading the image to the controller (cFP2220), it does not boot into safe mode ( but does perform a reboot when done).

 

4)  When using the application to configure the controller IP settings, the checkbox for DHCP does nothing but (dis)enable the indicators.  There was a hidden control

      wired into the set IP address VI which was causing the controller to be set to use DHCP.

 

      I edited the sub VI rtad_configure_target.vi so that the input to the set IP address VI is a local variable to the DHCP checkbox rather than the boolean control.

 

5)  When I build the application

 

      -- The application builder gives these warnings:

 

     LabVIEW prevented a file name collision during the build. Duplicate file names cannot be copied to the same destination. You can rename files as part of the build process to avoid name conflicts. 

     The following files were moved to a unique location:

     D:\LabView_Development\RT_Deployer_Reference\rtad20090603\subVIs\Zip\Open unZip File.vi
     D:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\zip\Open unZip File.vi
     D:\LabView_Development\RT_Deployer_Reference\rtad20090603\subVIs\Zip\Set Unzip File Date Time.vi
     D:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\zip\Set Unzip File Date Time.vi
     D:\LabView_Development\RT_Deployer_Reference\rtad20090603\subVIs\Zip\Close unZip File.vi
     D:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\zip\Close unZip File.vi

 

6)  When I try to run the built application from the project explorer.  The exe can't find three sub vi's (out of the general error handler?):

     "Not Found Dialog.vi", "Details Display Dialog.vi", and "Set String Value.vi"

 

7)  In the project, there's a broken dependency for "PathToUNIXPathString.vi" [Warnin: has been deleted, renamed, or moved on disk"]

      I got a chuckle seeing that VI's name ... when we made the jump From PharLap to VxWorks we spent a few hours scratching our heads

      before we realized we had a pathing problem and wrote our own.

 

If you could, please give us an idea what's going on with #6 so we can proceed with checking everything out?

 

Again, awsome job!

 

-Jason

     

Member MKr
Member
MKr
Posts: 13

Re: LabVIEW Real-Time Application Deployment

Hello Christian, hello Jason!

 

Thank you, Christian, for putting considerable work into this issue.  I appreciate that.  Since we depend on an easy to use and reliable controller replication scheme for our customers to use, I would like to ask you the following:

 

Under "Requirements", it says CompactRIO.  How about compact FieldPoint?   You mention certain problems that you resolved by inserting  additional wait times, and  here again only cRIO is mentioned.  Is it possible for a cFP system to run into the same problems?  You say that the problems occur when "a large number of files" has to be handled.  Just about how many files are we roughly talking about?   Did you use the Replication Toolkit V7 or V8?  Did you use that toolkit unchanged or did you make any modification to the 'inner' VIs of the toolkit?   Where exactly did you place the additional waits?

 

Jason, regarding points 2 and 3 on your list:

From what I experienced, I think it's normal (or at least ok) that the controller does not reboot before the toolkit's VIs read the data from the controller.

However, it is a MAJOR malfunction if a cFP-controller does not reboot before an image is put onto it.

 

The controller must not only reboot, it must do it in a certain way that eventually puts it into a special mode called "install mode" which is similar to "safe mode" and even comes with a similar flashing of the status LED.

 

Any image transfer to a cFP-controller that is in any other mode than the two I mentioned is most certainly doomed to fail.

 

The reason for this no-boot-behavior is an error in version 8 of the replication toolkit which did not exist in version 7.  It is big, but nevertheless very easy to resolve.  I know that because thank god some folks at NI told me so, which then finally enabled us to eliminate this behavior very quickly at our site.  So NI knows this, but the version 8 replication toolkit that is offered for download did not change since it was first put onto the NI website in 2008.  (I do not understand that.)

 

Another funny similar thing:  Both versions of the replication toolkit (version 7 and version 8) contain an .exe named rtcp which enables the customer to read and write images rightaway without the need to compile anything or any familiarity with the internals of the replication toolkit.  I was surprised to learn that the file rtcp.exe in the version 8 toolkit is the VERY SAME than that of the version 7 toolkit.   All the poor souls who use the version 8 rtcp and think they improved still use version 7 rtcp...   

And again:  NI knows this.  The version 8 replication toolkit keeps unchanged.  (I do not understand that.) 

 

Kind regards

MKr

 

Active Participant
Christian_L
Posts: 644

Re: LabVIEW Real-Time Application Deployment

[ Edited ]

Jason and MKr,

 

Thank you very much for your detailed notes and feedback. I'm working through them now and will address them individually.

 

#1 and 4: Notes and fixed in my code. I will publish an update when I get as many issues as possible resolved.

 

# 2 and 3: I'm not very familiar with the FP targets right now, and MKr's notes already provide an answer. I will spend some time testing on a cFP target and report my findings. So far retrieving and deploying an image on my cFP-2220 controller seems to work okay.

 

#5: This is the expected behavior related to conflicting VIs from different LVLIB name spaces. The app builder removes the VIs from their separate name spaces and runs into a name confilict, which it resolves and presents this warning.

 

In this particular case I needed to add some functions to the ZIP tools provided in LabVIEW. Rather than change the ZIP LVLIB distributed with LV, I made a copy and added my new functions to the copied LVLIB. However both LVLIBs include the same three subVIs, which creates this name conflict during the application build process. If I had added the new functions to the existing LVLIB I would have avoided this issue.

 

#6: I have run into the same issue on my end and need to find out the cause. My current workaround is to include these files in the project list and add them as Always Include VIs in the Source Files section of the EXE Build Spec. The VIs are located in \vi.lib\Utility\error.llb. When I publish an updated version of the utility I will include a Build Spec in the project that will properly build the utility into an EXE. I will also include sample applications for a cRIO, cFP, and PXI target.

 

Jason,

 

I have mainly focused on and tested the utility with CompactRIO targets, but it should work for Compact FieldPoint and PXI as well. I will spend more time testing on cFP targets and please keep reporting any problems you find.

Message Edited by Christian L on 06-24-2009 12:03 PM
Christian Loew, CLA
Principal Systems Engineer, National Instruments
Please tip your answer providers with kudos.
Active Participant
Christian_L
Posts: 644

Re: LabVIEW Real-Time Application Deployment


Jason Stallard wrote:

 

6)  When I try to run the built application from the project explorer.  The exe can't find three sub vi's (out of the general error handler?):

     "Not Found Dialog.vi", "Details Display Dialog.vi", and "Set String Value.vi"

 


This issue is related to a Conditional Disable structure in the Simple/General Error Handler VI. This structure includes different code depending on whether the VI is targetted to Windows or RT. As you open and save the error handler on your Windows or RT targets it will be re-compiled and saved for one of these two targets. If the error handler VI is saved in the wrong state while building the executable, these three subVIs may be missing from the built EXE.

 

I was able to to resolve this problem by opening the error handler VI and several levels of subVIs (down to the General Error Handler CORE) on a Windows target and compile/run each of the VIs and resaving them. Then when I build the EXE, the three missing subVIs are included in the EXE.

Christian Loew, CLA
Principal Systems Engineer, National Instruments
Please tip your answer providers with kudos.
Member MKr
Member
MKr
Posts: 13
0 Kudos

Re: LabVIEW Real-Time Application Deployment

Hello Christian,

 

since we depend on an easy to use and reliable controller replication scheme for our customers to use, I would like to ask you the following regarding your post from 06-18-2009:

 

You mention certain problems that you resolved by inserting additional wait times, but only cRIO is mentioned.  Is it possible for a cFP system to run into the same problems?  You say that the problems occur when "a large number of files" has to be handled.  Just about how many files are we roughly talking about?   Did you use the Replication Toolkit V7 or V8?  Did you use that toolkit unchanged or did you make any modification to the 'inner' VIs of the toolkit?   Where exactly did you place the additional waits?

 

How can I give Kudos?  Can't find the right knob in the forum software (or I'm not authorized??)...

 

Thank you very much in advance.

Kind regards

MKr

 

Active Participant
Christian_L
Posts: 644

Re: LabVIEW Real-Time Application Deployment


MKr wrote:

Hello Christian,

 

You mention certain problems that you resolved by inserting additional wait times, but only cRIO is mentioned.  Is it possible for a cFP system to run into the same problems? 


The same problem will likely occur on FP and PXI RT targets using LabVIEW 8.x RT. The issue is in the Ethernet configuration and FTP server running on the RT target, which is very similar on these three platforms. This issue has been corrected in the next version of LV RT, so this workaround is only required until then.


You say that the problems occur when "a large number of files" has to be handled.  Just about how many files are we roughly talking about?  


In my case it was around 240 files, but I've heard the issue occur with as few as 180 files. The specific number will depend partially on your network connection and speed. With a faster connection the number of files that will cause this issue will be lower as the controller will have less time to free up and reuse existing Ethernet ports/sockets.


Did you use the Replication Toolkit V7 or V8?  Did you use that toolkit unchanged or did you make any modification to the 'inner' VIs of the toolkit?   Where exactly did you place the additional waits?

I used the V8 Replication tools which are currently published on DevZone and made modifications to the inner workings. These updated VIs are posted on DevZone community. The Wait function is placed in a For loop in the Get Target Image and Set Target Image VIs. The loop is executed once for each file that is retrieved from or copied to the controller. The Wait function slows down this process so that the controller has more time to free up and reuse Ethernet sockets. The default Wait time is set to 500 ms, but the control is pulled out to the connector pane of these two updated VIs ("Delay per File (ms)") so that you can set the Wait time yourself.

 


How can I give Kudos?  Can't find the right knob in the forum software (or I'm not authorized??)...
Click on the White Star in the yellow box on the right side of the post.
Christian Loew, CLA
Principal Systems Engineer, National Instruments
Please tip your answer providers with kudos.