Initialization and de-initialization

[Kevin_Price]

A lot of these thoughts & issues about "deinitialization" were illustrated and described quite well in BertMcMahan's msg #25.   Key points: *think* about which things need to happen unconditionally, regardless of upstream error state, and code to make sure they do.  And when you merge your errors together, make sure the original upstream error takes precedence in the merge.  (I got burned long ago by an Agilent instrument driver that gave the new error precedence and sent me off on a lot of fruitless investigation of the wrong stuff.  The new error that I was aware of was a side-effect of the upstream failure that their driver had suppressed instead of propagating it properly, the way BertMcMahan illustrated.   I've been real careful about that precedence ever since.)

-Kevin P

[Mark_Yedinak]

From this thread you posted the following:

"

I agree with what the others are telling you, but before you can comfortably move to state machines you need to learn how to encapsulate. And I'd know because the first two LabVIEW projects I delivered were not all too different from the, frankly, abomination of a VI that you have posted. And I was lucky enough to discover, mostly by sheer luck, the book that changed it all for me and set me on the path of implementing sustainable source code:

A Software Engineering Approach to LabVIEW, Jon Conway, Steve Watts, 2003 (that same Watts is still around on this very forum, by the way)

It will teach you how to encapsulate code into maintanable subcomponents, or as some would call it, to abstract functionality. And once I learned that, all my (nested) sequence structures disappeared, everything became readable, block diagrams shrunk and debugging became a breeze. Once you master that the transition to state machines will be all the much easier, since they are nothing more than stacked sequence structures that don't have a set sequence between the different states. Can't recommend that book strong enough to you."

If that is all that you believe a state machine is then you still have lots to learn. A statement machine is much more than simply a case structure with multiple cases. It also includes that logic and control to control the execution flow. IN your particulae case you want to know how to handle the errors which may occur during your initialization. Since the state machine controls the execution order you are in complete control over what happens when, what errors you need to propagate downstream, what errors you can handle locally and clear, and what the next operation should be. Personally, I like Norm's TLB pattern for state machines since it separates the logic of state transitions and the actions performed for each trigger within each state. You should take your own advice and do some additional reading about software engineering as recommended earlier.

[Dobrinov]

---

@Mark_Yedinak wrote:

From this thread you posted the following:

"

I agree with what the others are telling you, but before you can comfortably move to state machines you need to learn how to encapsulate. And I'd know because the first two LabVIEW projects I delivered were not all too different from the, frankly, abomination of a VI that you have posted. And I was lucky enough to discover, mostly by sheer luck, the book that changed it all for me and set me on the path of implementing sustainable source code:

A Software Engineering Approach to LabVIEW, Jon Conway, Steve Watts, 2003 (that same Watts is still around on this very forum, by the way)

It will teach you how to encapsulate code into maintanable subcomponents, or as some would call it, to abstract functionality. And once I learned that, all my (nested) sequence structures disappeared, everything became readable, block diagrams shrunk and debugging became a breeze. Once you master that the transition to state machines will be all the much easier, since they are nothing more than stacked sequence structures that don't have a set sequence between the different states. Can't recommend that book strong enough to you."

If that is all that you believe a state machine is then you still have lots to learn. A statement machine is much more than simply a case structure with multiple cases. It also includes that logic and control to control the execution flow. IN your particulae case you want to know how to handle the errors which may occur during your initialization. Since the state machine controls the execution order you are in complete control over what happens when, what errors you need to propagate downstream, what errors you can handle locally and clear, and what the next operation should be. Personally, I like Norm's TLB pattern for state machines since it separates the logic of state transitions and the actions performed for each trigger within each state. You should take your own advice and do some additional reading about software engineering as recommended earlier.

---

Not sure who you meant by that, but that was my post. And yes, in a simplified way, that is what a state machine is - literally a collection of states, that appear just like a stacked sequence structrure, on the block diagram, where each state can decide to which other state to transition upon completion. You can literally make a state machine that transitions through the states in order, i.e. a literal sequence structure, and it would still be a state machine. You can change the sequence in which it executes, on the fly. There is nothing more to it. Guess that oversimplification bothers you on some level.

