LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Question about storing references

I have been using Notifiers for a long time - to send string data to "status bar" type indicators on the GUI. I also may use them for synchronization. 

 

In the case of sending data to the Notifier, the Notifier wire gets to be a pain nesting into sub vi's. I have been experimenting with various methods of using the Notifiers "wirelessly", while maintaining efficiency and speed, avoiding memory leaks, etc.

   

In this tread, Mr. Grey mentions storing a Notifier reference in a "look-up" table. Can someone explain what this may be? An array of references?

 

 

 

Richard






0 Kudos
Message 1 of 14
(1,817 Views)

Simple AEs/LV2globals do the job nicely. Whenever you want it wireless, it's a good choice. Second, you can place an obtain notifier on first call inside.

 

Felix

Message 2 of 14
(1,810 Views)

Yeah, I normally have an AE store the reference to the FP object, and then have various actions to update the value or other properties.

 

There may be a better way, but it's 'wireless' and I think since it avoids copying the reference, it should be memory friendly.

0 Kudos
Message 3 of 14
(1,804 Views)

For instance, I often have a three-line scrolling string indicator.  Attached is the AE to update it.

 

 

0 Kudos
Message 4 of 14
(1,799 Views)

We developed a LVOOP class that allows whatever code or components in our system to post messages. We also have a router that directs the messages. The event classes are generic and require no wires to be passed to them. The class handles all of the communication details. The component generating the message simply needs to invoke our "Post Event" object. Components that generate the messages advertise the types of messages they generate. Consumers of these messages register with the router to receive the messages. The consumer is responsible for decoding the actual message content beyond the basics (time stamp, message ID, etc.). However, since it is requesting specific messages it makes sense for it to know the content. In addition, our router is capable of broadcasting a single message to multiple recipients. We use queues for sending and receiving the messages. Each application has a predefined name for teh primary routing queues. This is how teh Post Event can obtain the queue in a generic fashion. Consumers of the messages register with the router which messages it wants to receive and the name of it's receiving queue.

 

We have found this to be a very flexible design.

 

The only change we are making now is to change the queues to network based queues. This will allow us to route messages across application boundaries.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 5 of 14
(1,786 Views)

Mark, any chance to post the code, or a Nugget?

 

Schubert: Thanks for the idea of the First Call. I had an AE (set, get) version of my wireless status updater built and running fine. But, I found it to be bulky for that purpose of simply updating a string on the front panel which isn't a priority - just a convenience feature of the GUI.  Not to stray off topic, bit I've been thinking a bit about my own use of AE's after reading this post by Aristos Queue, 

 

To the AE's credit, it does work well in this scenario, because this isn't a Write Once Read Many (where, in such cases, I have started using Globals again for the first time in years). This is a Write Many Read Constantly scenario. However, continually Obtaining, Sending, and Releasing the notifier also guarantees no race conditions and is wireless, but undoubtedly at a performance hit (speed wise), and is just as bulky as the AE.

 

I have also tried (for fun mostly) programmatically "finding" the reference to the notifier (by name) and running wirelessly that way. Bulky still, of course. Oddly, seems fast.

 

Maybe there's something to keeping stuff on wires.

 

Richard






0 Kudos
Message 6 of 14
(1,756 Views)

Yes, I would love to see Mark post a nugget too!

>

"There is a God shaped vacuum in the heart of every man which cannot be filled by any created thing, but only by God, the Creator, made known through Jesus." - Blaise Pascal
0 Kudos
Message 7 of 14
(1,736 Views)

I'm working on getting permission to post post the code. It is code that was developed at my company and I need to clear it with them.

 

Also, one of the features of our messaging/routing system is file logging and UI updates. I presented the code at NI Week this year. Unfortunately the slides of the presentation are not enough to give a full picture of what there is. I am in the process of writing up some supporting documentation for the slides to give a better overview. At a minimum my addition information will contain some screen shots of some of the code highlighting some of the key features.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 8 of 14
(1,733 Views)

BA-

 

Interesting discussion and I'll add my two cents.  Obviously there is going to be a performance hit every time you updat a FP obect without a wire to a local or to a terminal.  and a Global still requires you to update the FP of the GUI by timely reading the Global.  Creating an AE with a VI referance to the FP object on a SR (a "special AE type I call a "Resource Module") as duplicated by PiMaster (See my Nugget Series: Application Development for examples of a distributed component oriented GUI update method) still requires the overhead of writing values via property nodes (with all the overhead associated with both a subvi call and a property node write/read). so lets look at a method that might make sense for opimizing this problem.

 

REQ:

  • lossless data access to FP object on a GUI
  • Race condition free (blocking)
  • data maintained privately to the method.(encapulated)
  • high performance.

Mark seems to get there with the class (And I'd love a peek too (Hint- nuggetize the class based generic message system)_ but have you considered the simple expediant of using a subpanel to a vi that has 1 string control visible ? Wire the rest as an AE BUT use the terminals rather than a SR.  Place the sub.vi's FP in a subpanel on the GUI and BAM! a "nearly 0 overhead" method to write/read a GUI object since all the overhead is in the call to open the FP in a subpanel. 


"Should be" isn't "Is" -Jay
Message 9 of 14
(1,723 Views)

Jeff Bohrer wrote:

REQ:

  • lossless data access to FP object on a GUI
  • Race condition free (blocking)
  • data maintained privately to the method.(encapulated)
  • high performance.

Mark seems to get there with the class (And I'd love a peek too (Hint- nuggetize the class based generic message system)_ but have you considered the simple expediant of using a subpanel to a vi that has 1 string control visible ? Wire the rest as an AE BUT use the terminals rather than a SR.  Place the sub.vi's FP in a subpanel on the GUI and BAM! a "nearly 0 overhead" method to write/read a GUI object since all the overhead is in the call to open the FP in a subpanel. 


I agree for very basic things this works nicely. In our use case we have lots of low level components that get reused in many different applications. We never know what will get logged, what will get displayed and what messages will be of interest to the application. Therefore we chose this method to allow the low level modules to fire off messages. It will do so whether anyone is listening or not. In fact, the lower level code doesn't care. THis approach is very flexible and it really decouples the functionality from the UI. Yes, there is some overhead associated but it does provide a very versatile and flexible architecture.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 10 of 14
(1,711 Views)