Initialization and de-initialization

[Vasilich2004]

Hi All,

My program, usually, initializes everything at the beginning of program and de-initializes at the end. A picture below shows this idea. If any item during initialization would give an error then rest of code will not work and  initialized items will not be de-initialization.

It is possible to check "references" but sometimes it is not helpful. For example, file reference isn't defined if the reference wasn't used.

If somebody uses the same approach, please, share your technique.

Thanks, Andrey.

[altenbach]

Your picture is probably too simplified to give detailed advice.

• Why don't you carry the error across the middle frame?
• Instead of a sequential "worm" of a program, we typically prefer a properly architected state machine where initialization and shutdown code are just defined states.
• Typically, sequence structures are not mandatory once states and dataflow are well organized.

[Vasilich2004]

sure, it isn't real program. it just show an issue. so

- Middle frame is place of code which make something

- sequence isn't important. it just shows program flow. real VI is showed below.

- state machine has similar issue or it should take care about initialization of each item and store initialization result somehow/somewhere

[RTSLVU]

Your architecture is flawed from the beginning because you used a Sequence Structure.

Error or not you are stuck in that sequence, there's no way out. 

Consider a simple State Machine with sates such as:

1. Initialize
2. Do something
3. Do something else
4. Error
5. De-Initialize

Now an error occurring in any state can skip al the other states and go directly to the Error state where your program can display an error message then go to the De-Initialize, Of course if there was no error then you would simply skip the Error state.

OMG I just saw your next post and I must reaerate Your architecture is flawed 

BTW: A State Machine would store initialization information in a Shift Register so it can be passed on to other states.

[Mark_Yedinak]

Why are you using terminals and local variables for all of your references? The user will never need to se them so there is absolutely no need for them to be indicators. Use a cluster or clusters (depending on how things should be grouped logically) and pass them through your code using a wire. As suggested, you should really be using a state machine for your code.

[Vasilich2004]

The simple State Machine doesn't help.

Program should do something in Error and/or De-Initialize state.

If program doesn't return resources, for example, COM port async running VI then LabVIEW framework has issue.

[Vasilich2004]

I could avoid Local variables but Block diagram will get the same amount of long lines which are also don't look well! If program would be written in State machine architecture it will be the same question - additional Local variables vs additional lines. Moreover in State machine will have additional variable or line itself!

By the way,:

- I don't know how to combine State machine and Event structure

- my program uses few Start Asynchronous Call Nodes which vi could be inserted as Subpanel. This approach allows to avoid code duplication in Top VI.

Recently, I read that LabVIEW 2021 will not show hidden Local variables during Run!

[altenbach]

---

@Vasilich2004 wrote:

Recently, I read that LabVIEW 2021 will not show hidden Local variables during Run!

---

It is not clear what you mean here. You are probably talking about controls/indicators, and if they are hidden they will not show in any LabVIEW version. Local variables are only visible on the diagram and just provide secondary terminals to wire to these front panel objects.

Wires will never be long if the diagram is kept at a reasonable size and has a clean architecture, so focus on that. 😄

[RTSLVU]

@Vasilich2004 wrote:
The simple State Machine doesn't help.

That's only because YOU don't understand them. I have been doing this for a long time and probably >%99 of my programs are state machines.

Also I might add, many of the more complex architectures like Producer/Consumer and Queued Message Handler are a State Machine at their core. 

Program should do something in Error and/or De-Initialize state.

Then make it "do something" in those sates 

If program doesn't return resources, for example, COM port async running VI then LabVIEW framework has issue.

No, your programming has issues such as, you are not closing the VISA sessions or other instrument handles properly if it is not returning resources.

[Dobrinov]

---

@Vasilich2004 wrote:

Hi All,

My program, usually, initializes everything at the beginning of program and de-initializes at the end. A picture below shows this idea. If any item during initialization would give an error then rest of code will not work and  initialized items will not be de-initialization.

It is possible to check "references" but sometimes it is not helpful. For example, file reference isn't defined if the reference wasn't used.

If somebody uses the same approach, please, share your technique.

Thanks, Andrey.

---

I sort of "solve" the same problem in that I use a self-made Error Logger VI, which logs every single error, in multiple key spots on my block diagrams and has an input that allows me to choose whether to clear the errors in it, or to let them through (sometimes you want them to propagate). Here is what the "end" side my bigger VIs looks like:

The "red" VI would log any error on the wire and clear it by default. This way the error information is not lost, but logged, and the error doesn't prevent anything from deinitializing. The Merge Errors on the leftmost side collects any errors leaving 4 relatively fat state machine loops, to give an idea. Normally no error would manage to leave those as any errors in them would get logged and cleared the same way, but better to be safe than sorry.