Aristos Queue

And I will file a bug report to look at that specific error message and try to improve it. [LATER] CAR 294353 filed.

If you want to use it elsewhere, I suggest you'll need to use the "Seconds To Date/Time" primitive and then write that cluster to the config file. I think that's the only way to get a portable version of the data. Even if you knew the encoding, you'd still have to have that other system know the epoch.

The failure was not in the software developer who spec'd the device, but in the software manager (aka king) who poorly specified design requirements. The software developer actually spec'd out a really nice breakfast food processor. If that wasn't what the king wanted, he should have said so. I hope that the monarchy is overthrown by angry subjects a decade later when they find out that in the republic next door, food replicators are commonplace.

I'd like to answer: why don't you stupid use the VI Documentation? and why don't you use the text-tool in the BD? Or just paste an entire picture into your source code, like the flow chart, or hardware configuration... Define "major release"... VS put out versions 2003, 2005, 2008, and 2010. Are these major upgrades? They completely keel hauled the user interface between each one. They've got a two year cycle, most of the time. And the entire .NET language is revving once per year, a very fast cycle time. LabVIEW specifically and NI generally tries to strike a balance between putting out new features (which is the only thing users are really willing to shell out money for) and patching existing features, and between backward compatibility and forward innovation. I think we're doing a good job when I compare us against the other tools that I have to use. Yes, the speed is blazing and it is hard to keep up, but I think LV's front panel is a perfect example of what happens if we don't rev every single year. We took our eye off of that particular ball for a while, focusing on improving the compiler, making new toolkits, expanding diagram syntax, and in just a couple years, instead of ooching along with small differences annually, the panel looks really dated, and everyone comments on it. My theory is that LabVIEW as a whole would suffer that same rapid slippage if we didn't try to rev continuously, and the cost to catch back up -- as we're seeing with the panel -- is substantial.

Back in February, Daklu asked me to review this thread, but I missed seeing his private message. Sorry about that... For good error handling, the "error case structure" (hereafter called ECS) only needs to be on the leaf subVIs. In other words, if your subVI is composed entirely of other subVIs or built-in nodes that already check for error, there's no reason for your subVI to check for error. Adding the ECS just adds an unneeded check. It improves performance in the error case, which is the less common case. Is the hit minor? Yes -- just a single "test and jump" assembly instruction. Can that hit be devastating? When replicated thousands of times, yes. On the next topic, how many of you would consider this to be good code? Having error terminals on data accessors is equivalent to this. It's a complete waste. This may make you ask, "So, if that's your opinion, and you wrote the templates for data accessors for LV classes, why do the templates have error terminals?" Well, my opinion isn't the only one that matters. :-) And I am the one who later added the options to the dialog to create accessors without error terminals. At the moment, there's no performance hit other than the case structure check to having the error terminals. However, LV's compiler continues to improve, and in a not too distant future (maybe next year), the version without the case structure should see a significant performance boost over the version with the case structure. The compiler can do more to optimize code that will always execute than to optimize code that conditionally executes.

That would introduce a nasty race condition into user events. Consider this block diagram. Under LV's current scheme, the Event Structure is guaranteed to hear the event. If you changed the behavior of the Register For Event node to not actually do the registration, you would miss the event. That safety net makes possible a number of event architectures that would not otherwise be possible. Moreover, the Event structure would have to redo its registration every time the while loop iterated, which would either be a performance penalty or another timing hole, depending upon how it was implemented. The view inside R&D seems to be moving toward, "If a user had found this during the LV 6.1 beta, we would definitely call this a bug and change LV to break break the VI unless there was a case for every dynamic event. But it has been there for 9.5 years. So how the heck do we fix it now?" I don't know what if anything will happen with this CAR. It is getting a thorough debate. At the moment, it could be anything. Ideas I've heard include just updating the documentation, doing something special during Execution Highlighting to show that the event fired but nothing happened, mutating to have a default case, or mutating to add a no-op case for every dynamic event and *then* breaking any future VIs that violate the rule. We'll see what the future holds.

This thread is about generation of errors. Please do not tangent off into handling of errors, except insofar as generating one error to replace one from upstream is a form of handling. I'm asking this question partially as LV R&D, with an eye to the future, but more as a CLA user with an eye to writing code that is good style. In the question about dropping warnings, this is the type of programming that I mean:

