From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
startup event?
Solved!
@altenbach wrote:
The continuous run button is a debugging tool, not something to use for regular operation, ever!
Simply place a while loop around your code and wire the startup code so it is executed before the while loop starts. That's all!
Ok! I just got it, could you please confirm once again, like this? 
Yup, something like that and as i mentioned in my first post, now your starting 'event' is outside the while loop. 🙂
The event structure you posted is usually placed inside the main while loop since it only executes when some action happens, as a button press. Since you have the 100ms wait (good call, many forget that) you wont panic the CPU, though often/most of the time you only want/need to perform an action when a Control is changed or a button pressed, or in the case of keeping indicators updated with a timeout. That's when Event structures are superior.
/Y
@Yamaeda wrote:
Yup, something like that and as i mentioned in my first post, now your starting 'event' is outside the while loop.
Ty, got it now but it wasn't that clear to me in the beginning.
@Yamaeda wrote:
The event structure you posted is usually placed inside the main while loop since it only executes when some action happens, as a button press.
yeah, I got it through a series of experiments with another vi, if it's placed outside the loop, the program just freezes. the other thing I had to discover is that it is nessesary to add a timeout event with a "0" value wired to it, or again all the other controls will freeze during execution.
Nevertheless I abandoned event structure in this vi, and replaced my string control with a list box and an array of values, so that all the different S/N's are being listed in the beginning and then the user can simply select an S/N.
@Yamaeda wrote:
though often/most of the time you only want/need to perform an action when a Control is changed or a button pressed, or in the case of keeping indicators updated with a timeout. That's when Event structures are superior.
As far as I think I understand it correct, or I may not, there is no difference in performance between an event structure set on a value change and the comparison of a value of a control by the means of the shift register and an attached case structure to it? - and this is just what I have implemented here. Or is there?
No, there's no penalty to the comparison. It is however rather common to have a loop that updates everything every X ms when there's really only 1 or 2 things that need updating, and those are often only needed to update every 10 sec.
Stopping the VI through Abort is not a clean solution though, change that F constant to a control. 🙂 (put in it's own Value change event and wire the New Value outside to the Stop loop) 😉
It seems you're only saving when you press the OK-button, that's a perfect candidate for a OK-button value change event. 🙂 (the full upper case)
The lower case could be in the timeout event (with the 100ms timer).
The diagram will be smaller, more organized and you'll more easily find the operations for future modifications.
Bonus: If you want to clean it up even more you can register a User event - Init which you generate at start and in which you perform your outside initialization.
/Y
