I posted a while ago about a thermo cycler program that was very tedious code wise and I have restarted my coding using sequence structures and local variables. So far I am pleased with the results except I am having a hard time looping a flat sequence structure properly. Attached is the vi I am practicing on, as one can see I am allowing the user to select how many times the second sequence repeats. The problem is that only one while loop in the nested sequence structure repeats and not both nested while loops. If any could shoot me some advice or help I would greatly appreciate it.
Solved! Go to Solution.
Please start again. Sequence structures and local variables cause far more problems than they solve, especially for beginning programmers.
Look at the state machine architecture. At the most basic level it consists of a while loop containing a case structure and shift registers. With a state machine you can easily do everything you are trying to do without the need for any local variables or sequence structures. State machines are more extensible, more robust in the presence of errors or dynamic changes of the status of the system, and more easily maintained than the way you are now trying to do things.
Go through the LabVIEW tutorials to help get you started.
Thank you both for the quick response,
When I look at the tutorials, all I see are examples based on a user interaction with the program. In my real program, not the test, I wish to input 5 temperatures(5 states), each with their own incubation time, p, i, and d controls. Each of these values specific to a certain temperature will be applied to a greater program as input parameters only when there state is called. So a state machine does make sense, however I would still need exterior logic outside of the machine in order to have the state machine run the temperature states as : 1, 2,3,4, 2,3,4 2,3,4 5 end. I think this is clear. I want the state machine to function without user input and I want the states 2,3, and 4 to cycle for a given inpu value i.e. 3 as seen above.
Any advice/specific tutorials for something like this? What structure does one suggest I use to run the logic for state selection?
A state machine does not require it to interact with the UI. In fact, most state machines don't do much on the user interface. A well designed state machine can still do what you want and can get input from outside the state machine (via a queue or notifier) to specify things such as starting or stopping a particular test run and providing the parameters for the test. The state machine could also be written in such a way that it does not rely on any user interaction at all. Once the application starts it could read the test parameters from a file and then process them. Your state machine would contain the logic indicating what the next state in the processing is as well as the logic to determine when to stop a cycle and move to the next phase.
Since the example you posted is not labeled I am not clear exactly what your states (1,2,3,4, etc.) are. I suggest that you actually put pen to paper and define what states/actions you need and what events will cause the transitions. For example one of your states might be "Set Temperature" (Hint: you should use a typedefed ENUM to define your state names) and it might have logic to set the next state to be "Set Temperature" if you have not reached your set point. If you did reach your set point the next state might be something like "Take Readings" or "Incubate". Your state machine should be written to allow these settings to be variable. I do not mean LabVIEW local variables but not be constant values. This way you can use different sets of parameters with the same state machine.
If you do require user interaction then I recommend you look at the producer/consumer architecture. This is basically two parallel loops (tasks) with one servicing the UI. This loop will contain an event structure. The consumer loop (task) is generally written as a queued state machine. It can accept input from the producer (UI task) for things like start and stop a test. A message could also be used to pass in the test parameters. The consumer loop (state machine) would then process that and cycle through your states.
For something that specific you will probably not find any ready-made examples.
The Producer/Consumer (Events) Design Pattern is a good way to set up the part in which the user enters the parameters. The state machine can be in the Consumer loop. I might make an array of temperature setpoints and the associated parameters. Then each time the system completes one stage it reads the next temperature and operating parameters from the array. If the program will take hours to run, the parameters could be stored in a file so the data does not get lost in the event of a power failure.
This may not be a particularly difficult program but it will require much attention to detail to get it right. I recommend very strongly that you carefully document the operational requirements and then design the program before you start coding.
A note on semantics: I would not call the temperature values "states." Unless this is a requirement of whoever will be using the system, this terminology will end up confusing you. When you are talking about state machines, the state refers to a portion of the program. It is likely that the machine will be in the same state (regulating temperature at a setpoint for a specified time interval) for each of the different temperatures. I would call them temperature stages or something like that.