Aristos Queue

There are two sources for this error. The most probable is a bug in LabVIEW of some sort. The less probable, but worth checking, is a Call Library Node in your own code that is calling a poorly written DLL or a poorly configured Call Library Node that doesn't match what the underlying DLL is doing. The memory manager can be messed up if a DLL modifies a piece of memory that LV did not expect it to modify. If you aren't using DLL calls or if you already checked them for correctness, then it's probably an issue inside LV. The correct action at that point is to contact an NI Application Engineer (through the forums or by phone if you have a support contract) and see if they can debug what's going on. They can escalate a CAR and may be able to provide a workaround.

I posted a small tidbit of useful info over on ni.com for those of you who like to squeeze every drop of performance out of your LV code. This tidbit involves avoiding data copies when doing type testing on objects: http://forums.ni.com/t5/LabVIEW/Performance-tweak-for-LV-Classes-and-quot-To-More-Specific-quot/m-p/1760322/message-uid/1760322#U1760322

It's kind of true thanks to the way objects are encoded. When designing the flattened data format of LV classes, I really didn't give any consideration to someone deliberately mucking about with the string. That could have meant a serious problem that all objects would have a backdoor way of setting their values. But -- as several determined hackers have griped at me -- I also tried to minimize the size of the flattened string. As a result, the format of the flattened object shifts to three different forms, default fields are not written into the data at all, and there are various size checks that all must be preserved. All of this means that in many cases, it is tricky to reach into the flattened string -- even using the XML format -- and make changes.Honestly, I made a big mistake in making the Flatten To String and Flatten to XML primitives work on objects by default. The other major programming languages of the world all require classes to opt-in to such abilities. They are not serializable (meaning "can go to/from string") by default. The only ones that are serializable are the ones that programmers declare that way deliberately, and then they have code in the unserialize method to check for tampering, if the class has critical internal data relationships that must be maintained. We lack any such hooks in LabVIEW. It's one of the few areas of LV classes that I wish I could retroactively redesign.

This appeared on the Idea Exchange last week. Pause on first Error - option for debugging http://forums.ni.com...g/idi-p/1751590 Why only 10 kudos? The page has had more views than that. When I saw this, I immediately thought of all the times I had tried after the fact to decipher a call chain or gone into a VI and deliberately deleted all my error wires just so that Automatic Error Handling would trap my error on the spot. If this worked like an Execution Highlighting button on the button bar, I think it would be great. Thus, I'm posting this idea here on LAVA to give it a second chance at exposure.

May I suggest you find a book called "Beggars in Spain". It is, like Atlas Shrugged, fiction wrapping philosophy, and it is both a counter and an evolution to the Rand ideas.

Yes. Pantomime is far more important as a skill. Trust me: knowing the right gestures helps communication between LabVIEW architects.

One thing the page does not mention: TestStand cannot directly invoke dynamic dispatch VIs. You must create a static dispatch VI as a wrapper for the dynamic dispatch call. This limitation is expected to be eliminated in the next version of TestStand.

> is this functionality exported in any way that we can take advantage of it in classes? Not currently. Those are marks on properties of C++ classes. The LV classes have no such designation. Not a bad suggestion. I'm guessing this would be a property you would set on the Property Folder, not on the VIs themselves. It would be up to you to still recolor the icons of the VIs if they were being used somewhere directly instead of through the property node. We could do it on the VIs, I suppose, but at that point, I'd want a much broader feature for deprecating VIs generally that had nothing to do with classes. Hmm... would you ever want to deprecate only the read or only the write half of a property? If that's a use case, it might be better to be on the VIs themselves. Anyway, think about it, and then throw it on the Idea Exchange. It's a worthy suggestion but not one I've contemplated before. I'll ping Mr. Mike on this topic... he is the member of my team that owns the property node interfaces.

Could you just draw the image in a Picture Control and then change what you're drawing there? Or are you actually needing to edit a whole bunch of VIs to change one image for another (like, say, a corporate logo changing) ?

The easiest way to count the button presses is to use the Event Structure, like this: Every time the button gets pressed, the value in the shift register gets incremented by one. Look at some example files (use Help >> Find Examples... in the menus) of usages of the Event Structure. You probably also want to combine this with a basic state machine pattern. You essentially have 3 states: "Draw the two colors", "wait for button to be pressed", "Evaluate results". You can code that up like this: In the "Wait For Buttons" case, put the Event Structure. In each case, you decide which frame you want to happen next. Sometimes it will be a fixed constant, sometimes there will be some decision about which frame to go to next. This is the state machine pattern and there are lots of good examples of it, also, in the Example Finder. Good luck.

A bit of history here... when the icon FP Terminals were first added, I didn't like them and asked they be removed because all they did was reflect a few FP controls/indicators. Those who do the usability testing on LV said that it benefited newbies to recognize the association between the thing they dropped on the panel and the thing they dropped on the diagram. I sighed and said, well, if we're going to have icons, they might as well be *useful* icons, so I made the VI Refnum reflect conpane, made the other refnum types show something other than just the folded corner of paper, made the typedefs show their control icon, and made LV classes show their type icon (originally they were all cubes). And then, as time went by, they started growing on me.Maybe it's just prisoner syndrome and I've started identifying with my captors.

My comments on this topic are here: http://forums.ni.com...c-p/927234#M577 After you disagree with me, you can add your kudos to the idea exchange entry. :-) Proud to be a unicorn!

As is standard with these requests, please post your initial attempt at writing the VI and then we can help make adjustments, but we cannot help with nothing to start from.

