LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Concept Prototype of Globals using Queues vs. Unitialized Shift Registers (USR)

This is a followup question to regarding conni's concerns on implementing access to globals using queues.
 
I am trying to implement a Single Element Queue which allows access similar to a Global Variable.  I have successfully used Uninitialized Shift Registers but am trying out some new concepts in the hope to improve performance and robustness.  From what I know, Single Element Queues, guarantees protection against shared access across other VIs while they are being modified.  I've prototyped some code, but can't get queues to work.
 
I have attached some example code (LV 6.1).
 
String_USR_Global.vi  (works great)
String_Queue_Global.vi (doesn't work)
 
I've looked in NI Examples, lavag.org, and this discussion forum, but was not able to find a direct answer. 
 
Can someone please review the code to see what I'm doing wrong?  I would like to keep the same VI interface (as in String_USR_Global.vi).
 
 
Thanks!
Smiley Wink
- crazycliffy
0 Kudos
Message 1 of 9
(5,312 Views)
Here is the code ...
- crazycliffy
0 Kudos
Message 2 of 9
(5,310 Views)
I think this code would work if you called it as a subVI in another VI multiple times (At least once to set and once to get). The problem is that if you simply run the VI by itself as a top-level VI, LabVIEW will automatically destroy the queue when the VI goes idle, because it isn't needed anymore. If a VI is being called as a subVI, it won't go idle until the calling VI goes idle, so you won't have this problem of auto-destruction. This is different behavior than a functional global with an USR, but it shouldn't impact a single-element queue's use in the overall application.

Jarrod S.
National Instruments
0 Kudos
Message 3 of 9
(5,302 Views)
I made a few mods and put quick comments in the code.  I also changed the wiring interface to add the error in / error out terminals at the bottom, so you don't toss away errors.

Final comments: you may want to consider Notifiers which, if I recall correctly, are internally implemented as single-element queues.

-Kevin P.




Message Edited by Kevin Price on 04-11-2007 05:29 AM

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 4 of 9
(5,286 Views)

Not to pre-empt Kevin but because this is AE week for me and because you are working LV 6.1 I offer this example that may help.

Besides I wanted an an example of a AE that demonstrated self-inititalization using the "First Call" function.

Ben

 

Message Edited by Ben on 04-11-2007 07:57 AM

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Download All
Message 5 of 9
(5,269 Views)

Thanks all for your suggestions. I was able to combine most of everyone's idea, and also created some test drivers to verify the functionality.

Files are written in LV 8.20.  Sorry didn't have time to port over to 6.1.

- crazycliffy
0 Kudos
Message 6 of 9
(5,240 Views)
Hi,

thanks for all your suggestions (Look's like I forgot to watch this thread long before, sorry.. )
In the meantime I've been using a lot of single-element queue globals in my programs and have not noticed any problems. I use them, where concurrent access might be dangerous, otherwise I use simple USRs in a subvi to store data.

Cliff, thanks for those examples, I'd add just a few comments:
1) why do you put the data right back into the queue in operation "get" ? this way the data is not locked, or do I miss something ? i think, it should be possible to "get" the data only once (queue is empty afterwards, other callers have to wait) and have to put it back using "set" afterwards.
2) If you make the VI reentrant and always use obtain queue to get the queues refnum, it is possible for one thread to wait in operation "get" endlessly without polling,  while one thread is working with the data and can put it back afterwards using "set".

Regards
Conni
I
0 Kudos
Message 7 of 9
(5,222 Views)

@conni wrote:

Cliff, thanks for those examples, I'd add just a few comments:
1) why do you put the data right back into the queue in operation "get" ? this way the data is not locked, or do I miss something ? i think, it should be possible to "get" the data only once (queue is empty afterwards, other callers have to wait) and have to put it back using "set" afterwards.
2) If you make the VI reentrant and always use obtain queue to get the queues refnum, it is possible for one thread to wait in operation "get" endlessly without polling,  while one thread is working with the data and can put it back afterwards using "set".


1.  My application is to follow a similar Get / Set function.  Once a user "set"s the value, repeated "get"s will just pull the data from the queue.  It enqueues the data back, so that other parallel running VIs can obtain "get" the value. 

2.  Yes this is possible.  LabView 8.20 has built in examples of this.  See the Producer Consumer state machine.  Or you could do a NI search in the discussion forum for "queue state machine".

Hope I was able to answer your question. If not perhaps you can post and example.

-crazycliffy

- crazycliffy
0 Kudos
Message 8 of 9
(5,210 Views)
In this case there seem's to be no need to protect the data against concurrent access, right ? wouldn't a simple LV2 aka functional global do the job then ?

conni
0 Kudos
Message 9 of 9
(5,173 Views)