User defined sequence (array of clusters) with relatively long software-timed loops.

[J_Hammond]

Hello and apologies in advance- I'm an infrequent LabVIEW user.

Current working on a VI to control a peristaltic pump and valve to be used for controlling some microfluidics for a nanogap biosensor. I have the pump and valve working manually (i.e. I adjust values on the fly) but I am now trying to allow the user to define a sequence of steps that are then executed one after the other.

User inputs: valve number, flow rate, duration, pump direction (boolean).  Ideally the user can then run several different steps by adding more steps, so I was thinking of an indexed array of clusters with each element representing a step? 

I would like the user to input the duration as minutes and seconds. The minimum duration will typically be 30 s and could be as long as an hour. I am unsure of the best strategy for the timed loop as I understand using the 'wait (ms)' block can cause issues. I thought about getting a time stamp, adding a value to it and comparing? Are there any other suggestions?

Any advice would be appreciated.

I am using a USB-6009 DAQ.

P.s. The LabVIEW  VI is likely an education version so may cause issues when opening?

[James.M · Accepted solution]

Are you asking just how you should architect your code? Using an array of step parameters is an easy eay to do it. And the Wait isn't necessarily a bad thing, it just depends on your aplication and if you need the timing to be exact in a certain way. You can use the Wait Until ms Multiple instead for synchronization.

You can lookin in to a State Machine architecture to make the best user interface functionality.

The Simple State Machine template that ships with LabVIEW is really the best way for new developers to get familiar with LabVIEW while utilizing a semi-scalable architecture.

Here's a broad example of how a state machine works:

• States: Init, Idle, Exit, DoThing1, DoThing2, DoThing3
• Each state contains code that might take some time. Ideally, not too long because that's how long your code could be unresponsive.
• The Idle state contains an event structure for all user interaction.
• The front panel has a button that says "Do Thing 1".

1. Loop Iteration 0: Application begins, first state is Init. The Init state does some initialization stuff and tells the application to go to the Idle state when finished.
2. Loop Iteration 1: Application goes to Idle state. It sits there, waiting at the event structure.
3. Time goes by, then user presses button "Do Thing 1". There is no code, or minimal code, within this event case. The output of this event state tells the application to go to the DoThing1 state.
4. Loop Iteration 3: Application goes to DoThing1 state. There is code here that does some stuff. The output of DoThing1 state tells the application to go back to the Idle state.
5. Loop Iteration 4: Application goes to Idle state where it waits at the event structure again.

• Each of the states can tell the application to go to any state they want. Want to reinitialize? Go to the Init state again. Want to end the program? Go to the Exit state. Want each state to trigger another (like a sequence)? Have DoThing1 output DoThing2, which outputs DoThing3,  which outputs Idle.

You can create a State that runs the input configuration cluster and operates. The risk with a long Wait is that the code will not be able to receive user input during that wait period. So if you are doing a long wait, you can use an Elapsed Time VI to check repeatedly if the wait is over. 

[J_Hammond]

Thanks James.

I managed to implement a state machine as you suggested. You're correct- the wait isn't really an issue. We're likely to set up the sequence of 5-50 steps and leave overnight to run the tests. I now have a for-loop that iterates on the index (step number) of the array of clusters (step settings). I then use a flat sequence to ensure that the pump is turned off whilst the valve is switched to the new position. The pump then runs for the target time using a 'wait(ms)' timer.

I now have a new issue where I don't appear to be able to update a DAQ output. I think this may be due to the way I have set up the timing control.

I would like the user to be able to select/deselect a 'recirculate' function whereby the pump oscilates between forward and reverse (TTL logic so using booleans), at a fairly low frequency, say 0.2 Hz. This is so that when we have very small test volumes or reagents (such as blood samples, biomarkers or nanoparticles) we can keep the small volume within the sensor and tubing lengths, but maintain some sort of movement.  Initially I tried to put a while loop (while time target not reached) in a case structure (if recirculate had been selected) and add a shift register with XOR to toggle the boolean values but it doesn't seem to work properly. On a few occasions it seemed to toggle once, but never again - maybe an issue with the way I wired the shift register.

I'm not in my office so I've attached an old version of the VI (I have added some error handling and generally tidied since this version), but the fundamental problem remains the same (I cannot seem to toggle the pump direction whilst waiting for pump duration to finish).

Again, any suggestions or pointers would be appreciated.

Kindest regards,

Jules

[RavensFan]

You don't want to have a VI that sits there a long time in any given state.  Someone stops the VI, they are going to have to wait minutes or hours for it to take effect?

No.  Have a state that checks whether the elapsed time has passed.  If it has not, then it can go  back to the checking state again.  That way if someone does something like try to end the test early, the state machine is responsive enough to handle that.

As a part of all that, it can now iterate fast enough to that you can have a secondary path that will allow it to cycle  back and forth whenever 5 seconds have elapsed so you can handle the 0.2 Hz recirculation of the pump.