Agreed. Or at least show it only on the diagram window and not on the front panel.
After all, it's a debugging tool, mostly to quickly play with controls and probe wires, etc. on a subVI that typically does not run as toplevel and thus does not have a while loop.
>>> Actually, I use it quite often. Sorry, no kudoos...
There is no good excuse to use "run continuously" except for debugging.
When using continuous run, the program does not really run continuouly like in a while loop, instead it simply automatically restarts whenever it is done. Also since there is typically no delay on the top diagram, it might use all CPU for no reason.
There are clear differences in behavior, especially with globally initialyzed feedback nodes and "first run?" primitives, so "run continuously" is not the same as run with a while loop encompassing all code.
If you do any kind of instrument control or DAQ, the instrument is typically initialized once before the loop. Do you really think you need to configure the serial port with the same parameters millions of times per second?
I would strongly recommend to lose your bad habits if you ever want to get a job in the industry. 😉
>>>There is no good excuse to use "run continuously" except for debugging.
I agree.
It's just that in our research-like department we always work in the LabVIEW development environment and we need to be very flexible w.r.t. to our experiments .
Depending on the outcome, experiments tend to change (with some exaggeration ) almost by the minute.
So we change code instantly, which often requires (some) debugging. "run continuously" may come in handy when checking (part) of the code.
(BTW we always double check the data sent to disk used for experiment analysis).
I think it is different from developing a well organised and structured program where the requirements and goals are clear beforehand, and which has to be (formally) delivered to a customer. Don't worry, occasionally we have these requests and then we start thoroughly with an architecture.
LabVIEW has two groups of users, what I'll call "engineering users" and "programmer users", and they are almost equal in number and they have exactly opposite expectations of LabVIEW. NI recently did a user survey of "what do you like" and "what do you dislike" about LabVIEW. This survey showed the divide is as strong as ever. The same features were on both lists, in about exactly equal number, splitting our user base. What one group liked, the other disliked, and vice versa.
Run continuously is used a lot by engineering users. They write DAQ Start, Read, Close, get it configured, and then use the existing button bar to run once, or run many. They aren't writing a while loop and a stop button. If that sounds like a trivial small burden to some of you, then you're a programmer user. Removing the Continuous Run button would definitely be a pain for the engineering users. I think moving the button would be ok, as long as it didn't go too far away. Maybe just some whitespace between them?
Maybe the "run continuously mode" should also include an implicit 10ms way between atomic runs in order to plays nicer with everything else running on that rig. That might however be a seperate idea. 🙂
The NI solution to the "user divide" seems to be surveys and meetings to determine which half of the user base to annoy for each given feature. My solution would be to make LV as configurable and flexible as possible. For instance, in this case if we were simply able to specify a .vit to be used as a template for a new vi we could hide or unhide that button as we desire (and tweak many other things as well). Yes you can create the same template and always use "New..." menu, but that is slower and more clicks.
In this case I am a Ctrl-R'er so I do not have problems with hitting the Run Continuously button, I used to Tile windows now and then, but that shortcut is long-gone in my IDE.
> For instance, in this case if we were simply able to specify a .vit to be used as a template for a new vi we could hide or unhide that button as we desire (and tweak many other things as well).
You can do that. If you create a VI called lv_new_vi.vi in the LabVIEW\resource\plugins folder, it will be run each time you press Ctrl+N. You can use that to instantiate your VIT and then dismiss the untitled VI. This isn't fully documented, but you can find some details here.
