LabVIEW
Automating mass flow controller
Solved!
Just in case you didn't already find it, here's a link describing State Machines.
LabVIEW frequently markets itself (actually, I suppose more accurately NI frequently markets LabVIEW) as being easy to get started with and quickly get things running, but this can lead to quickly causing yourself future problems (I did this a lot, and still do this all the time - sometimes you just need to do it again with the knowledge from the first attempt).
This does mean that it's good to try and follow "best practices", as they were, as soon as you find out about them, and all the time (not just when you think it will be a big project, or when you're not in a rush, etc). Of course, this would be more useful advice if I had a link to a list of best practices 😉 (maybe someone else actually does...)
One "best practice" I'd suggest with regards to the VI you attached is the use of Type Definitions (you're using 2017, so create a Control and then change the dropdown box near the top) to define your enums. This makes it easier to change them later (to add more states, etc). I didn't do this for a simple example recently and was kicking myself as soon as I had to change it...
Another option might be to try and avoid the use of Local Variables except where definitely needed. In your VI you have two controls and two indicators (initially I missed that they were not the same thing due to the similar names) and you use the local variables to get the last value of the Time Target. You never Reset the timers and the behaviour is a little surprising. The "non-active" timers keep going around and so depending on the two timers, you can get unexpected results. Moving to a slightly more complex state machine might help you modify this, but actually you can probably achieve your goal with a feedback node between Time has Elapsed and Reset on each case. Removing the Local Variables will only make your code clearer (I was initially surprised that I could update them after starting the VI, because I saw the terminals outside of the loop).
Conversely, you can populate the boolean indicators by moving them outside of the case structure (but still inside the loop). Then you won't need the Value property nodes.
I don't really suggest this as a best practice, but the elapsed time Express Node can I suppose be useful and the confusing behaviour you've stumbled on is a consequence of the Auto Reset functionality. You need to manually reset only when you reach the end, but if you do it in the same iteration (of the While loop) then you'll have auto-reset behaviour. You need to reset in the next time that that case is called, i.e. the first iteration of the next "Regeneration" case (for Regen, the other for the other). A feedback node allows a value to be propagated forward in time from the previous time it was called (and by using two separately, this is not the previous iteration, but the previous (last) in the same case).
To make your feedback nodes look like this, I right clicked and chose "Change Direction". This has no effect on the execution, but changes the appearance. You might prefer the default, I often find when I use them I prefer this way around. I initialise with True because I want to reset on the first call.
Please let me know if that isn't clear (or perhaps what isn't clear) and I'll try elucidate.
