LabVIEW Real-Time Application Deployment

[JoshuaP]

Ok. I think I understand. We will look getting that fixed in the next release.

[Mads]

A feature request for the next version: add the option to format disk (or make the image "absolute", like a disk image).

This way we can ensure that the device is indeed free from old and possibly trouble-causing files after the image has been applied.

I've also experiences problems applying an image to a device with an old system, in which case the solution has been to format the disk first.

[Mads]

Throw in configuration of secondary NIC, and a clock adjustment interface in RAD as well and you can do pretty much everything that a production department would need to do from it;

Configure network, wipe the device if it has been used before, deploy image, set the clock - and off the assembly line it goes...

We've made a simplified version of RAD just for this purpose, here's how we've layed it out:

[QFang]

Mads,

How did you implement the time adjustment in your clamp-on tool?

Also, I don't suppose that tool would be shareable in any form? 😉

We are also developing a custom version using RAD as the base and expanding with a 'package' parser of xml commands so that we can send maintenance and service packages to our field crews that perform certain actions automaticallally based on the xml contents.

For time adjustments, I found it necessary to put a hook in the RT app itself that I can then connect to via TCP to update the time... maybe there is a simpler way that I missed?

[Mads]

The reason for not sharing the tool is the same as the reason I would prefer to get things added to RAD (and maybe it's work flow changed a bit as well); its not generic enough (we've only covered exactly the scenarios we need).

So far we use the web interface to set the time, but yes - we do plan to include it in the software deployment tool as well. Setting the time can be done using the set time VI included in the system configuration API. There are some loops to go through to handle possible time zone differences (and Daylight savings time) between the target and the PC running the tool (just try to read the time from LabVIEW and compare that to the time shown in the web interface for example: If the RT target has a different time zone the web interface does what is intuitive; it shows the time as it would appear if you were working directly on the RT target, LabVIEW does not. You also need to know the strings for the time zones (the API does not take a numeric input)...and the API does not give you a way to read the names of the different supported time zones as they appear in the Web GUI e.g. (as far as I know anyway...would have been nice..) so you have to make that equivalent control yourself...(lends itself to an XControl-implementation...). Lots of work that it would be nice to get for free from NI 🙂

[Burt_S]

This is great feedback.  Thank you for sharing it.

For the format disk feature, in general the process of imaging a controller should be exactly the same as doing a format before imaging.  Imaging should make the target controller exactly the same as the image, no matter what the starting conditions of that controller were, as long as no blacklists are used.  There are some exceptions to this, but not many.  I am concerned that this format feature is a workaround for a bug and may not be a real use-case.  Could you share some more details about the behavior you were seeing and why the format was necessary?  I'd be great to get an image that replicates this issue as well if at all possible.

For the secondary NIC configuration, these should get inherited from the deployed image.  From my experience, this is the most commonly desired use-case.  Could you share some more details about why you would like the secondary NIC configuration to be different than what is contained in the captured image?

As for the time zone change, this is great feedback and will definitely be something we consider adding in a future release. 

[QFang]

Hey Burt, 

Just wanted to point out that its not just the time zone but the actual time (hour/min/sec) that would be useful to set (synch) via RAD. 

[Mads]

Hi Burt,

About format disk:
When we apply an image it does not overwrite files that do not exist in the image. So if the target has the files A, B and C - and the image only contains B and C, then A will still reside on the target after the image has been applied.

The secondary NIC:

In our case both the primary and the secondary NICs get unique addresses on each target, so we do not want it to inherit the same address as the one in the image. This might be more normal for us than others because we (try to) use both NICs equivalently (the secondary NIC  unfortunately has no default gateway, nor DHCP support...but we need full redundancy, so we overcome this in different ways). I've posted an idea/request for an upgraded secondary NIC on the RT idea exchange...

Regards,

Mads

[QFang]

Hi Mads,

In regards to files not in your image remain on the target after an image has been deployed, I just wanted to chime in and say that is decidedly not the behavior I see. Details below:

Version: executable from NI.com v 3.0.2 (NI --> you may want to update your file "About" string to be RAD instead of RTAD which was the old name.. while at it, do a string search in the project and update all of them.)

Image retrieval black list: 

Image deployment black list: c:\mydata\ (prevents field deployment from earsing all customer data)  c:\settings\ (prevents image update from also overwriting custom settings). (Data and settings maintenance is done separately by trained field crew since every deployment is different and customized as far as the settings).

Test target setup: I copied a file (settings.dat) to c:\ and also into c:\tmp c:\ni-rt\ and just in general scattered it around a few places. I also created a new folder on the root: c:\test\ and placed a file in it. I also placed the dummy file inside of deployment blacklisted folders and created a new folder inside of one.

Results: all dummy files where removed as expected from locations that were not blacklisted. dummy files (and folders) created "inside" or "under" a blacklisted folder remained (as expected). Since my blacklistings are folders as opposed to specific files, new content in blacklisted locations are also not touched. I ran another quick test where I blacklisted c:\test\test.dat from deployment but put in a c:\test\extra.dat in the same folder.  After deploying the image with the new "blacklist during deployment: c:\test\test.dat" I had c:\test\test.dat (as expected) with the "extra.dat" removed (as expected).

So for me, in the cases described, it appears that a format would not be necessary as RAD correctly removes/replaces/keeps in accordance with my image blacklist settings.  -I wonder if files you expect to be removed are kept because you have configured the parent folder in the deployment blacklist? This would have the possibly unintended consequence of also blacklisting all files and sub-folders within that folder?

-Q

[Burt_S]

I agree.  A format should not be required and any additional files should automatically get deleted during the deployment (unless blacklisted).  If a format is required, something is happening that I wouldn't expect.  Mads, if you have two sets of images that can reproduce this behavior we would be happy to investigate them.