Real-Time and Control Applications

cancel
Showing results for 
Search instead for 
Did you mean: 

Replication and Deployment Utility (RAD)

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

0 Kudos
Message 291 of 301
(722 Views)

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!

0 Kudos
Message 292 of 301
(570 Views)

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.

0 Kudos
Message 293 of 301
(565 Views)

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.

0 Kudos
Message 294 of 301
(560 Views)

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.

Message 295 of 301
(552 Views)

Hi nanocyte,

 

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

 

0 Kudos
Message 296 of 301
(551 Views)

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.

Message 297 of 301
(417 Views)

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.
cRIO Hard Drive Full 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.

0 Kudos
Message 298 of 301
(258 Views)

@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.
cRIO Hard Drive Full 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.

Systems Engineering
LabVIEW 5.0 - 2018
0 Kudos
Message 299 of 301
(247 Views)
Highlighted

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):

 

 

errors disappearing.PNG

 

 

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
Message 300 of 301
(156 Views)