EDIT: Which, by the way, is just like with stacked sequence structures, state machines are pretty crap when it comes to readability, and why the OP doesn't like them (well, at least partially), since just by looking at a state machine, you can't necessarily understand what it does, or even worse, in what order. And before you take your pitchfork, I'm not saying not to use them, I'm doing it for years, it's just that they indeed are crap when it comes to readability. But, unlike what the OP thinks, they do offer advantages big enough to offset the negatives.

[Mark_Yedinak]

---

@Dobrinov wrote:

---

@Mark_Yedinak wrote:

From this thread you posted the following:

"

I agree with what the others are telling you, but before you can comfortably move to state machines you need to learn how to encapsulate. And I'd know because the first two LabVIEW projects I delivered were not all too different from the, frankly, abomination of a VI that you have posted. And I was lucky enough to discover, mostly by sheer luck, the book that changed it all for me and set me on the path of implementing sustainable source code:

A Software Engineering Approach to LabVIEW, Jon Conway, Steve Watts, 2003 (that same Watts is still around on this very forum, by the way)

It will teach you how to encapsulate code into maintanable subcomponents, or as some would call it, to abstract functionality. And once I learned that, all my (nested) sequence structures disappeared, everything became readable, block diagrams shrunk and debugging became a breeze. Once you master that the transition to state machines will be all the much easier, since they are nothing more than stacked sequence structures that don't have a set sequence between the different states. Can't recommend that book strong enough to you."

If that is all that you believe a state machine is then you still have lots to learn. A statement machine is much more than simply a case structure with multiple cases. It also includes that logic and control to control the execution flow. IN your particulae case you want to know how to handle the errors which may occur during your initialization. Since the state machine controls the execution order you are in complete control over what happens when, what errors you need to propagate downstream, what errors you can handle locally and clear, and what the next operation should be. Personally, I like Norm's TLB pattern for state machines since it separates the logic of state transitions and the actions performed for each trigger within each state. You should take your own advice and do some additional reading about software engineering as recommended earlier.

---

Not sure who you meant by that, but that was my post. And yes, in a simplified way, that is what a state machine is - literally a collection of states, that appear just like a stacked sequence structrure, on the block diagram, where each state can decide to which other state to transition upon completion. You can literally make a state machine that transitions through the states in order, i.e. a literal sequence structure, and it would still be a state machine. You can change the sequence in which it executes, on the fly. There is nothing more to it. Guess that oversimplification bothers you on some level.

EDIT: Which, by the way, is just like with stacked sequence structures, state machines are pretty crap when it comes to readability, and why the OP doesn't like them (well, at least partially), since just by looking at a state machine, you can't necessarily understand what it does, or even worse, in what order. And before you take your pitchfork, I'm not saying not to use them, I'm doing it for years, it's just that they indeed are crap when it comes to readability. But, unlike what the OP thinks, they do offer advantages big enough to offset the negatives.

---

Yes, that was directed at you. As I stated earlier, I do not feel you are open to advice. It is clear that you believe you have all of the answers and reject what others say regardless of their expertise or experience. Clearly you think most of us are ignorant idiots who don't have a clue about anything we say. Good luck with your future endeavors.

So, your preference is a very long horizontal block diagram so it is more readable? No programming language can display everything you need to know on a single screen. In text languages the code is generally spread across many files. There is no way to show they entire thing in one shot. Same with LabVIEW. I would argue that a clean, well designed state machine is much more readable than a long horizontal block diagram that you have to scroll endlessly to look at. This is also another reason I like Norm's TLB pattern because it makes it much easier to see what actions occur for each trigger.

[Dobrinov]

---

@Mark_Yedinak wrote:

---

@Dobrinov wrote:

---

@Mark_Yedinak wrote:

From this thread you posted the following:

"

I agree with what the others are telling you, but before you can comfortably move to state machines you need to learn how to encapsulate. And I'd know because the first two LabVIEW projects I delivered were not all too different from the, frankly, abomination of a VI that you have posted. And I was lucky enough to discover, mostly by sheer luck, the book that changed it all for me and set me on the path of implementing sustainable source code:

