Correct Design Pattern for my 3 Instrument Application

[rkmadse]

I am trying to figure out the best design pattern for a project I am working on. I am using a workstation to control three instruments and a swith matrix to connect to multiple outputs so that simple measurements can be taken across those outputs.

The user will select a few initial settings but then will click a "Start" setting off a full sequence of measurements where the user will have no interaction during the measurements.

I was orignailly working with an Even Driven Producer Consumer (With a state machine in the consumer loop) design pattern , but am rethinking what I need to be doing since the process will be something like..

1. Gather tesing initial conditions.
2. User presses start.
3. Switch to output1 → Measurements with insturment 1 → Measure with insturment 2 → Measure with insturment 3
4. Switch to output2 → Same as above ↑
5. Continue switching until all outputs have been covered.
6. Log Data

My main problem is that I need something to take care of the timing, making sure that the system is waiting between swiching and connecting to insturments and then repeating the sequence if the user selects to have the test run continuously.

Any help is much appreciated!!!

Thanks,

Kellen

[rkmadse]

Maybe the Producer Consumer isn't the way to go, maybe a simple State Machine type design is sufficient for what I am doing? After all, the user should only be clicking the button once and the acquisition isn't going to be happening faster than it can be processed.

[Sam_Sharp]

If you have any situation where there is a series of steps you need to follow, it lends itself well to a state machine - that could be a queue-driven state machine (like the event producer/consumer - the event structure is mainly for handling user events like start/stop/exit etc.) or a 'classic' enum based state-machine. You might want to have a look at the JKI state machine as it lends itself well to the problem you're describing. (It has an event structure in the idle case for start/stop but then runs through a series of steps).

For timing, you could have a 'check timer' state which you stay in until the time has elapsed and then go to your acquisition state before resetting the timer and starting again. Of course - this is windows driven so if you need accurate/deterministic timing it's better to use hardware timing if you can (e.g. DAQmx / RT).

[Dennis_Knutson]

You could also consider using TestStand. It's an extra cost option but it's designed expressly for applications like yours.

[Gregory]

Lately I'm a fan of the Module approach from the Delacor Queued Message Handler. You can make each instrument ("Module") it's own SubVI with it's own user events or queue. The default case (first enum value, or empty string) can stream data back to your main VI if it's a measurement device, then you can set the timeout to some non-negative number to continuously acquire data.

If you need to ensure that the data is somewhat synched up (i.e. after a setting is applied, and not before) you can send a notifier reference to the Module. Then make your main application wait on the notifier, and have the module send data back on that notifier.

[RTSLVU]

---

1. Gather tesing initial conditions.
2. User presses start.
3. Switch to output1 → Measurements with insturment 1 → Measure with insturment 2 → Measure with insturment 3
4. Switch to output2 → Same as above ↑
5. Continue switching until all outputs have been covered.
6. Log Data

---

State Machine.

[rkmadse]

Thank you for your response. If I have a timing state that checks to see if sufficient time has passed to move on to the next state, does that mean that I'll then need to keep track of the previous state and determine what the next state should be within the 'Check Time" state? Or is there a better way to know what the next state should be when sufficient time has elapsed?

Thanks in advance.

Kellen

[RTSLVU]

---

@rkmadse wrote:

Thank you for your response. If I have a timing state that checks to see if sufficient time has passed to move on to the next state, does that mean that I'll then need to keep track of the previous state and determine what the next state should be within the 'Check Time" state? Or is there a better way to know what the next state should be when sufficient time has elapsed?

Thanks in advance.

Kellen

---

Yes, no... Maybe? 

Without knowing all the decision logic details I would suggest you might want to also consider a queued state machine over a "standard" state machine.