LabVIEW Real-Time Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Mads

Running a VI from the IDE should not touch the application launch flag

Status: New

If you have an RT target set up with a startup application (ready to be deployed in the field), running a VI on it from the IDE should not change anything permanently. 

 

Today (LabVIEW RT 2013), doing this will not just temporrarily stop the VIs running on the target (from the executable) - as you get warned about, but also cause the RTTarget.LaunchAppAtBoot=True line to be removed from the ni-rt.ini. So the startup application will not be launched the next time the device is started up, rendering your device useless in the field. Why?

 

- We had an incident where we narrowly escaped such a scenario. The RT target was embedded into a cannister that was about to be sealed, but an unforseen issue made it necessary to run a special test on it, with a VI from the IDE. The startup application in this case provides the only way into the system once the cannister is sealed (no Ethernet access, just RS485), so having it no longer start would be a catastrophy. No one expected running the VI would actually change anything permanently. We tested it of course, and saw that it stopped the startup application (and so we loaded an image of the correct setup afterwards to be sure all changes were removed), but it would be much better and more intuitive if no such permanent and fundamental changes occured (if actually possible to implement in a such a way).

 

 

9 Comments
ScotSalmon
Active Participant

When you connect from the IDE to deploy the VI, it deploys the project settings configured in the project you're deploying the VI from. If that project doesn't have a startup app, the deployed settings will reflect that and disable the startup app.

 

So, if you want to preserve the configuration that includes your startup app, you need to connect from a project with a configuration consistent with that.

 

It's definitely a confusing behavior when this happens, but hopefully you can see it would be even more confusing in the other direction if we made the target ignore the settings specified in the project you're deploying from.

 

Does that explain what you saw?

Mads
Active Participant

How does a project "have a startup app"? There is a build specification for a startup application in the project..if that is what you mean, but is there a setting in the project somewhere where you *permanently* define whether that application should be set to run on startup or not?

 

I normally just right click on the build and say "Set as Startup" ...And that's been done plenty of times in that project because I almost always want it to be (so even if the last choice in the project was to blame, it should have started the app).