Step 1: Archive your entire application. If any of the following fixes the bug, I would still like the corrupt version archived if you can possibly share it with NI. I don't care how large your application is... if you can share it with us, we'll do the work of extracting and isolating. Step 2: Load your corrupt VI, do ctrl+shift+click on the Run arrow. Then run your app again. Does problem go away? If yes, proceed to Last Step. Step 3: There's really only one way that this can happen -- the unbundle node is indexing the wrong memory address. So let's assume that node is actually corrupt and no amount of recompiling will fix it. Delete that unbundle node and drop a new one from the palettes. Run your app again. If that fixes the bug, proceed to Last Step. Step 4: Still broken? In that case we have to look for something more exotic. Are you using class properties? They're brand new in LV 2010. I haven't heard of anything like this, but newest features are the most likely culprits, so move the accessors out of the property nodes, replace the property nodes with subVI nodes, and let's see if the problem goes away. If it does, proceed to Last Step. Step 5: Proceed to Last Step, but despair of having a workaround because that's all that I can think of. Last Step: If any of the previous actually fixed your bug, do File >> Save All and keep working. Please send the archive to NI if you possibly can.

I see FPGA as one of the more critical platforms to have OOP supported. I pushed really hard for it despite a lot of doubt from others. I understand that it isn't typically done, but as I see it, that's largely because in most languages, objects tend to be reference based and don't deploy to the FPGA, so FPGA programmers never get used to thinking about them. Class encapsulation provides protection for data. It allows a programmer to prove -- conclusively -- that a given value is definitely within a given range, or that two values always maintain a particular relationship. Most academics researching software engineering tell me that OOP improves debugability and code maintainability as code base increases in size, regardless of what the task of the software is. That to me means that the more important that verification and validation are to a platform, the more valuable OOP becomes. FPGA programming is often used for direct hardware controls, often in some very high risk domains, situations where you want to be damn sure that the software is correct. OOP is one programming paradigm that helps assert correctness of code. You could pass raw numbers around through your program, but a little bit of class wrapping can help make sure that numbers representing Quantity X do not get routed to functions that are supposed to have numbers representing Quantity Y, and, more importantly, that only meaningful operations on X are ever performed. Class inheritance provides better code reuse. It's true that dynamic dispatching at runtime cannot be done on the FPGA. The compile fails unless every dynamic dispatch node can be processed at compile time to figure out which subVI will actually be called. However, if you're writing many different FPGAs that each have a slight variation in some aspect of their data, it is a lot easier to change out the upstream class type and override one member VI than to "Save As" a copy of your entire VI hierarchy, change a cluster typedef, and rewrite a core function. It can be. It just often isn't because so many folks think in references instead of in values. With LV's compiler, the classes are proptyped through the entire VI hierarchy to statically determine every dynamic dispatch, then are reduced to clusters, and from there the rest of the FPGA compilation takes over, which allows parallel operations on multiple elements of the cluster. So OOP code written with LabVIEW classes does often get that parallelism kick. Even when it doesn't take full advantage of the parallelism, running on an FPGA is sometimes done for speed, and being able to deploy an OOP algorithm onto HW may be important to some folks.

What in the world does this have to do with XControls?!?!

After the CLA Summit on Monday, I did come up with an interesting idea that uses this approach. Consider this: There may be issues with this approach, and it may not be intuitive, but if I can quickly come up with a use case like this, it means that someone out in the world may have used this same idea for an actual realworld VI, which would make it hard to mutate away. And it might actually be a useful approach -- I'm not sure... someone might want to try it -- which would really enshrine its behavior. :-)CAR 288741 has been created by Norm Kirchner to track this issue. I added the URL of this discussion thread to the CAR.

Yes. Hold down the ctrl key and click on the Run arrow button. That will force a recompile. If that works, please don't save over the busted VI until you post the actual VI and its subVIs to the forums at ni.com so that we can investigate that code for a compiler bug.

If you do New >> VI For Override on a class, the dialog that appears has an asterisk next to any VI that is marked as Must Override. Perhaps we could tweak the error feedback in this area.

For the record, all of the built-in items that you see when you pop up on something in LabVIEW are dynamically built every time you right click. Performance hasn't been an issue there, and some of our menus (say, the "Select Class" menu when you pop up on a VI Server refnum control) are pretty intense -- both long and deeply nested.

