What is the best way to design parallel loops?

[tim_wright]

Hello all,

I am designing a VI to handle an instrument we're building.  I have been using labview on and off for about a year and my earlier iterations of this software design were full of poor design choices.  As I gear the new design up, I'm starting from scratch. 

My design can be distilled down to two main functions, updating a thermoelectric controller every second and taking a picture every 10 seconds.  My design thought was to create a single timed loop that loops every 10 ms and then on the 100th loop iteration execute the controller update and on every 1,000th iteration take the picture.  The final design constraint has to do with button presses (such as a 'stop' command or initiate new ramping parameters) I would like button presses to alter operation quickly (not the 10 seconds that could happen while a loop finishes).  The 10 ms loop would give a fast enough response time to button presses.

I have a few concerns with this approach which will most likely highlight my lack of understanding on how Labview operates. 
Concern 1) The loop will eat up system resources

Concern 2) Picture taking or new command operation could take longer than 10 ms to finish and therefore hold the loop up while execution finishes.

I would appreciate any suggestions on design implementation before I pour time into a badly chosen framework.

Thanks!

[mdwebster]

There are a couple of considerations to think about here.  The one that will most drive the design is how much jitter is allowable?  On a 1s/10s basis, I would guess you can probably handle 3-400ms of jitter without losing much sleep.  This should be mostly achievable using Labview on a PC, but just know that Windows isn't deterministic and depending on what's going on, you may wind up with >1s of jitter (theoretically, it could be multiple seconds, but as long as another app isn't hogging the CPU too badly, it should be ok (emphasis on the *should*)

If you do need tight determinism, then there's a lot of work involved figuring out what the interface of your devices are and if you can use an RT system or DAQ hardware to trigger the acquisitions.

I'm going to assume you don't need that and that 100ms+ is fine.

Personally, I would have a loop for each instrument and a state-machine / event-driven pair for handling the GUI.

1.  Loops don't take up much in the way of system resources as long as you have a wait primitive inserted that allows them to yield to other processes.
2.  This is why you decouple the GUI from the instrument loops.  All sorts of GUI routines sit and wait for an input and you don't want that holding up your more time-critical loops.

Now, there are all sorts of ways to send messages between the instrument loops and the GUI loop, but I'm running short on time here.  There are lots of articles talking about action engines, command & response queues, and other ways to shift data between parallel loops.

Good luck,

Mike

[Esteban_B]

Hi Tim,

I think that you are in the right way thinking about parallel loops, maybe you just want to decide what is going to be in each loop. For example what Mike says about having a loop with an event structure for the GUI and a loop for each instrument is a good approach. You can also consider a structure producer/consumer for handling your interactions with your instruments.

To avoid concern 1, you just have to place proper timing in each loop. To avoid concern 2 you can have a producer/consumer configuration, or a master/slave configuration. In this case, producer/consumer will be a better option because it will allow you to queue events and prevent the lost of information.

The producer can be the manager of the actions, it can has a counter and a case for each action, when need to send a signal to the controller, or to the camera and the controller at the same time. You can have two consumers, one for the camera action and another for the controller.

You can find the producer/consumer configuration in the LabVIEW templates; you can also find useful information about producer/consumer design here, and important documents for general design patterns here.

I hope this will help you in your project.

Regards,

[tim_wright]

Thanks for the repsonses.  I'm having a hard time setting aside my previous programming experiences and force myself into the LabView paradigm. 

I have a design that works at the basic level.  I'm adding features now and I'm happy with how easy it will be to add further complex actions.  The desgin I settled on has one timed loop running at 10ms.  This loop watches for button presses on the UI.  I then have two while loops outside the time timed loop (ending with an 'All Stop' button press) that watch for signals from the timed loop to activate mini-state machines for each action.  For example, the thermoelectric control can only set a new temp or read current temp on one bus read.  Therefore, on the 1 Hz signal from the timer, it will determine if it needs to send the write or the read command.  No matter what's going on with the thermoelectric controls, the camera seems to operate on it's 0.1 Hz frame rate.

Thanks again for your help!