Smart switching to main application instance.

[PJM_Labview]

I do not know about most people use cases with RT system, but I have the reflex to click the run arrow to test all my VIs. When I am on site and I do have access to the hardware, everything is rosy. But, when I do not have access to the hardware, and depending on the system complexity, I now have to wait up to over a minutes before I can resume working. It would be nice if somehow once I realized my mistake I could notified LabVIEW (right away) to run my VI in the main application instance instead of attempting to deploy it on the missing target.

Alternatively, once I made the mistake once, LabVIEW could automatically run the VI in the main application instance.

I do not know what is the best approach to fix this, but I know that I am very annoyed every time I make that mistake.

[ScotSalmon]

---

PJM_Labview wrote:

LabVIEW could automatically run the VI in the main application instance.

---

 

I definitely agree that it takes too long to even get to the point where you can cancel the "run" operation on a non-responsive target, especially for large applications.  But I don't think having the RT application run in the main instance is a good idea.  For testing your logic, etc., it is useful to run parts of the RT app in the main app instance, but in some cases switching where your code runs "automatically" could have undesirable side effects.  Imagine an app which publishes I/O data from RT to the network -- if the app ran on the main app instance sometimes, network data from that run would be bogus (since the I/O would be unavailable) and the consumer on the network wouldn't necessarily have a way to determine what happened.  I suspect there are many examples where "automatically" switching to the main app instance would be problematic.

-Scot

[PJM_Labview]

I can see that doing this automatically (without telling the user about it) might be a bad thing, but there might be a middle ground where this could be done to the satisfaction off all.

If LabVIEW would just indicate to the user that it switch to the main app instance because no hardware has been found (and warn the user that there might be unexpected behavior by doing this) this would be fine (note: If a dialog is used to do this, a "do not show this dialog again" would be nice). Additionally, this option to automatically switch to the main app instance could be enabled/disabled through an ini option.

[ScotSalmon]

I guess what I am really wondering is, would you find this auto-switch behavior actually useful, or is it just that it's better than waiting around for a non-responsive target?

Because if we can get it to quickly detect the non-responsive target case for purposes of switching to the main app instance, that means we could have given you the "couldn't connect" dialog quickly instead.

That's really the main problem in my experience -- takes too long to fail.  If it would just fail quickly, that would be okay for me.  You?

[jkurtw]

Fail quickly would work for me.

[PJM_Labview]

Definitively. The "fail quickly" will work just fine for me as well.

It is all in the definition of "quickly". For me less than a couple of seconds would be ok.

[gsussman]

This is something that "chaps my hide" as well.

I think the normal scenario that PJM is referring to is when developing code offline (in the office) when the target is nowhere to be found, and not when you simply want to run the code on the windows target while the RT system is available. 

One approach that might work is to provide an initial prompt the first time you attempt to run on an RT target. Something along the lines of:

"Do you wish to connect and run code on the target device" 

Answering "Yes" to this prompt would cause LV to operate the way that it does today. Running any VI targeted to the RT system would attempt to download and run it.

Answering "No" would cause all future attempts at running on the RT target to be automaticaly redirected to the "My Computer" target. LabVIEW would stay in this mode until it is restarted or the user switches the mode under the target properties.