topic Re: Question about storing references in LabVIEW

Question about storing references

Broken_Arrow — Mon, 15 Aug 2011 20:22:41 GMT

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?

Re: Question about storing references

F._Schubert — Mon, 15 Aug 2011 20:32:59 GMT

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

Re: Question about storing references

PiMaster — Mon, 15 Aug 2011 20:46:37 GMT

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.

Re: Question about storing references

PiMaster — Mon, 15 Aug 2011 20:49:52 GMT

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

Re: Question about storing references

Mark_Yedinak — Mon, 15 Aug 2011 21:10:50 GMT

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.

Re: Question about storing references

Broken_Arrow — Tue, 16 Aug 2011 13:32:50 GMT

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.

Re: Question about storing references

vt92 — Tue, 16 Aug 2011 14:17:07 GMT

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

Re: Question about storing references

Mark_Yedinak — Tue, 16 Aug 2011 14:19:38 GMT

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.

Re: Question about storing references

JÞB — Tue, 16 Aug 2011 14:39:05 GMT

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.

Re: Question about storing references

Mark_Yedinak — Tue, 16 Aug 2011 15:00:39 GMT

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.

Re: Question about storing references

JÞB — Tue, 16 Aug 2011 15:05:03 GMT

@Mark Yedinak wrote:

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.[..............

Yup- my thoughts exactly! versitale, component based, High reuseability, Nice decoupling, .... Looking forward to the nugget and link to the slides (I missed NI Week again)

Re: Question about storing references

Broken_Arrow — Tue, 16 Aug 2011 15:40:34 GMT

@Jeff Bohrer wrote:

BA-

[...] _ 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.

Very good idea for this type of isolated indicator! No, I haven't thought of it. It works great. Gives me the willies because its simplicity seems so akin to writing to multiple locals, but it isn't.

Re: Question about storing references

JÞB — Tue, 16 Aug 2011 15:44:24 GMT

@broken Arrow wrote:

@Jeff Bohrer wrote:

BA-

[...] _ 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.

Very good idea for this type of isolated indicator! No, I haven't thought of it. It works great. Gives me the willies because its simplicity seems so akin to writing to multiple locals, but it isn't.

And--- (BONUS) since the subpanel is in scope of the GUI FP you ARE registered for events! (well, most of them I seam to remember there are a couple that are not avalable for subpanels like panel cose?)

Re: Question about storing references

Broken_Arrow — Tue, 16 Aug 2011 15:48:00 GMT

Jeff....... Micro-Nugget?