Simple State machine

[MogaRaghu]

I have been reading the application notes on State Machines including this one :

http://zone.ni.com/devzone/conceptd.nsf/webmain/C74CEC177A289DBD86256C4E00600196

But most of them use shift registers to pass on the next "state".

I just put together a simple SM using a local variable. Is something wrong with this approach or are there some pitfalls ?

( Coded on LV7 )

Thanks

Raghunathan

[altenbach]

LabVIEW is a dataflow language and the wire is the most efficient way to transport data.


This discussion comes up once in a while. here's a recent thread worth reading. Enjoy!

You can see for yourself: If you redo your exact code with a single shift register an NO local variables (see attached, LabVIEW 7.1), the code is 40% smaller (7.9k vs 13.7k)! 🙂 (Also notice that the stop button is now set to latch and will automatically reset once it is read by the diagram, no need ot reset it with a local variable.)

Obviously, you are coming from a text-based programming background. It would be important to rethink your approach before starting with large LabVIEW projects. Dataflow is extremely powerful and you should definitely embrace it. It will make LabVIEW programming much easier.

Local variables also make extra data copies, which is not a problem in your tiny case, but could be an issues if you are dealing with large data arrays.

Also, imagine you have 20 indicators that need to be updated. If by accident you would forget to update one of them in one of the cases, it would be difficult to find the problem with your programming technique. Im my example, you would immediately see that one output tunnel does not receive data in all cases because it would show as hollow.

Message Edited by altenbach on 05-29-2005 10:20 AM

[altenbach]

Another problem with your programming style is the fact that you cannot know what happens first:
(1) writing of the zero to the "numeric" local variable on the right OR (2) reading the "numeric" local variable in the while loop. There is no data dependency defining the sequence of these two events. Looking at the code, one might think that (1) happens at the end of the run, but it actually happens at the beginning. (After the program finishes, the indicator contans a "4", not a "0"!). In the worst possible case, it could even happen during one of the other states (e.g. during state 2), causing unpredictable or unexpected results. The sequence of events might change in the future as the VI grows when you add more and more code, when you convert it to a new LabVIEW version, etc.

[MogaRaghu]

Hello Altenbach,

Yes you are right - I defenitley am migrating from a VB and C environment and variables have been my bread and butter till date. And as I am still coding for some projects in text based environment, the "dynamic switch" is something my brain ( hope its still there ) finds difficult to adapt.

I saw your SM with no local variables. Agreed - a defenite upgrade and an elegant method. I have now brought two more real time requirements :

1. A specific time delay for transition from state_01 to state_02. I do suppose that here the local variable is unavoidable !? ( as I can't use the other regular time delay functions inside a timed loop ?)

2. Wait for user input for transition to state_03. In a machine this can be a hardware based input.

But my real time state machines are a whole lot complex. Digital inputs are in the order of 30 to 40 and outputs about 10 to 20. And numerous time delays, real time plots , decisions, verdicts etc make life tough and more important make the VIs very large - for instance in most of my codings I can't see all of timed loop in a single screen!

But thanks to your tip, I can atleast now do away with the global DI and DO array and handle it the way you had shown.

I am enclosing the modified SM code for any possible improvement..

Regards


Raghunathan

[altenbach]

Yes, you still don't need any local variables. Again you are creating an unpredictable race condition in case 1: There is no way to tell if the delay is first decremented OR first compared with zero, the outcome is uncertain within one count. (For safety, I would always check for "less or equal than zero". If this race condition occurs, it could actually happen that zero is never checked and it will continue to count to minus infinity" ... or the I16 equivalent ;))

[MogaRaghu]

---

@altenbach wrote:
Yes, you still don't need any local variables. Again you are creating an unpredictable race condition in case 1: There is no way to tell if the delay is first decremented OR first compared with zero, the outcome is uncertain within one count.

---

Now this is getting to be interesting.

> I know I should have created a "flow" or data dependancy by enclosing the decrement and compare functions in a flat or stacked sequence. That was a slip.

> But now with the delay loop being handled by a shift register, the situation is much more elegant.

> Just to make sure that the idea sinked in proper, I tried using the SAME shift register to create another delay between states 3 and 4. It works fine. The only issue here is that I should remember to "load" the required delay count ONE state ahead of the state for which I need the delay. I guess there is no way out of it.

I now have a feeling that the idea of "the wire is the variable" is starting to sink in me. Thanks for your efforts.

Raghunathan