LabVIEW Real-Time Idea Exchange

About LabVIEW Real-Time Idea Exchange

Have a LabVIEW Real-Time Idea?

  1. Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
  2. Browse by label or search in the LabVIEW Real-Time Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  3. If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW Real-Time Idea Exchange. Be sure to submit a separate post for each idea.
  4. Watch as the community gives your idea kudos and adds their input.
  5. As NI R&D considers the idea, they will change the idea status.
  6. Give kudos to other ideas that you would like to see in a future version of LabVIEW Real-Time!
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
PJM_Labview

Smart switching to main application instance.

Status: New

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.



  


vipm.io | jki.net

6 Comments
ScotSalmon
Active Participant

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
Active Participant

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.

 



  


vipm.io | jki.net

ScotSalmon
Active Participant

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
NI Employee (retired)
Fail quickly would work for me.
PJM_Labview
Active Participant

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.



  


vipm.io | jki.net

gsussman
Active Participant

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.