Help with recording measurement

[Ayin]

Hi all,

I'm trying to take voltage/current/resistance measurements from a Keithely sourcemeter and plot them on charts. There's also the option to record the measurements upon pressing the "record" button, which then would prompt the user for a path name. After the 'record' button is pressed again, the file is saved and closed. During the entire process of openning file, recording, and closing the file, the measurements should be plotted onto the charts uninterrupted.

I've used a state machine pattern, with the value of the 'record' button as input to decide the state transitions, used in a "select" gate. However, when I run the VI, the state transitions never happens, pausing the execution and probing the value of the button yields that its output stays the same regardless of the state of the button.

I've set the operation of the button to "switch when pressed". 

I know this is a common task, but I'm pretty stumped about how to fix this. The VI file is attached, any pointer is appreciated.

Thanks

[johnsold]

Ayin,

I can tell you why the state machine is not working.  When you get it working, I am not sure it will do what you want.

The clue is the coercion dots on the Select inputs in the case structure.  Your "state" enums are all different datatypes! The one outside the loop has four values.  Each of the ones inside has only one and most of them are different from the others.  With the Context Help window open, move the wiring tool cursor over the wires coming from each constant and notice that the data descriptions are different.  This is why it is recommended to make the state enum a typedef.  When all the constants are derived from the typedef, any changes automatically propagate to all of them.  It is also useful to name the elements of the enums with the names of the states. You could have 0 = Idle, 1 = Open, 2 = Save, 3 = Close. Those names then show up as the selector labels of the case structure so you can tell at a glance what state you are looking at.

Lynn

[Ayin]

Hi Lynn,

Thanks for the reply.

I'll make the enums typedef. But when you say any change in a typedef will propagate to all the enums, you mean the range of values, but not the actual value of the enum constant right?

Also, I originally have all the different states named with descriptive names. However, at some point, the case-display of the case statement loop started only displaying numbers instead of the state descriptions. I couldn't figure out a way to correct that, so I changed all the other enums to numbers.

How can I make the case statement behave again?

Thanks,

Al

[JÞB]

I think Lynn tried to explain- 

Make a type-def of the enum.  You want 1 type def!  Then replace all the constants that wire to the case selector with instances of the new enum.  Now the data types are all the same and LabVIEW does not need to coerce the values.  the case text went away the first time you changed 1 constant and forced LabVIEW to treat all the enums by value (Since they then had different texts)

[johnsold · Accepted solution]

The typedef enum will solve the problem of the names.  Once all sources (controls or constants) connected to the state wire in every case and outside the loop are all copies of the same typedef, the names will return.

What happened was that you changed one of the enums or created a new one.  It had a different data type.  Yes, it was still an enum and still produced a U16 integer, but because the items in it were different, it was considered a different data type.  When two different data types are connected to the wire going to the selector terminal, the case structure attempts to find the common "denominator", in this case a U16 integer, but not the enum.

I converted the enum constant you had with "record" and other values to a type def and copied it several times.  When I replaced all the other state enums with that type def enum, the names came back.

Lynn

[Ayin]

Hi all,

Thanks for the prompt help, everything now works perfectly. Labview actually makes sense now!

Al