A User-configurable State Machine Using LabVIEW

[User002]

Overview

This is an example of how to let users configure different states of a program, adjusting timing on a sequence of outputs.

Description

This code might be used in a factory or manufacturing line.  Here, the user will specify the settings for a number of on/off valves, and one variable valve.  They can be settable to the nearest 10 ms (plus or minus operating system jitter, of course).  Exposing these as an array lets the user create an arbitrary length vector of these sequence steps. each with user-configurable timing. 

Requirements

• LabVIEW 2012( (or compatible)

Steps to Implement or Execute Code

1. Run the VI 
2. Click the button"RUN" to run sequence
3. Change the state of Sequence
   
   

 **This document has been updated to meet the current required format for the NI Code Exchange.** 

[J.Harv]

Is there a potential problem with using the tick count?  What happens if the tick count rolls over in the middle? 

From what I can tell, your current time would be much less than your saved time and elapsed would always be zero and time elapsed would be false until you got up to where it rolled over (2 months or so from the time of the mistake). 

I'm implementing something like this now and was trying to avoid the tick count for this reason, what do you think?  Granted the chances of this happening are slim, it could still cause quite a problem in a released system if it happened.

-John

[User002]

When the tick count rolls around its data type, it actually is not a problem.  Try experimenting with the math with a subtract VI and a couple of controls.  As long as both inputs and the outputs are all of the same datatype, you still get the true difference of what would be the elapsed time.  It has to do with the operation being confomant to the datatype.

For a simple example, consider using a U8 count, which is valid from 0 to 254:

If you were at 250, and then you checked a handful of counts later and it was at 5, the computation would be (5 - 250).  But, the answer comes out to be 11, since the answer lies outside of the datatype range and wraps as well. 

The only time you might run into problems is if you had a step that lasted longer than a the count period of 2 months and some change.  Rolling over twice is very bad.  But once is ok.

[J.Harv]

Ah!  I understand. I didn't consider the data type, makes complete sense now. Neat.  

I ended up implementing the same thing but with a Get Data/Time in Seconds in place of the Tick Count.  I suppose they are roughly the same thing ....except if I have a time interval longer than a few months (my intervals are seconds though) I'm set! 

Thanks for the quick reply!

[User002]

That's the difference - the Tick Count will give you (roughly) millisecond resolution, as opposed to second resolution.  I had in mind an application that was looking to get around 200ms for most operations.  For sequence states that have step sizes with a whole number of seconds, what you have will work great! 

No problem!