(I've never actually checked if I need to do this, or if it stays that way until you choose "Unset".I s that setting actually remembered within the project itself and reapplied every time?)

 

I can understand that such a setting would be applied if I actually built and deployed an application from the project, without setting it as a startup app /or actually chose the "Unset" option,  because that would make it understandable that something needed to change on the target. But in this case I'm just opening a project, run a VI that is in that project...and close the project. The fact that setting on the controller then change in the beckground, without having explicitly been told to, or at least been verified by the user, is difficult to accept as correct...

 

Intaris
Proven Zealot

Doesn't the RT need to reboot for the settings in the settings file to be actually active?

StephenB
Active Participant
Kudos. This behavior is undesired and poorly undocumented. Further, LabVIEW gives no warning that you are making permanent changes to your target's configuration when you connect via a LabVIEW project... It simply happens silently. Scott, when the application is provided by a 3rd party (like VBAI or NI VeriStand) there is no way to avoid this behavior. I CARd this like 3 years ago and I think the CAR is still open.
Stephen B
ScotSalmon
Active Participant

Mads: a project "has a startup app" if it has a build spec set as startup. If not (either no build spec, or not set as startup) then it doesn't "have a startup app" for this purpose, and deploying anything to that target through that project, including running a VI, will deploy that configuration, disabling any startup app. That setting is stored persistently in the project, so if you ever "unset" it, that "unset" state will be the configuration that is applied on each deployment from then on until you "set" it again. If you're always using a project that has "set as startup" enabled for the target you're deploying on, and "set as startup" is still getting unset by running a VI, that is a bug and I would like to understand more about your exact steps to reproduce that.

 

Stephen: I know this (meaning your CAR, not the possibly-separate actual bug Mads' new post seems to indicate) is confusing and "undesired", but I'm not sure it's worse than the alternatives. I see two obvious solutions: (a) prompt the user before making this change behind their back, or (b) ignore this part of the project configuration for some deployment operations. Are there other ideas? With respect to (a), we've gotten a great deal of feedback over the years that adding prompts during deployment is undesireable, so that would be making a fairly significant change that just trades off one undesireable behavior for another; I don't think that is the right move. For (b), the problem is identifying when you do or don't want to deploy various parts of the project configuration. It's very obvious to us as users when "I'm just running a VI!" and don't want to mess with the persistent state of the startup app, versus when we're actually intending to use the project's settings as part of the thing we're deploying. Unfortunately in some circumstances the failure mode if we left out settings that the user intended to include could be even more problematic than this failure mode. An example from the notes in your CAR is that there would be no intuitive place to put the UI to remove a custom startup app if that's what you intended. I think there are definitely a variety of options here, but I see a lot of pros and cons and no clearly correct behavior, so I'm reluctant to say we need to pick another. That said, as noted in the CAR, the team is definitely aware this is far from optimal.

 

As far as "poorly undocumented" (does that mean it's actually well-documented? ha!), I am open to suggestions for improving http://www.ni.com/tutorial/14534/en/#218506_by_Category -- let me know. My main concern is that it takes some understanding of the issue to even know how to look for documentation on it, so if you have ideas on how to more proactively document it that would be very helpful.

 

Mads
Active Participant

The project had a build spec set as startup yes, so according to your statements the fact that running a VI from this project caused the currently deployed startup app to be unset to run at startup isa bug yes...I can test it a bit more to confirm this.

 

When it comes to the alternatives you list for Stephen I have a couple of comments:

 

Option a) would not really introduce a new prompt, you already get a promt when you try to run a VI like this on a target that has a startup application running. That prompt tells you that the running VIs have to be shut down if you wish to run the VI...However it does not tell you that if you do this it will not just introduce this temporrary change (shutdown of the running VIs), but permanent changes as well. So I do not see why people should be against being told the full story in the already existing prompt.

 

When it comes to b) I think the issue should be turned upside down; if the action does not explicitly order a persistent change, tell the user that the action he is about to do will have any permanent effects - and allow him to decide if that's OK or not. The current solution assumes that the user is aware of the side-effects, and does not bother to warn about it in case that assumption is wrong.

 

 

ScotSalmon
Active Participant

Good point. Adding a little more text to the app-already-running conflict as option (a) would probably address quite a few of the cases where this is hit. No promises but let's see if we can come up with some reasonable wording. Note also that that doesn't always work: for example, if you first connect from a project that has the startup app, that's when you'll hit the dialog, and that will stop the startup app; if you then connect from a project that doesn't have a startup app, you won't get the dialog, and the startup app will still get disabled. And there are other settings, like VI Server configuration, that fall into this same bucket of things that get silently updated when connecting from a new project that are orthogonal to startup apps, so this is far from a complete fix. But, it seems like a feasible step in the right direction.

 

What we've seen with your idea on (b) is that when we add that kind of warning, users get frustrated after the first couple of times. It's great to get told what's about to happen from your action if you're not expecting it, which is the first time, maybe the second time. After getting the same warning 2000 times, I suspect people will be posting ideas here asking to remove the warning. Often the response to that concern is "add a 'don't show this conflict next time' checkbox to the dialog", but that only helps if there's only one user of that LabVIEW IDE (and they're using it regularly enough to remember), which isn't a safe assumption, so we generally try to avoid those checkboxes.

Mads
Active Participant

"...if you then connect from a project that doesn't have a startup app, you won't get the dialog, and the startup app will still get disabled. And there are other settings, like VI Server configuration, that fall into this same bucket of things that get silently updated when connecting from a new project that are orthogonal to startup apps, so this is far from a complete fix. "

 

The real goal here should be to avoid all these changes. In this case you say that the startup app is disabled even when you connect from a project that does not have a startup app (?). If the running of a VI needs all those permanent changes on the target for some reason,  it should at least be easier to revert back to the original situation. As it is now we kind of feel like we have to create an image of the target first and reapply that afterewards just to be safe, that's a tedious process just to run a VI(!)

ScotSalmon
Active Participant

While it would work to reimage the target, that's overkill; it should be enough to run the VI from the same project that you used to deploy the startup app. I do realize that's not always practical, though.