LabVIEW Real-Time Application Deployment

[fblerg]

Hi  MikeC3,

Good find. You can report issues at the below link. Also see the testing requirements in the Contributing document.

https://github.com/ni/rad/issues

https://github.com/ni/rad/blob/master/CONTRIBUTING.md

Thanks,

Frank

[cgibson]

Does anyone know what kind of login permissions are needed when RAD programs the image of one of these new Linux RT based cRIOs? Do we need to be admin?

Our cRIOs are deployed to our production sites and maintained by technicians. We would prefer not to give techs what is essentially a root password. (The admin account has root privileges.) But it is not clear if you can install whole images to these new cRIOs with anything less then admin.

Anybody know?

Thanks!

[JoshuaP]

Yes, it has to be the admin password, which makes sense when you think about it because you are replacing the entire image.  That kind of power should only be available to administrators.

[nanocyte]

I asked the same question here:

https://forums.ni.com/t5/Real-Time-Measurement-and/What-permissions-does-a-CRIO-user-need-to-retriev...

I agree with the need for "Imager" permissions so it's not all or nothing.

[cgibson]

Hi Joshua,

The problem with that is that only people with the all powerful admin password can perform software updates. We have production sites all over the world and maintenance may happen at any time of the day or night.

The alternative, giving local field technicians the admin password, is even more problematic.

[cgibson]

Hi nanocyte,

Thanks for the link. Did you ever get it to work?

[cgibson]

There is a race condition in rad_Extract Full Image.vi. In the VI there is a copy function and a subVI called Util_AppCreateTempDirectory.vi. The order of execution of these two functions is not guaranteed. If the util runs first, it deletes and recreates a directory. The copy then copies the image file to this newly created directory. This is the correct order.

If the copy happens first, then the util deletes the directory along with the copied image file and leaves an empty directory.

Functions downstream fail intermittently in this case as they expect the image to be there and it isn't. The user level symptom of this is being told that the image file is incompatible with the version of RAD. This is because the image file version string is empty.

I posted this description to the Github issues list.

[cgibson]

If you try to retrieve an image from a 9038 or 9049 when the / file system is 100% full, you will get a pop up with a unhelpful error message.

I think this happens if you deploy to a full cRIO as well.

Maybe if this error is detected a file system check can be done, and if full, a more informative error message provided.

This error happens in the Create System Image (Folder).vi that is called from rad_Retrieve Image Wrapper.vi.

I posted this over in the GitHub as well as here.

[James@Work]

---

@cgibson wrote:

If you try to retrieve an image from a 9038 or 9049 when the / file system is 100% full, you will get a pop up with a unhelpful error message.

I think this happens if you deploy to a full cRIO as well.

Maybe if this error is detected a file system check can be done, and if full, a more informative error message provided.

This error happens in the Create System Image (Folder).vi that is called from rad_Retrieve Image Wrapper.vi.

I posted this over in the GitHub as well as here.

---

FYI - I received an almost identical error message, different number (-2147220331) when trying to retrieve an image from an NI cRIO-9014.  While it was just as useless for debugging the problem, my root cause was different.  In my case there was a very large file on that cRIO and after I deleted it the image retrieval was successful.

Just in case this detail might help someone else debug a similar problem.

[Mads]

Bug report (RAD 16.0.0.1):

I had trouble with converted images always being just 1KB if the original image was located on a file share (access issue).

Turns out such errors are not passed on, due to a missing shift register...(So I did not notice anything when converting, only when trying to deploy the new image...).

A disk access error will cause the auto-indexed for-loop in the ExtractNestedImage VI to get an empty path array input from the UnZip-function, and this in turn causes the for-loop to pass on a default error instead (see image below):