LabVIEW
Initialization and de-initialization
I am going to give you a simple example of a State Machine. Maybe this will give you some ideas on how to refactor your code to a proper program architecture.
First we initialize a WT1600 power analyzer
Next we initialize a WT230 power analyzer
Next we open our data file
Then we take a measurement
Then we go to the Timer state and wait for time to elapse
This is the part I want you to understand since your first question had to do with error handling.
Where the instruments are "De-initialized" and the data file is closed
An error message is displayed and the program exits after the error is acknowledged.
Now I did not go into a lot of detail or show every single state as I wanted to keep it simple.
But if you have any questions feel free to ask.
your example of State machine is not helpful. Wt1600 initialization takes resources at first vi in line and there isn't another vi which takes resources.
let's look your Error state. If error would happen in WT230 close then WT1600 close and file close will not do anything and resources will not be clear! This topic is really about this!!!
your program is pretty simple and you use single top vi. in anyhow, state machine approach has few issues
1. all items, like wt1600, are not visible at glance. programmer needs to click multiply times to find out
2. programmer should keep all information in memory. let's say program has 100 items, initialization order is hidden and it is easy to miss initialization of couple items
3. debugging requires many extra clicking
in anyhow, state machine or not is preference of each person.
to give you chance to think a little instead blind follow pattern 😉 i placed couple block diagrams
1. Wash initialization vi. Wash uses 2 valves and 3 stages. The stages are shared with other items. It shows why there is extra reference (I created topic but nobody wasn't able to improve)
2. Wash has task which work with top vi and multiple other tasks. It shows how to simplify top vi instead of put everything in "State machine" 😉
if i would follow your approach my top vi will have few hundred states 😉
@Vasilich2004 wrote:
2. No, you are incorrect about "Wires will never be long if the diagram is kept at a reasonable size and has a clean architecture, so focus on that."
The longest horizontal wire segment can never be longer than the width of the diagram. 😄
With a wire, you always know where the data is coming from, where it last got updated, and where it is used downstream. With local variables, you can never be sure unless you sprinkle an unhealthy amount of sequence structures everywhere. Besides, you get extra data copies in memory.
(I typically keep most process data in a cluster held in a shift register and updated using bundle by name. One wire, unlimited number of "variables" and self documenting as long as the cluster elements are named well. If a function need parts for processing, I unbundle by name.)
Actually I have one more thing to add:
If you think a State Machine is hard to understand or troubleshoot. Just wait until you are handed some code that looks like this and told to fix it.
I literally had to spread this stupid block diagram out over THREE 27 inch monitors to see it all and screen capture it.
THIS is the direction you are heading and THIS is why we are trying to tell you now that you are doing it wrong.
i use shift register as minimum as possible. to reach that i use object-oriented approach (but LabVIEW object-oriented vi). of course, i use clusters but again those are trade!
examples of good usages of shift registers and clusters 😋
