sync multiple parallel loops

[asuwish4]

HI all,

I have a program where I am running multiple parallel loops:

Each loop has its own named queue (not shown).  The general concept here is grab UI events and send messages to the SYSTEM loop (which in-turn will send messages to the indiviual component loops) or the UI loop can send directly to component loops.  The direct messages are for simple actions such as JOG X AXIS or to set DMM to DC Volts.  The SYSTEM loop sends out multiple component messages to perform a task.  i.e. 

1. Toggle supply off
2. Switch Relays from voltage meas to resistance meas
3. Set DMM to 2-wire Resistance mode at 10000 Ohms range
4. Take DMM reading
5. Set DMM to DC Volt mode at 10V range
6. Switch relays to voltage meas mode
7. Toggle supply on.

This is the part I have a question about.  What is a good method for return communication from individual loops back to the system loop?  Using the process just mentioned, I want the Power Supply loop to tell the system loop when it is finished before the relays switch.  Is a Rendezvous the right choice?  Yet another message-based queue?  Notifier?

Or is this architecture not suitable?

Any input would be appreciated.

Thanks all!

Charles Spitaleri

[apok]

I would consider using a queue (many to one)...have a look at this solution 

[crossrulz]

I would use a queue to return data to the system loop.  All of the other loops can send messages to this loop with the same queue.  Perfectly reasonable.

[johnsold]

I agree that a return message queue is a good way to do this. Back in the LV 5 days I used pairs of queues to link pairs of parallel loops.  It did not have quite as many loops as yours but the concept worked very well.

Lynn

[BTC_Admin]

If used correctly, queue would work but a word of caution - I have come across an instance where a queue-based applicatication (developed by a CLA!) was not properly flushing the queue (especially when a user needed to interrupt actions) which caused serious lag issues for the client on top of unexpected actions. For instance, assembly line operators can be impatient sometimes so they may click on buttons multiple times - if you're not careful then you'd generate a tsunami of queued messages which would cause a severe lag in system response). This is why in hardware feed-back type of systems, I have preferred Functional Global Variables (for data transfer/communication messages and flags, especially when an application also involves user-interaction.)  BUT this is just my personal preference/opinion and I'm sure that every programmer likes doing things his or her way based on personal experience.

I prefer queue-based designs if dealing with things like database or file system, etc which do not require any real-time feedback or response, but when it comes to working with hardware many queue-based designs are so flawed that they become a headache.

-DP

[johnsold]

That is one of the flaws of the Queued Message Handler Design Pattern template. It assumes that every event should generate an enqueue action and that every dequeue action should result in something occurring in the other loop.  Many programmers just take the template and run with it without thinking about the impatient operator or the consequences produced by one.

I used functional global variables before queues were available and still prefer them for handling arrays of data in many cases.

As you said a flush of the queue is sometimes appropriate. Another technique is to read the queue as fast as possible rather than waiting the usual time interval before the next iteration.

What all this boils down to is this: Complicated applications require careful design, particularly in the area of communication between loops. With proper design anhy of these tools can be made to work.

Lynn

[BTC_Admin]

Very true - sometimes things are made unnecessarily complicated if some basic items are either missed or ignored by a programmer. I still prefer functional variables too- once I did a simple speed testing - a simple while loop that ran for 10 seconds and I essentially read/wrote FGV in every loop- at the end I simply looked at how many iterations the vi went through... and then I compared the same with queue-based design (two loops, one sending messages to the other to read/write.)  Needless to say that FGV was significantly faster and easier to use.

On the other hand once I saw a design where someone was using Global Variables to store data that needed to be written to dbase and that design had a problem of missed data. Each database call didn't finish within a predetermined time, but the global variable was getting overwritten at a specific interval with new data before the old data was even sent out to the database! This was a design that should have been implemented using a queue.

I guess depending on the functional need, each design has its own merit. Because LabVIEW has made it very easy for non-programmers to be also able to do some basic programming, this has also increased chances of features used inappropriately!

-DP

[Yamaeda]

i would send results in an event.

[asuwish4]

Do you mean set up a second event structure and send user events as request acknowledgements?