Passing a queue as a local variable or reference

[granum]

Hi All

I am developing a piece of code, where I have a lot of different queues and clusters. It has become quite big and messy, so I am trying to get rid of some of my wires by using local variable and functional global variables (FGVs). However, is does not seem to work to pass a queue as a local variable. Neither does it work to pass around a reference to the queue. I basically want to do something like on the attached screenshot. Does anyone know how to do that? I have not had time to test if a FGV will work, but I suspect not.

I am programming on a RT environment

[StevenD · Accepted solution]

In your picture you are not enqueuing any thing to the queue. I can't image that passing it would not work, however you may want to look at naming a queue rather than passing it around as a local variable.

https://zone.ni.com/reference/en-XX/help/371361R-01/glang/create_queue/#:~:text=Use%20named%20queues... 

[altenbach]

Local variable and value properties are not a solution to messy diagrams. They will make things significantly worse (!!). How about bundling the various queues? Have you looked into channel wires?

(With locals and value properties you need to be extra careful about race conditions)

You are not saying much about your code. I assume the queues cross subVI boundaries.

You already got some good advice above. Still, I am curious about your "does not work" statement. Can you elaborate or attach a simple demo VI that demonstrates? (we cannot run or debug pictures).

The following silly and ridiculous code runs just fine here.

[crossrulz · Accepted solution]

---

@granum wrote:

I am programming on a RT environment

---

Generally, RT means there is no GUI.  This means there are no front panels.  No front panels means references to the controls and local variables do not work in RT.  Why can't you just use a wire?

Personally, I am not a fan of named queues.  I have seen too many weird errors, especially when two things use the same name.  I have also seen references not being closed properly because 1 process forgot to close and this will cause memory leaks.

So could you supply a better idea of your current architecture and the goal of the application?  I can make better suggestions with more information of what you are trying to do.

[wiebe@CARYA]

Aren't there limitations to get\set control values by reference on RT? Not an expert, but I heard about problems with that. The RT VI might not have a FP, and might not work well with FP control references.

The queue is a reference, why not pass the reference, instead of a reference to a control that has the queue value?

Named queues are glorified globals. I'd avoid them at any cost. There's never a good reason for named queues (I'm sure we can find one or two exceptions).

EDIT: That crossed... Almost the same message...

[altenbach]

---

@crossrulz wrote:

---

@granum wrote:

I am programming on a RT environment

---

Generally, RT means there is no GUI.  This means there are no front panels.  No front panels means references to the controls and local variables do not work in RT.  Why can't you just use a wire?

---

I was suspecting that too, but cannot test. One would think that if LabVIEW allows placing local variables, it would be capable of keeping enough things in memory so they continue to work, but what do I know. 😉

[granum]

The picture was just to demonstrate, what I wanted to do. I the actual code I do enqueue something before dequeuing. 

Perhaps obtaining the queue by the name is what I should do. I already use this method to pass data back an fourth between the RT and the FPGA module.

I have attached my VI. It works nicely the first time you run it, but the second time the queue references did not work, since I did not release my queue (thanks for reminding me about that!). I have added the release queue, and now the local variable seems to work. The reference does not, but that might just be because I am not pulling the correct value out from it?

Before I released my queue, I got "not a refnum" as a value in the probe window

Clustering wires together would be a possible solution to reduce the wire gore, but I already have clusters holding clusters, so I want to avoid any further cluster gore

[wiebe@CARYA]

But why not like this:

No control references, no global resources (named queues)...

This is just a quick manipulation of your VI, I'd clean up (straighten wires, remove empty space, ditch the sequence structure.

And (optionally) close the queue at some point. For example if the while loop stops. If it never stops, I guess it doesn't need closing.

[wiebe@CARYA]

---

@granum wrote:

I have attached my VI. It works nicely the first time you run it, but the second time the queue references did not work, since I did not release my queue (thanks for reminding me about that!). I have added the release queue, and now the local variable seems to work. The reference does not, but that might just be because I am not pulling the correct value out from it?

If you close the queue, it doesn't exist anymore.

If you close it in the 1st iteration, it's not valid in the 2nd.

You should close the reference to the queue once for each obtain queue. In your example, you're not obtaining a queue reference, you're getting the existing queue reference from the control.

[granum]

Wiebe: I don't want that wire going from the obtain queue vi into the while loop. I the actual code I am developing (not this simple example), I have 7 queues, 4 clusters, and a bunch of other stuff what I used to wire into my while loop and keep it updated via a shift register. It just became too many wires, so I am replacing them with local variable and FGVs