state machine analogue output with datalogging wont save properly

[GerardMc]

Hi everyone,

I've been using Labview for a few years but mostly simple DAQ Assistant based logging of thermocouples and low level voltages.

I am now attempting to control a cyclic experiment where I want to alternately cool and heat some samples for N cycles, then take data measurement scans, then resume the cycling.  I have managed to get the analogue outputs working fine using a state machine, so I can command "cooling" and "heating" functions.  I'm using Compact DAQ.

I think my vi manages most of this, but with 2 problems immediately apparent, and one further question...

1)   My COOLING and HEATING times appear to be mixed up.

2)   I would like to perform 2 scans but can only manage one scan, I want to perform the first scan when "N" Cooling cycles have occurred, then another scan when N heating scans have occurred, so that both scans record minimum and maximum temperatures.  My program only seems to accomplish one of these.

3)  Why is it saved as a ctl file, and not a vi??

I would be grateful for any pointers, and any shortcomings you see in my first attempts to use the state machine.

Thank you in advance....

Gerard

[GerardMc]

For clarity, I attach a block diagram of what I am trying to achieve. 

Thanks in advance..

Gerard

[Mark_Yedinak]

Then implement your state machine as such. You have your scans running in parallel to the heating/cooling cycles and are not controlled as to when they actually take the scans. If this is what you want they should be in their own independent tasks and not be within the loop with the state machine.

Also, it is not very effecient to copy states and simply rename them. Imagine what would happen if you had to save your data 1000 times. Do you really want to have 1000 states that do the same thing? You are much better off having one state that takes some input parameters that replace all of those copies.

[GerardMc]

Thanks for your tips Mark,

I had placed the scans and saves inside the state machine earlier, but this did not work at all.  I will try it again, and persist with it a little more.

I made the duplicate "scan" and "heat" states to circumvent the "next state condition" as I didnt want them to just go back in the heat/scan states in a continuous loop.  Like.... I want to COOL followed by HEAT" say 99 times.  Then on the 100th time, I want to COOL but instead of going straight to HEAT, run a scan, then after that scan, proceed to HEAT.  After that last HEAT (N=100) go to another scan, and back to Ready, then run the HEAT/COOL cycle again.

To get around this, could I count the number of individual "COOL and "HEAT" states enacted?  Then create the next state depending on elapsed number of "COOLs or HEATs?  I'm not sure how to do this?

Best regards

Gerard

[crossrulz]

---

GerardMc wrote:

To get around this, could I count the number of individual "COOL and "HEAT" states enacted?  Then create the next state depending on elapsed number of "COOLs or HEATs?  I'm not sure how to do this?

---

Store the counts in shift registers, use a comparison of some type along with a case structure or select function.

[GerardMc]

Thanks Crossrulz,

Thats what I have kinda done already, except for the final COOL and HEAT cases, where I proceed to run 1 scan after each of these states.

I have implemented Marks suggestion and placed all my scans in the state machine.

While the program still seems to be able to give analogue outputs, and receive inputs during the scan, the order in which each state executes is not progressive.

It progresses to the wrong states, and may end up freezing with an output condition (say HEAT on), something I dont want.  On other occasions it messes up the first iteration timewise and order wise, and if it proceeds to the second or subsequent iteration, the order is correct but the timing is incorrect.

I attach my updated program, and invite any comments or suggestions.

Regards

Gerard

[Mark_Yedinak]

Your two save states are identical with the exception of the next state to be called. This time of thing should be avoided. You can resolve this by either making your save state a subVI and simply call it when appropriate or modify it to either accept an input indicating the next state or create the logic to determine that. Duplication of code should be avoided since it quickly becomes a maintenance nightmare.

[GerardMc]

Thanks Mark,

I will try to create some differences in that save routine, or as you say, transform them into a subVi.

I just had a chat with another fellow in my dept, who also recommended the use of subvi's.

He also suggested I had implemented way too much too fast into my code.  Therefore I am going to re-build my program from scratch, testing it every step of the way before adding more features.  Thats the plan.

I will report back when I get a better outcome.

Best regards

Gerard