multiple channel state machine based DAQ

[SteveKS]

I wrote a program that recorded a couple voltage measurements and a temperature measurement, using PXI switch cards, for a specific channel every couple of minutes and saved it to a file.  Each channel needs to have the ability to be turned on or off independently.  The program had 64 channels, so there was essentially one giant while loop, with 64 case loops within it.  There are several sub VIs within each case loop, so there is some ability to alter the sub VI without having to alter every channel, but one of the biggest shortcomings is the cumbersome nature of editing the program.  So, my question is if anyone has ideas for other structures that are more compact and efficient for editing or just more efficient in general than this multiple state machine concept.

Thanks,

Steve

[F._Schubert]

The basic path I#d suggest is to breack the giant while loop down into seperate loops and make a subVi out of each. This only really works nicely, if you don't need to have the different tasks acessing the same ressource.

The main job when refactoring code is to keep an eye on which patterns are repeated and then find a strategy to make them a reused feature.

I could imagine, that you have n-channels for temperature reading. Make a general purpose subVI that is reentrant and is a state machine in itself (so having e.g. an Active state and an Inactive state). Now for each temperature sensor, you run one instance of this state machine with the specific channel settings necessary for this sensor. If they acces a shared recource, you need some kind of mutek around. You can use a semaphore or a single element queue for this.

Also use a notifier or user event to communicate to these loops from your master control loop. You can write any command pattern like 'channel 1::stop' which would be parsed by each of the parallel loop and compared against it's own channel name ('channel 1'). Make sure that in both stoped and running state, the queue or user event is received (in stopped you can just wait for it, in running, you can use it with a timeout before moving to the read state.

Maybe you can present a simplified architecture, so we can comment more on the overall structure. It really depends a lot if the tasks are running on the same cards or not, if they need to be syncronized and by what means...

Felix