single element queue within a functional global

[LV_Pro]

I'm contemplating using single element queues for some messaging within a current project, but as the number grows, causing the number of queue references to also grow, I'm looking at methods to minimize the number of wires running around my higher level vi's. I don't want to initialize these queues early in the program and then have to run their individual references all over. One thought I had was to encapsulate them in an Action Engine, to hold the references, but am wondering what, if anything, I  gain or loose by doing this, vs just using functional globals for the messaging and not bothering with the SEQ's?

Thanks, and for those of you in the southwestern part of the US, stay warm (they are having unusually cold, snowy weather).

[DFGray]

I have done something very similar to this for almost a decade.  I wrap all my references into a strict typedef cluster and make a reference to that cluster.  This über-reference is then used in all my top-level VIs.  In 2000, I started with all references being multi-instance functional globals, but switched to all single-element-queues around 2004.  For new designs, I would recommend the data value reference, instead.  It is safer, and usually faster.  It also cannot be named, forcing better programming practice (no global).

However, lately I have been rethinking the "correctness" of throwing everything into reference objects.  It makes sense to keep local data local in shift registers, but this has to be balanced against future needs which would require massive rewrites if a piece of data is needed more globally.  In addition, making things into reference objects produces resource contention and race conditions issues.  In the final analysis, the design will depend on what you are doing and how much contention will actually exist (ask Ben some time about what happens when you try to hit the same functional global simultaneously from hundreds of locations...).  Having come from a physics background instead of a computer science one, I tend to err on the practical side of things. 

[LV_Pro]

Thanks, sort of! Your answer has caused me more questions. When you say in the first part of your response that you wrap all the queue refs in a strict type def'd cluster, then make a reference to that cluster, what exactly do you mean? You pass that cluster to all the relevant locations, pass a  control reference of that specific instance of the cluster to the various places, encapsulate the cluster in a FG that is referenced where needed?  As to using a DVR, we are, at least for the foreseeable future at this customer, using 8.6 and I'm of the understanding that DVR came out in v2009? I guess I'll have to ponder this a bit more.

I'm going to be in Austin the end of this week and the beginning of next, so I hope that you folks have pleasant weather for my visit!

[DFGray · Accepted solution]

Using single-element queues as a reference object (the best one you can use in LabVIEW 8.6, in my opinion ), I do the following.

1. Create single-element queues for each of the reference objects.
2. Create references for each of these queues and place them in a strict typedef cluster (typedef is probably good enough, but I like to preserve layout).
3. Create a single-element queue which contains the typedef cluster.
4. Initialize all the queues in your startup code at a level that ensures they will not be helpfully cleaned up for you (usually as a subVI in your top-level code).

To use, dequeue the top-level queue, unbundle the correct reference, requeue the top-level queue.  You should not have to touch the top-level queue that often, since the references should not change during the life of the application.  In fact, you can replace the top-level queue with a global, for that reason, except you then have to worry about initialization before use.  I have an extreme revulsion to unencapsulated, globally available data that I picked up in my C days, so generally avoid them if I can.  Hopefully this was a bit more enlightening.

Our weather at the end of the week should be about normal for this time of year - unlike last Friday.  Here is a picture of the entrance to the R&D building about 7AM.  It was our major snow of the decade .  The city shut down for the day.  The next day, we almost hit 70°F.

[LV_Pro]

Thanks a lot! That helps a lot. Sort of a mini-nugget!

Yes, my significant other has been bugging me about what she should bring, clothing wise, and I tell her that it is hard to tell, could be cold, could be "warm" (for us at this point >50 F is warm!). The car behind mine, parked last night on the street, was clipped by the snow plow, took off his side mirror. (A snow plow, for those not familiar, is a large dump truck with a big steel blase on the front for pushing snow off the road. ) Where I am in NY for this project doesn't get as much as where I am on the weekends. Up there we hit our normal seasonal total of 115" around two weeks ago, we are probably nearer 130" now, although it isn't all on the ground (no 13' depths). I just need to get out and play in it, either skiing, snow shoeing, something.

[SteveChandler]

I am trying to visualize the snow covered cactus gardens.

[DFGray]

While not a cactus garden, this may help.  This path is across the street from Building B heading toward Building A (manufacturing).