Queue References & Functional Globals

[cowen]

Hi Guys,

Not a newby to LabVIEW. but this feels like a newby question!!

I have a Functional Global VI with the following functions....

- Init - opens a queue reference and stores the reference in a shift register

- Deinit - destroys the queue

- GetQ - passes out the queue reference

- Send - places data on the queue

This was written in kind of auto-pilot. Just wanting to make sure all application VI's initialise the queue correctly with the same name and the same datatype. Everywhere I need to send data via the queue, I call this VI and attach the data to the input and the stored Q reference is used by everything.

My question is, is this fundamentally wrong?

Of course I understand that I can open new references to the same Q, send data and then close that reference instance.

Are there any known advantages/disadvantages?

[Cat]

I can see two reasons for using sub-vis for this sort of thing

1) Cut down on queue wires going all over your block diagram. Of course, some folks would consider this sort of data-flow hiding to be a Bad Thing (kind of like overusing a local variables)

2) Other than that, I can maybe see a reason to have an Init vi. If you only have 1 queue and are using it in a lot of vis it would keep you from missspelling the name. But this wouldn't need to be a functional global, just an Obtain Queue primitive with a name (and data type, of course). It only takes 1 primitive to release a queue or enqueue/dequeue data, so it seems kind of like overkill to use a vi for those functions.

So unless there's a messy wiring issue, while doing this in a functional global isn't "wrong", I'm not sure if you need to go to all that trouble.

Unless of course I'm not getting the whole point of what you're doing...

[ShaunR]

I'm even worse (although I don't use a FG. Instead I use named queues) and only use strings for all my queues' data

1 VI for any queue anywhere within my code

[cowen]

In other application I have a VI for initialising the Queue only (to ensure name and datatype) - this seems sensible. However, in this application there are many functional globals for sharing of data, and I think I just created this functional global for the queue without thinking so clearly (probably late one sunday evening with a bottle of Bud close by!!).

[asbo]

(probably late one sunday evening with a bottle of Bud close by!!).

A bottle of Bud?? You're in Germany, you can do better than that!

[Cat]

I'm even worse (although I don't use a FG. Instead I use named queues) and only use strings for all my queues' data 1 VI for any queue anywhere within my code

This is bad? Oops...

[JamesMc86]

The risk with a system like this is that it is very easy to end up with the queue communications embedded within your code modules. This can reduce the reusability and scalability of your application so I prefer wiring the reference, especially as 3 of your functions just wrap queue primitives anyway.

[Darren]

The risk with a system like this is that it is very easy to end up with the queue communications embedded within your code modules. This can reduce the reusability and scalability of your application so I prefer wiring the reference, especially as 3 of your functions just wrap queue primitives anyway.

Yeah, what he said.