Aristos Queue

I'm just talking about opening up the property pages to extension... nothing to do with the property tags of the libraries themselves.

I did, but I probably don't count. :-)Seriously... various folks are discussing how this could be opened up as a result of Jack's posts. We'll see what the new year holds.

A lot of folks are on vacation at the moment... you may get a better answer if you repost after New Years. You should be able to start with a top level object like a Canvas or somesuch and add multiple objects to it. So although visual objects always have a tree with a single root object, that visual tree is a tree, with arbitrary branching, not just a linear list of parent->child->grandchild.

Inline + Subroutine = Inline Subroutine priority does not add anything once the subVI is inlined.

I'd forgotten about Daklu's earlier write up. His is probably what you're looking for.

The simplest form of the Observer Pattern in LabVIEW is "One VI generates a user event and gives it to any other VI that asks for it. That other VI then registers the user event refnum with an event structure and listens for the event." There are many variations on that theme, some more successful than others, so let me point you toward one that I would use initially. The Observer Pattern needs two parts -- the independent model and the listening system. The independent model is what I was constructing withthe Actor Framework, presented at NI Week 2010. In the docx file that is part of the download .zip file, there is a description of how to set up listener relationships between the actors by selectively sharing the queue refnum. That isn't quite the same as the Observer Pattern. For the observer pattern, you would want to share around user event refnums -- create some sort of RegisterMe message class and send it to the model object and have it send back the user event refnum and then have the observer register that refnum on an event structure. You'd have to work out the details yourself, but I hope that's enough to get you started.

The right place to post this is over at http://forums.ni.com in the LabVIEW forum where an AE can see the post and start investigating it or searching for an existing bug report. You probably won't get very far unless you can post a VI / VI hierarchy that demonstrates the problem (fixing that sort of bug without a replication case is probably impossible). There are AEs working Mon-Tues-Wed this week, but not Thurs-Fri (company holidays).

A bug in *your* code, not mine, I take it. Yes?

No. It's VIs that don't have friends.The library (this is not specific to classes) is the thing that defines the access scope of its contained items. The library has to know that an item is a friend to grant it access to the community scope. Granting a particular other VI access to a particular VI within the library is something we could have implemented, but fiddling around with that level of declaration is usually noise -- if a VI not in the library is closely bound enough to the library to need a friend relationship, then it frequently wants access to multiple community scoped VIs, and you've already said that you know this other VI well enough to trust it with general access.

Yes, and it has been done. The current system is *after* we made them easier to work with. If you have any ideas, run them up the Idea Exchange, but keep in mind that some simplifications (like getting rid of the Register and Unregister nodes) aren't going to get very far because of the effect that has on performance. The current system gives LV clear signals about how long an event's data needs to be retained. Most other easier to program approaches leave LV with an open ended requirement to keep data around. (Note: This isn't my area of expertise and the preceeding explanation may be incorrect in some fashion.)

If it is listed in the project or is used by any open VI then it is already loaded. It's not a version problem -- that's a separate error code. This error only occurs when the data was flattened with a class of name XYZ and when unflattening there is no class of name XYZ in memory. I don't know (or at least don't recall) the bug that Jarrod S mentioned. As far as I know, that's the only situation you should be getting this error. Look at the actual flattened string... you should be able to see the name of the class embedded in the binary string. Look at the Class Hierarchy window. Is that class in memory?

Usually, this happens when you have a Child class being flattened on the RT system and on the host system, you unflatten it as a Parent class, without the child class actually being loaded on the host side.

Notifiers also share code with the queues. Notifiers are broadcast, so there are data copies when using them because there could be other listeners at any time (listeners are formally registered for user events but not for notifiers, so a copy of the data is always retained in the notifier when it is read by a Wait node). Notifiers are essentially queues bound to a single element and always accessed with Preview Queue. Notifiers also have some "history of this message" code to track whether or not a given Wait node has seen a particular message. Notifiers, because they make data copies, do have jitter on RT targets. But if you're not using them in a time critical loop, they do function just fine on RT targets. All refnum functions in LabVIEW are, and must be, thread safe. Just forking a wire creates thread contention issues, and all refnum types must assume that they will be used concurrently in multiple parallel sections of code.