I am sorry... I still don't grasp what you're asking for. I am guessing that English is not your native language and you're using translation tools to post. Something is being lost in mechanical translation. Could you try posting your question in your native language... there may be someone on the forums that can provide a better translation.

Based on mje's final version... Progress Bar.vi Progress Bar DEMO.vi Thanks for the feedback.

Here's a better example of the use of the Occurrences. Here it is used to implement efficient dequeue from multiple queues. It was built using the instructions: "Build the system with polling first, then add the occurrences to avoid polling." Note that you shouldn't actually use this example directly if you are going to wait on multiple queues because there's a starvation issue -- if the first queue gets heavy with elements, the consumer loop will never get around to dequeuing from the second queue. You'd need to put some fairness into the consumer's behavior to make sure it checked each queue equally as often for elements, maybe by rotating the queue array on every iteration of the consumer while loop, or something like that. Left as an exercise to the reader... this post is just about Occurrences. What's that you say? There are times when the loop will execute a poll when there's nothing to do? There's an extra iteration after every dequeued element just to prove that the queues are empty? Yes, you're correct. That's how the occurrences work. They are not the signal that there *is* data waiting. They are the signal that there *might* be data waiting and it's a good time to go check. This is their intended design because they are deliberately as lightweight as possible so as to be the atomic unit of locking in LabVIEW. Consider what would happen if the two producer loops both did "Set Occurrence" at the same time without the consumer getting an iteration in between, something that will happen every once in a while. Handling that case is why the consumer loop has to do its own secondary polling. The intention is that occurrences are used to write higher level APIs, and those higher APIs give the calelr the illusion of "I'll actually wait until data is available". And this is why occurrences are almost never used by LabVIEW customers -- those higher level APIs already generally exist. Here's the VI, saved in LV 2011: Wait For Multiple Queues.vi

I don't think that's true. Note that although the template today uses primitives that I wrote, older versions of the template existed before I started at NI, so I can't be certain of the intent -- I don't even know where they originated -- but to me, the master/slave pattern is useful because the master may change its mind about the next direction. The slave carries out some order. In the interim, the master may change the next order several times. This occurs during navigation type operations, where additional data is coming in all the time about road hazards, so the information sent to the slave is the master's "best guess for next action", which may be changed frequently. It needs to be sent and updated continuously because the master has no idea when the slave is going to get around to asking for the next instruction. Day trading applications use this pattern, with a master system evaluating the market and multiple slaves responding to "buy this" or "sell that" orders, orders that might be redacted before they are actually acted on. You're missing something bit: Notifiers have an implicit message ID system. The "Preview Queue Element" node will copy the front element of the queue (assuming the queue is not empty) every time the loop repeats. The "Wait For Notification" node will copy the element of the Notifier ONLY if this particular Wait node has not seen this particular notification before. That means that the Notifiers are not only a broadcast mechanism that wakes everyone up when a notification is sent... they are a mechanism that guarantees that each listener is woken up at most one time for that notification. This is covered in the documentation of Notifiers and various other places on the 'net if you want more details. Short version: You cannot effectively build a Notifier out of the Queue primitives without introducing some reentrant wrapper VIs that store state so that each Wait call can remember what message ID it saw last. Even more, you cannot build "Wait For Multiple Notifiers" at all without turning to some sort of polling mechanism inside those reentrant VIs or reaching for the very low level Occurrences and using the less-than-intuitive canonical correct usage pattern for Occurrences that I posted last week. [Later] I went ahead and built the "wait for multiple queues" example because it was such a good example of the purpose of Occurrences. You can see it here.

Although it is true that the loop that handles messages does wait for the next message, each Actor may have one or more additional control loops in its Actor Core.vi. I suggest that the reason you don't see anything like what you suggest in the Actor Framework is the existence of these separate control loops. If I needed any "do this until you hear otherwise" behavior in one of my actors, I would encode it in the control loop. An example of that is in this Actor Framework demo in the Temperature Sensor class, where the sensor polls for the current sensor value every five seconds in the absence of any other message.

I'm confused. Please define "native implementation". That VI is doing exactly what LV does under the hood in the C++ code. I'm not sure how much more native you can get. And, to answer Yair's question, no, there's no flattening of the variant involved.

I know the conversation earlier had comments about other ways to make this work, but none of them highlighted that the current way didn't work. I just don't want anyone who Googles this site to think that the Network Queue implementation here is fully functional. For non-timeout cases, it works, but it has some nasty lurking bugs.

I put my comments in the Idea Exchange thread.

Ooo... bad choice of phrasing on my part. When I said "it's an annoying bug", I meant "It's a behavior that creates an annoying bug in user code that is often hard for them to track down."

As long as the primitive has existed to the best of my knowledge, but I couldn't check any earlier than 5.0 today... didn't feel like digging out older installers. If you ever undertake to write the queues or notifiers completely in G, you'd need the occurrences. It can be done, and the main reason it isn't done today is the polymorphism of primitive nodes. You wouldn't use the occurrences as the keys for looking up data for a particular refnum, but you'd use them for triggering various interactivity between read and write VIs and the timeout mechanisms.

> you're going to need another copy of the code saved into the other LV version anyway, right? Not if you turn on Source Only which allows us to have multiple binary versions for the same source VI.

There's no way in scripting to get a runtime value from a wire or a raw terminal because they don't have values -- they all share values through the inplaceness algorithm and the memory address that is used for any given terminal/wire is not unique to that term/wire. You can ask a control or indicator for its value, although opening that control reference will have a performance impact on your code since now a copy of the value will be made to the UI layer when your VI runs (just as if you had the front panel sitting open).