A Software Engineering Approach to LabVIEW, Jon Conway, Steve Watts, 2003 (that same Watts is still around on this very forum, by the way)

It will teach you how to encapsulate code into maintanable subcomponents, or as some would call it, to abstract functionality. And once I learned that, all my (nested) sequence structures disappeared, everything became readable, block diagrams shrunk and debugging became a breeze. Once you master that the transition to state machines will be all the much easier, since they are nothing more than stacked sequence structures that don't have a set sequence between the different states. Can't recommend that book strong enough to you."

If that is all that you believe a state machine is then you still have lots to learn. A statement machine is much more than simply a case structure with multiple cases. It also includes that logic and control to control the execution flow. IN your particulae case you want to know how to handle the errors which may occur during your initialization. Since the state machine controls the execution order you are in complete control over what happens when, what errors you need to propagate downstream, what errors you can handle locally and clear, and what the next operation should be. Personally, I like Norm's TLB pattern for state machines since it separates the logic of state transitions and the actions performed for each trigger within each state. You should take your own advice and do some additional reading about software engineering as recommended earlier.

---

Not sure who you meant by that, but that was my post. And yes, in a simplified way, that is what a state machine is - literally a collection of states, that appear just like a stacked sequence structrure, on the block diagram, where each state can decide to which other state to transition upon completion. You can literally make a state machine that transitions through the states in order, i.e. a literal sequence structure, and it would still be a state machine. You can change the sequence in which it executes, on the fly. There is nothing more to it. Guess that oversimplification bothers you on some level.

EDIT: Which, by the way, is just like with stacked sequence structures, state machines are pretty crap when it comes to readability, and why the OP doesn't like them (well, at least partially), since just by looking at a state machine, you can't necessarily understand what it does, or even worse, in what order. And before you take your pitchfork, I'm not saying not to use them, I'm doing it for years, it's just that they indeed are crap when it comes to readability. But, unlike what the OP thinks, they do offer advantages big enough to offset the negatives.

---

Yes, that was directed at you. As I stated earlier, I do not feel you are open to advice. It is clear that you believe you have all of the answers and reject what others say regardless of their expertise or experience. Clearly you think most of us are ignorant idiots who don't have a clue about anything we say. Good luck with your future endeavors.

So, your preference is a very long horizontal block diagram so it is more readable? No programming language can display everything you need to know on a single screen. In text languages the code is generally spread across many files. There is no way to show they entire thing in one shot. Same with LabVIEW. I would argue that a clean, well designed state machine is much more readable than a long horizontal block diagram that you have to scroll endlessly to look at. This is also another reason I like Norm's TLB pattern because it makes it much easier to see what actions occur for each trigger.

---

Well, there are people that can change my mind in 5min, and others that never manage to. Comes down to the arguments one brings along (if any). If you feel treated like an idiot, then I'm afraid that is your problem, was certainly not my intention. If I regard you to be an idiot, I will call you that, don't worry.

And, you know, on one hand you claim to be treated like an idiot, but then you don't even bother reading what I wrote. Read the EDIT: part again, please. Slower this time.

[Kevin_Price]

Mark,

The person you responded to starting in msg #32 is NOT this thread's OP where you had previously assessed unwillingness to take advice in msg #16.  FYI.

-Kevin P

[BertMcMahan]

Yes, Dobrinov is advocating for the OP (Vasilich) to use state machines and said "Nothing more than..." in an attempt to encourage the OP to use them. Not to put words in his mouth but it reads to me like he's oversimplifying it a bit to get the OP to see they're simple to implement, yet can produce very complex effects. To perhaps rephrase, "State machines are easy as pie". Not "State machines are just sequence structures".

[Mark_Yedinak]

You both are correct. Not enough sleep last night. My apologies Dobrinov.

[Dobrinov]

---

@Mark_Yedinak wrote:

You both are correct. Not enough sleep last night. My apologies Dobrinov.

---

Sh!# happens.