synchronizing timed loops in multiple VIs

[EthanStern]

When I call 'Synchronize Timed Structure Starts.vi', wire a 10000ms timeout and an array of timed loop names, it runs immediately, does nothing and returns no error.  Previously, I had run it in a subVI which forced that VI to wait on other timed loops before executing but when I put it in a separate VI, it seemed to do nothing.  It would be nice to be able to call the sync VI and then call a number of dependent loops that require synchronizing.  This would allow me to synchronize multiple loops without having to sweat which one gets called first.  Is this a bug or am I just misusing the synchronize VI?  Thanks.

[Norbert_B]

Estern,

i do not completly understand what you are up to; maybe it is a good idea if you post a small example of your current issue and explain, what you'd prefer it to do.

Regarding synchronization of timed structures beyond "vi-boundaries" there are several possibilities:
a) Use named time structures and the "synchronize timed structures.vi". This works out the first time very good, but it is difficult to achive a solution which "repeats the synchronization".
b) Generate one timing source for all structures you want to synchronize. Clear the source if the structures should finish synchroneously. Generate it anew if you like to restart the structures. Difficulty: the timing structures skip if timing source is not present, so you have to poll for the new timing source which either creates CPU-load or timingjitter at start of the structures.
c) Use event based programming for calling your timed structures. This would propably be the best method since it is repeated quite easily and has low CPU-load and fast response-times.

hope this helps,
Norbert B.

[EthanStern]

Norbert,

Thanks!  In spite of my explanation, it seems you understood my question.  The Synchronize Timed Loops VI was working but only the very first time it was called -- very mysterious and annoying.

Could you/anyone elaborate on how to synchronize multiple VIs using events?  (Option 3 on your list of possible solutions)  I tried a few simple test cases and was unable to make anything work.  Is the event approach any different or any better than just using a notifier?  (I was so wrapped up in trying to use the fancy new features of LabVIEW that I forgot notifiers existed...)

[Norbert_B]

Estern,

i just made a small screenshot from an approach which might work out for you. All three while-loops could be contained in different VIs of course.....

hope this helps,
Norbert

[EthanStern]

Norbert,

Thank you again.  The notifiers seem to work quite well.  Not to beat a dead horse, but could I also use Rendezvous to achieve the same goal?  I just discovered them and the seem to provide the same functionality as notifiers in this instance.  (No example necessary, just curious.)  Thanks!

[Norbert_B]

Estern,

notifiers and rendesvouz are very different things. Ok, regarding your requirements, it might suit the same purpose for you here, but dont make the mistake and mix them up!

Notifiers can be used to:
- Transfer single data with the risk of loosing data if the "slave" (the one waiting on notifiers) is too slow.
- "Fire an action" if something occured at a different location in your application.
So notifiersare some kind of user defined events (which are available as an own structure as well!!)

Rendesvouz are used to:
- Synchronize parallel threads at a certain point
Please note that you cannot pass data with rendesvouzs and you can easily hang your application by improper usage....

hope this helps,
Norbert

[DFGray]

For your purpose, you could use occurrences, notifiers, user events, or rendezvous. I would avoid rendezvous because the underlying technology forces a switch to the UI thread (this will be fixed in a future version of LabVIEW). This can slow your program down. The others do not have this issue.

For most synchronization needs, queues, notifiers, and user events will take care of you. Use queues for point-to-point synchronization and notifiers or user events for broadcast type synchronization.

If you use the code fragment Norbert B posted, be careful that your loops do not take longer than the broadcast period. If one or more do, you will get out of synch.

[metzler]

I have a similar problem.  I need to run three different vis on the same computer, all using the CompactDAQ.  Each vi has a DAQ while loop, that writes and reads to some of the channels (each vi is using different channels from the CompactDAQ). 

When I run more than one vi, the readouts get jumpy.  I have checked perfmon and the processor is not overly taxed, so I am assuming that the different vis are trying to read and write to the CompactDAQ simultaneously, causing slow reading and writing.  All channels in MAX are configured for 'on demand' (maybe this is a problem?).

How would I use Norbert B's Synchronize Timed Structure.PNG to provide a timing source for the loops? 

Would I need to use a global variable for the input to the notifier terminal of the wait on notification?

Any advise is appreciated.

[DFGray]

I think you figured out your issue already.  I believe it is due to timing collisions in the hardware while trying to service the same device asynchronously from multiple directions. You may want to repost this question to the DAQ forums to get a better response.  When you do, be sure to include the hardware and software you are using.  Without this information, troubleshooting will be difficult.  Just guessing, you may be able to solve your problem by streaming data from your device continually and reading the stream when you need to.  Watch out for latency issues with this approach.  You can stream to any good singleton data object (single-element queue, functional global, or  data value reference).