Design Pattern using queues and notifiers and problem with syncing

[Gregory]

Hi Karen,

Just to clarify, it is possible to view the snippet as a png, but not much useful suggestion can come from viewing it.

[KarenM]

Hi, 

Here is the actual vi. I apologize for this monster VI. 

Thanks for the help!

[KarenM]

Hi, 

I see. I thought maybe all that was needed is a theory correction - eg. perhaps I had wired something differently or double-wired the same error wires into the same loop... I have included the VI in a subsequent post. Thanks for the help!

[Bob_Schor]

Thank you for sending all of the VIs!  Opening your main VI (I opened "FourChannels_Event_AcquireStart_DifferentTime_P2V2.2 (3) - all queues", which I hope was the right one) shows a much "more reasonable" size VI (only 6 across by 7 down Monitors).

I'm not sure I know what question(s) you are asking.  I see the error lines, they look fine.  I see what I assume is the Producer loop on top, with 4 Simulate Signal Express VIs doing something.  I assume the loops below that are the Consumers.

1. Are all of the Consumers running slowly?  I notice that you have timers on them -- are they all running at 4/sec?
2. Since you know the code better than I, in particular, you know what you want it to do, can you tell me, briefly, the function of each loop?  Are they all doing more-or-less the same thing, or are they all different?
3. Have you tried disabling all but one Consumer and seeing how the program runs?  A good idea when trying to debug a really huge system is to simplify it by turning off sub-systems.  A "sneaky" way to do this is to invert the Error Case Statement inside (what I think are) your Consumers.  What I mean is look at the Error Case, right-click the border of the Case Statement, and choose "Make This Case No Error".  Now (since you have No Errors) you'll only execute what was the Error Case, which should do nothing, and therefore take no time.  No code rewriting required!
4. Using Step 3, you should be able to test your Consumers "in isolation".  It may be that several of them are doing similar things, and all are "too slow", but you are in the position to do the testing and let us know.

If you can get a better idea from your testing which loop seems to be giving you trouble, we can focus on that.  There will still be the potential problem of how to "point" us to the right part of your code, but we'll cross that bridge later ...

Bob Schor

[KarenM]

Hi,

Thanks for looking through the code. I believe my past 5 posts in this thread will answer all your questions. The four acquisition loops do the same thing.

I have indeed tried disabling one of the loops and that cuts the program down to 3s. Thus, I want each of the loops take 1s to run.

I have also tried only wiring the error wires to ONE queue in each loop.

Following the idea that you mentioned about wiring the error lines in parallel like this, I am not sure what I might be able to try to get the program to run at 1cycle/s (simultaneous acquisition). I hope there needn't be any major refactoring, perhaps only changing around the acquisition loops?

I have run this program using the DAQ assistant to acquire actual voltage input -- the result is the same where the program acquires every 4s. I am not sure what I am missing to get this program to run parallel consumer loops. We have dual-core CPUs which the program will use.

Thanks!

[Bob_Schor]

OK, byte the bullet (that's a bad pun, I know) and disable all but one of the (identical?) Consumer loops.  Does it take 1 second?

Bob Schor

[KarenM]

Hi,

Lol. I tried it and it does only take 1 second.

Thanks. 

[Bob_Schor]

Drat!  That obligates me to do more work!  I'll be back ...

BS

[KarenM]

Hi Bob,

Much appreciated. Hasta la vista!

[ohiofudu]

Hi,

I will like to help.I took a look at your Code and I dont know where to start.