Because some people like to think of NI as the Sith Lords of the Empire constantly oppressing the LV users, while the LAVA jedi fight for freedom and openness. It's a bad comparison... after all, you couldn't pay Emporer Palpatine enough to treat you well. NI, on the other hand, has a well defined price list for good treatment. :-)(And now I need to get back to testing the driver software for this new Purple Lightening Generator that NI will be releasing soon. I wonder what we plan to use this for and why we seem to go through beta testers so quickly...) The packed library should be a good way to create a plugin, but you have to play by the rules. (I say "should be" -- I haven't done it myself, but I've heard testimony from others.) 1. A packed library absorbs all the subVIs and other dependencies needed to support its public VIs except 2. VIs and dependencies owned by other packed libraries. That means that you need to make your root class be a packed library so that when you make a single plug-in into a packed library, it doesn't absorb the parent class. Instead, it uses the parent class in the packed library. Then you write your entire framework in terms of that parent class in the packed library. To put it another way: 1. Write Parent.lvlib:Parent.lvclass 2. Build packed library of Parent.lvlibp:Parent.lvclass. 3. Write framework using Parent.lvlibp:Parent.lvclass 4. Write Child.lvlib:Child.lvclass. 5. Build Child.lvlibp:Child.lvclass. Any other class that is going to be used by both your Parent class and your child classes needs to be inside that Parent.lvlibp.

So, ash69 came by my desk to talk about this, then asked me to write up what's going on so he can keep his "one hit wonder" status. He likes being wonderful. Your problem is pretty straightforward. The class in your project is x.lvlib:y.lvclass. The class in the packed library is x.lvlibp:y.lvclass. That single letter "p" is critical -- these two classes are not the same class. There is no guarantee that they have any internals that are the same -- in your case, they happen to have the same private data definition, the same function list, etc, but they are two completely distinct classes, and you cannot just convert one class into another class. We can discuss at length why LV packed libraries are designed this way, but that's not going to help you with your problem. The solution is easy to explain, and a pain in practice. You should build your class -- and only your class -- into a packed library. Then build your current packed library using the class packed library -- it will use the class packed library as a dependency, but won't suck it inside itself. Then use the class packed library in your project. After all that, you will have the same class in your project as in the packed library, and then passing data will work. So, there you go. I hope that helps.

You mentioned properties were involved. That *might* be addressed in the 2011 beta. Are you part of the beta program? http://ni.com/beta

Excellent writeup. Daklu: Am I correct in guessing that "Output Queue" is a class that specifically only exposes a Dequeue method and "Input Queue" is a class that specifically exposes only an Enqueue method? You don't explicitly call that out in your text, but it seems like that's what you're doing.

Thanks, Relf. That tells me that something is causing the parent to recompile. But what? And why? In other words, it's a harmless change, and we're recompiling to exactly what we were before the recompile, but we shouldn't even have to do the recompile.> I was working on classes extending from those defined in the messaging library Any idea what you were actually editing?

Depending on your role in your company, you might consider prioritizing the CLA Summit over NI Week. If you're the sole rep for your company, then by all means, NI Week is the greater source of information and exposure, but if others from your company will be at NI Week and can attend sessions and report back to you, it might be worth letting them take it. The CLA Summit was highly educational last year, and I'm expecting similar this year.

I'll see if I can get someone who actually understands all the details to post. I'm definitely not an authority on event registration.

No, he's not. It's a design limitation that I've wished were fixed on multiple occasions. The problem is the one-to-one relationship of the registration refnum to the event structure. You should never share registration refnums with two different event structures -- that way leads to DOOM. As such, it makes little sense for the event registration refnum to be stored anywhere or passed around very much. The one-to-one relationship of that refnum to a given event structure is an invariant that can't be solved well... I barely understand the rationale, so I'm not going to try to explain it here. I accept it as proven by those with more comprehension of parallelism than I. So what is likely needed is an intermediary "event cluster" type, that packages all the event information together but without actually creating an event registration refnum, and could be passed to a Register node directly. Most approaches seem like a pretty hefty complexity jump for what is already a complex use case. PS: You should also not change which dynamic refnum a given event structure is using during the run of the VI. You can change which events are registered, but you should use the same registration refnum.

I've never replicated any claim regarding this. There is no code that I can find that would cause this. Do you have VIs that replicate this?

It's neither a bug or an undocumented feature. It's the control doing exactly what all controls do. If I have a numeric control and I say, "Make current value default", and the current value is 3, then thereafter the default is 3. With a reference number, the same thing happens. If the current value is "0x33445522", and you say "Make Current Value Default", then the default value thereafter is "0x334445522". The control does *not* allocate a reference ever. It returns that (probably invalid) refnum. I (and others) thought that a control/constant of these types were always default of Not A Refnum, which would be undocumented special behavior. But, no, it's just the same behavior as all other controls. What you have to remember is that the controls store a reference number, not the thing that is referenced.

In the TOS, NI grants a limited right to use its trademark for the purposes of linking. Then the TOS specifies that the company can revoke that right if you abuse that right by putting their trademark on a page that is obscene or disparages NI. That I believe would be completely legit under trademark law. It is NOT saying that you cannot include a hyperlink to ni.com from one of these sites, only that said hyperlink cannot use the NI trademarks.