Probably an accident that this works (and I'm glad it doesn't give access to the private data). There was some experimentation that the math team did about converting the waveforms into classes -- we'd really like to create an inheritance hierarchy around those types, but we've never gotten around to doing it. Perhaps some test code accidentally got bowled? Maybe the two nodes share some bit of "do I accept this type" code that they shouldn't be sharing. No idea. I'm inclined to leave it since it seems harmless enough. As long as it behaves just like the plain unbundle by name node in this case, there's always a possibility that someone has been using it for exactly that and would be upset if I fixed it.

Speaking as the guy who wrote the queue primitives... The queues are meant to be the primary means of communicating data in LabVIEW between parallel chunks of code. They are completely thread safe, and they participate with LabVIEW's concurrency scheduling algorithms. They're designed to minimize both data copies and latency and have been stable for many years. User events go through queues that share most of the code with the general queues, although they have a bit more overhead since at any time there might be multiple listeners for an event, which can (not necessarily "will", just "can") cause more data copies. User events are data broadcasters, where as general queues are data point-to-point transmitters. The general queues thus have less overhead, but it is a very small amount less overhead. For me personally, I prefer the general queues instead of the user events only because of the arcane nodes and special terminals that are required to register dynamic user events. I use user events when I need to have code that sleeps on both UI events and data arrival. But it is really personal preference -- many programmers are successful using user events generally.

True. It was inefficient to do an Equals test on the actual data whenever it was being flattened/unflattened. The only way the default value gets written out is if the value is still the shared copy of the default value. For the record, something I hadn't realized before but recently realized was a side-effect of other decisions: if you use Flatten To String on a real-time target, the non-default flattened string is always what you'll get. On the RT target, we don't share a single copy of the default value (everything has to be preallocated to avoid jitter, so doing a copy-on-write under the hood is unacceptable at runtime). That means that we never use the shortcut representation of the class data.

My answer? NiMOToons.

It is 100% different from start to finish. Whether you can convince your boss is a question only you can answer. The syllabus is available online if you want to review it.

Snippets aren't VIs... they don't have memory of being part of a library or not. They're just nodes that join the VI that they are dropped on.

Check out the "Pricing" section in the course link. You'll find the ability to purchase the course in person, online with an instructor, or self-paced. Yes, December 9, 2010. In US standard notation, the month always goes first. Blame it on the Romans for not establishing a standard system for date abbreviation. I'm actually particularly fond of the Check Republic's solution -- the month is always given in roman numerals. As a result, there's no localization problem for the names of the months, and which one is the month is always obvious regardless of the order of the numbers. The more I work with international developers, the more I like to encourage significant events to be scheduled either after the 12th of the month or on days when month and day have the same ordinal (such as 8/8/2010).

A) Is this in LV 2010? B) Does it involve a library that contains another library? (The inner library can be any type of library -- lvlib, lvclass, xctl, lvsc.) If the answer to both of those questions is "yes," then it's known and should be fixed in LV 2010 SP1. If not, please post a reproducing example on ni.com so it can be evaluated and hopefully fixed.

Not directly... but you make a static dispatch full reentrant VI in your ancestor class that wraps around the dynamic dispatch VI shared reentrant core VI. Instantiate the static dispatch VI whenever you need another LV2 style global. For bonus points, check out the LV2OO style global.

Nope. The code for those dialogs is all written in C++. When a VI compiles, it generates assembly code for its run proc. For those VIs, when they load, we swap the pointer to the code block with a pointer to C++ code already compiled into LV. The diagram never executes.Can you dynamically register for the "Close Panel?" event on every VI in memory? Put up a poll for "all VIs in memory" that runs every 1/2 second or so and register for the "close panel?" event. I don't know how well that would work but it seems like something you haven't tried yet.

You might also consider a model where a single DVR refers to a cluster of the two objects or a third class has an instance of the other two classes as members and you use a single reference to that third class. For the record, you could just fork the wire, but that creates a copy of your object -- potentially expensive. The zero-iteration for loop uses the type of your object and constructs a default object -- which, on desktop targets, is essentially free since we have only one instance of the default object that gets shared around. Because the original class wire isn't modified on either branch, LV doesn't create a copy of the original object. There's another way to get this that might be considered less of a hack -- use the Preserve Runtime Class primitive. Fork your class wire into the center terminal of that primitive and wire a LabVIEW Object constant to the left input. Ignore the error out because there will always be an error doing this, but the output is a default instance of the class of the object on the center terminal.

Doesn't have to be... make the VI reentrant and use Open VI Reference to give you a new reentrant clone each time you want a new LV2-style global instantiated.