Easier Way To Deploy Target-Relative Apps To RT Targets Needed

[Ron_@_Fluor-Bettis]

When creating a real-time app (.rtexe) intended to be run on multiple targets with target-relative references, the recommended technique is to create a build with a IP address of 0.0.0.0; then, using some other utility outside of the LabVIEW environment, copy the executable to the startup folder on the target.

Given that, it would seem reasonable to create a feature within the LabVIEW Project Explorer that allows for direct deployment to a specific RT target or targets from the right-click menu instead of having no option to select an alternate target(s).  If setting the IP address in the project to 0.0.0.0 is the recommended technique for creating a target-relative (versus absolute) executable, then LabVIEW Project Explorer should be able to key off of this value to take a different and more appropriate action.

The same would be true of the Set as startup and Run as startup right-click menu options.

[rtollert]

I'm prrrretty sure that IPK-based deployment through SystemLink is meant to handle this use case, and it will probably do it better — you don't even need to fire up LabVIEW to do the deploy. Have you looked into that yet?

[Ron_@_Fluor-Bettis]

I had not looked at NI SystemLink, nor had I heard of it before.  Now that I have taken a quick look at it, SystemLink appears to be a multi-featured software package intended for the enterprise that may be a bit heavy for us to learn, support, and fund.

I will mention though, that we have in the interim, in about a day and a half, built our own LabVIEW app to deploy applications that is specifically tailored to our needs.  Our custom app also takes care of some deployment specifics (e.g, copying additional files to other non-startup folders, tweaking settings in ni-rt.ini and lvrt.conf) beyond what may be included as native features in SystemLink.  After going through that exercise, it made me wonder why I never took the time to create custom app before, since it's been an inefficiency for me for years.

That said, I still think it would be worthwhile for NI to pursue creating a new feature in LabVIEW Project Explorer that would allow users to select an alternate RT target when selecting Deploy from the right-click menu.  Couldn't be that hard could it?

[rtollert]

Glad to hear that a custom app is accelerating your workflow, but I'm still about 95% confident that you are re-implementing features that we have already shipped.

The IPK build process is largely independent of SystemLink (and in particular you don't need to buy SystemLink to build IPKs). It transparently allows supplementary files to be installed on the filesystem. It allows preinst and postinst scripts to be run (granted through shell scripting, not LabVIEW, but for the purposes you are describing I think that is more than adequate). Finally, once you have an IPK, you don't even need NI software to deploy the app; you just need something to SFTP the IPK to the target, login as admin, and `opkg install` the package. You can run that from a custom app, or from pretty much any other app as well.

The topological completion of that feature — once you start thinking about remote package management, deploying configuration changes, standardizing communication flows from targets, web administration, etc. — is, basically, SystemLink. It's primarily advertised to enterprises because the relevant pain points tend to scale with the number of targets, but it tends to also glom a lot of best practices together that smaller deployments could still derive benefit from. But, again, it sounds like IPKs are going to give you most of what you need anyway.

RTEXE deployment from LabVIEW requires an RT protocol connection to the target, which requires that the target address be physically present in the project. I assure you that what you are asking for is more difficult than you realize.

[AristosQueue (NI)]

> I assure you that what you are asking for

> is more difficult than you realize.

rtollert is an expert in all things real time. If ne tells me I'm overreaching, I definitely trust nir judgement on it.

[Ron_@_Fluor-Bettis]

I am unfamiliar with IPKs, so I'll need some time to chew on that.

However, regarding your comment about what I am asking about is more difficult than I realize, I quickly recognized that I should mention that all of my targets are already present in my project; so I have that aspect covered.  I recognize that some enterprises may be deploying to hundreds of RT targets, but just I have about a dozen (a number which is unlikely to grow, ever); so I currently have all of my RT targets added to my project for my own convenience and flexibility.  So in that respect, maybe we are not a typical customer.

So, if the Deploy menu option (when the IP address is set to 0.0.0.0) were to then present the user with a list of only RT targets that are currently added to the project, I could certainly live with that limitation.

Since I have no knowledge or experience with IPK, I'll offer some details about the features of the custom app that we built for deployment.  Here's what it does:

1. Verifies Windows connectivity to each target, and then establishes it if necessary.
2. Copies the .rtexe file to the startup folder via a UNC path.
3. Sets the startup app name in the lvrt.conf file.
4. Sets the LauchAppAtBoot flag to TRUE in lvrt.conf.
5. Copies a configuration file for the startup app to a subfolder named Configuration on the "fake" C: drive on the Linux RT target.  If the Configuration subfolder does not exist, it gets created first.
6. Sets a key value in ni-rt.ini to enable thermocouple measurement inversion (scaling).  A custom feature in using NI 9212 modules.
7. Deploys a Shared Variable library.
8. Reboots the RT target.
9. The actions in Items 2, 5, 7 & 8 can be enabled or disabled with a checkbox selection.
10. The RT targets which are to be updated can be set with a checkbox selection.
11. The selection of the RT target's intended startup application is keyed off of the target's hostname.

The custom application is very quick to execute.

Now that said, the feature that I suggested would not cover all of these bases, but it may help with a subset of tasks and could be useful to other users.  You would have to weigh that.

[JoshuaP]

I agree with Rich that my first suggestion would be to use SystemLink, however I know it may be overkill for some people. I created a small LV example that uses the NI System Configuration API to remotely installs RT packages (IPKs) to a target you can use as a starting point.

https://github.com/joshuaprewitt/rt-package-installer

Also, here is a link to the documentation on how to build a package in LV.

https://www.ni.com/documentation/en/systemlink/latest/deployment/creating-packages-labview-package-b...

Building and deploying a package this way will automatically set it as a startup by default and you can even include small scripts to modify other settings when the package installs. It will also restart the rt application after it deploys and allow you to skip the reboot.

The only issue you may have is that I don't know of a way to deploy share variables with a package. If you have already deployed them once you can use a package to update your application as needed. 

[Guybast49000]

hi, 

I tried to use your application to install a package that I created from a project but without success.

I have an error message, can you help me to see it more clearly, please?