LabVIEW Real-Time Application Deployment

[maxwellb]

I am able to communicate with and install software to the target using MAX. The target is on the same subnet as my host computer. Get and Set Real-Time System Image.vi did successfully retrieve an image of the target. That did take about 10 minutes, whereas RAD returns the error in just 30 seconds or so. I confirmed again that RAD is still throwing the same error right after I successfully retrieved an image using Get and Set Real-Time System Image.vi.

I am using the executable version of RAD, not the source code. Should I try the source version?

One thing about my development machine that may be unusual is that it has two network interfaces. One is connected to a large corporate network and the other to a small network with just two cRIOs on it.

[ePower-ahp]

Hi maxwellb

I have same problem, see my workaround in message 194

/Anders

[maxwellb]

Yes, it could be a local permissions issue. My permissions are rather limited on this machine, so the RAD could easily have run into a problem if it tries to create a temporary file in a folder I don't have access to. Unfortunately I haven't had a chance to try this yet. I will report back if/when I do.

[QFang]

While extremely unlikely, It's worth noting that I had what appeared to be the same issue, except the workaround didn't work, it just moved the error to a different part of the program. After heavy involvement with NI R&D including remote sessions on my system where we ran wireshark etc., it was found that a (rare) issue was at work on my system.  The fix was to replace the nisysapi.dll with a fixed version.

While it wasn't conclusively determined why it was affecting one (and only one) of our PC's, the suspicion was that something else on the system was using port 80, which caused an error in a dependent library.  I would try to reference support ticket 7400160 if you see this behavior:

• can retrieve images but not deploy.
• you keep getting this error -2147467259  from source nisyscfg.lvlib:Create System Image 

       (Folder).vi:710001<APPEND>
       <b>Complete call chain:</b>
        nisyscfg.lvlib:Create System Image (Folder).vi:710001
        image folder test.vi

• the old deprecated (2011) create system image function works. (or older version of RAD).

I'm not able to post the dll from NI because NI wants to be the gatekeeper on who has it since it is such a rare corner case that causes the problem I had in the first place.  It will be fixed in the next release of System Configuration (expected out with the LV2014 coming up in a couple of weeks).  The issue got CAR# 466253 so I suppose in theory you would be able to check future releases.

[maxwellb]

I ended up switching to a different development machine on which I have local admin and the RAD seemed work perfectly there.

I do have a comment on a feature I would like to have in the RAD. My deployments make use of both Port 1 and Port 2 and it would be great to be able to automate the Port 2 IP setting somehow. In the limited run I've produced so far so that has actually been the part where the most mistakes have been made because it is one of the only parts of the software deployment that is manual.

[QFang]

Using drivers 14.5 February 2015, using NI RAD 14.0 (also reproducible in previous version 5.5.2... in fact, that error was my incentive to find and install the new version, hoping it would be fixed)

Create an image with deployment blacklists.

Update the cRIO drivers on the controller (using MAX)

Redeploy RTEXE (using LabVIEW Project)

Attempt to update the image created in step 1 using 'new version of image saved on disk'.  update or not the app image properties, then ok and retrieve.. then boom.

---> Creating a new image works fine <---

Not sure what is going on or why it is this way.  I'm Admin on my own laptop. Windows 7.

[QFang]

I tried again using the source and development mode, stepping into the point where the problem originates::

Open "rad_Retrieve Image Wrapper.vi"

The error /condition shown in screen-shot below happens when 'Create System Image.VI (Folder)' is called.  All folders and other inputs to this VI are valid.  The error message suggests that the sys-cfg api is not installed, but as can be seen on the MAX screen of the target, it is in fact installed.

Just to make sure I haven't gotten my cRIO test unit in a bad way, I formated the device (keeping network settings) using MAX, then installed the 14.5 February drivers, including the syscfg API, deployed my freshly built RTEXE app using the LabVIEW project interface (Run as startup).  (I have the dip-switch noapp set to 'on' to temporarily prevent the app from running).

I then right-click the NI RAD shortcut and chose 'run as admin' and::

1) With controller selected in RAD list, clicked 'retrieve'

2) in pop-up, selected 'New version of an... Image Saved to Disk'

3) selected the image file on disk

4) in pop-up, edited the description to include the image changes/updates, in this case, simply wanting the image to be using the latest NI CRIO 14.5 February 2015 drivers. 

5) clicked ok

6) in pop-up chose the image storage/output folder (to rule out target folder as an issue, I selected my desktop, but I've also left it at the default image folder location)

7) clicked 'retrieve image from ....'

😎 the Retrieve Image progress pop-up shows momentarily, before it is reeplaced with the error message shown below:

Since the VI that throws the error is part of the password protected system configuration api, this is (yet again) as far as I can take this issue on my own... 

[edit]  I now have the same behavior when I try to create a new image, not just when I try to update an image already on disk! [\edit] 

Any ideas at this point are welcomed.  

[QFang]

So, I figured I'd try to simplify testing of this problem.  

Attached are two VI's for 2014.  

You will only need to do 2 steps to use it:

1) On block diagram, create a 'Target (localhost)' control and pick a valid target. (I didn't want the various system resources to show, so I deleted the 'target control' from the block diagram.)

2) On front panel, pick an existing folder as your image output folder. e.g. a temp folder on your desktop.

I've attached an NI I/O Trace log of what I get when I run it.  As you can see, it fails at the 'create' step.  As to why, I have no clue.

I've tried this on both a cRIO (freshly formated and re-installed) and an sb9606 with the same result.

This is perfectly reproducible on my system 100% of the time.. I'd be interested to see if anyone else gets the error too.

This is starting to look and feel like CAR# 466253 which was supposed to be fixed with version 2013 drivers... I have a feeling that when I installed the updated drives, it replaced the file with the fix in it.. I'll follow up with NI Support and see whats going on.

[ePower-ahp]

Have you tried to force the target in safe mode before you try to recieve an image?

[QFang]

Yes, in safe mode I get a different error from my test VI.

The error I get in safe mode is -2147220621, according to NI support (just in), this error is a known error when the target is in safe mode.