Aristos Queue

I read this as "driving snow under my belt" and I thought, "Wow. That's quite an updraft."

I'm going to ignore the rest of your post (others can help out with plugin setup) and focus on the one part that you probably need NI help to resolve. That error you describe should simply not happen. Ever. Any chance I can get you to post VIs that replicate this?

Yeah, and what we discussed there is apparently wrong to some degree. :-)

You know, I never thought about this, but what if we just made it so that the default value for refnums was *always* Not A Refnum? I don't think there's ever a valid reason for having a non-zero default value in either the default value or in a diagram constant. [EDIT] Ah... just saw Omar's post. :-)

No idea. Yes. All that is correct. There's another variant -- the FP could be the thing hosting the typedef, and when the typedef changes, LV will load both the FP and the BD into memory in order to update the FP. The reason the BD loads is because the VI has to recompile to deal with the typedef change. I know that it does change. I do not know how dramatic the change is. Your analysis sounds completely plausible, but I haven't really stayed up-to-date on the source-obj splitting. Up until LV 2009, the default values of controls were stored as part of the front panel, so any time the VI wanted to recompile, the panel was actually necessary to generate the code. Nowadays the default values have been moved out of the panel, and we are inching closer to the day when the recompile could happen with just the diagram without the panel, but there are 25 years worth of code that assumes "if I have the diagram then I know the panel is in memory, so I don't have to test for NULL". It's a low priority refactoring that is ooching forward. On the "reasons for FP being in memory", add "VI is tagged dirty". Same for BD. Do put a note on it that it is LV2010 specific and does not cover the case where source and obj files are saved separately.

Not in the runtime engine (because no BD there), but yes in the dev env. Of course, my first thought is, "How often are you loading broken VIs as part of a running app?" Most of the time, it seems to me, this wouldn't be a big deal. I mean, if you're loading a broken VI, my guess is that it probably isn't a part of the hierarchy you're trying to run, so there are few callers of it that would also be broken. If it is something like a template VI, you're going to need the block diagram anyway to fill in whatever is missing with scripting.

I'm going to try to explain some details of loading a VI. What happens during load depends upon what happened when the VI was last saved, so let's start there. A good VI is one that has an unbroken run arrow. A broken VI is one that has a red X next to its name in the Error List Window because that VI itself has some problem. A bad VI is one that is listed in the Error List Window because some other VI/library that it depends upon is broken. There's a special case involving typedefs, poly VIs, and global VIs that are in the middle of being edited but are at the moment valid typedefs (i.e., they would not be broken if user did Apply Changes). Such VIs have the pencil icon next to their name in the Error List Window. Those VIs are good, but VIs that use them are bad. If a VI was good, then we can compile the VI, meaning we can generate the assembly instructions for that VI to run. If a VI is good, when we save, we compile the VI, and we save the compiled code as part of the VI. If a VI was broken or bad then we can't compile it, so when we save such a VI, we obviously can't save the compiled code. However, a VI might have been good, been compiled, and then become bad without any changes to its own block diagram. In that case, we already have the compiled code for the VI, and so we'll save that with the VI. There's also the special case of a VI that is broken only because it is missing subVIs. We may already have compiled code for such a VI, and so we'll keep that code around if we are asked to save again. (In the case of typedefs, they do have compiled code. They carry the instructions for copying and comparing their data. PolyVIs have no code. I'm not sure about global VIs.) Ok. That covers save (or, rather, it covers enough of save that we can now talk about load). When we use the phrase "a VI is in loaded into memory", we really mean, "some portion of the VI's file is in memory in a way that other VIs may link to it and it can be edited and/or executed." If you use the VI Server method "Read Linker Info", that reads the connection information of a VI without loading the VI -- so although we opened the VI file and read some data out of it, we didn't properly make the VI available to the editor and execution system. Same when the palettes load -- they read the icons out of the VIs in the directories, without actually loading the VIs. There are N parts of a VI, where N is a number I don't remember right now. But for the purposes of this conversation, we can really think of there being just three parts: the front panel (FP), the block diagram (BD) and something I'm going to call "the linker/code block" (LC). That's not a term you'll find anywhere else because I just made it up. The LC is all the stuff that makes a VI be a VI in memory, including: the linker information (the list of other LV files upon which this VI depends), the identity of the VI (which library owns this VI), the compiled assembly code (unless the VI is broken, in which case there is no compiled assembly code), and probably some other stuff not relevant to this conversation. In the development environment, whenever you say File >> Open and load a top-level VI, the LC and FP load into memory. If the VI was last saved as bad or broken or if it turns out to be bad/broken after it finishes loading its dependencies, then the BD also loads into memory. If that VI has subVIs, the LC for all those subVIs load into memory. The FP loads if the subVI is considered necessary (see my earlier post in this thread for things that make that necessary). Both the FP and BD are loaded if those subVIs were saved bad or broken OR if they turn out to be bad/broken once dependencies are loaded. For all VIs, if an edit is needed during load (say, a subVI conpane changed while the caller was not in memory, or a typedef needs to update, or LV version mutation, or updating the path to a subVI), both FP and BD load. In the runtime engine, the BD never loads. Obviously, the BD doesn't load if the VI was saved without a block diagram. In a real-time system, neither the FP nor the BD ever load. After loading the VI (and all its dependencies), if the compiled code is missing and the block diagram is loaded and the VI is not broken/bad, then LV will go ahead and compile the VI and put a docmod on the VI (the little asterisk that means "this VI has unsaved changes"). The FP and BD will eagerly unload as soon as the reasons for them staying in memory are dealt with. So if you fix a broken VI and then save the changes, FP and BD will unload unless the windows are open or the FP is necessary for the VI. If you want proof that the diagram loads independently, try this: Save a caller VI and its subVI. Open the caller VI. In the operating system, copy the subVI file on disk to a temp location. Back in LV, open and modify the subVI's diagram. Save the subVI and close the panel and diagram (keep the caller VI open). Now copy the temp file over the subVI file. Now open the block diagram of the subVI again. You'll get one of the more interesting dialogs that LV has to offer, noting that the diagram saved doesn't match the VI in memory and you can either choose not reload the diagram or do load the diagram which will recompile your VI for the new diagram code. If you didn't save the subVI (meaning you choose Defer Decision on the Save Changes dialog), then the diagram is already in memory and I'm pretty sure you won't get that dialog because LV doesn't bother to check disk for stuff it already has loaded.

No, you didn't misunderstand anything. 2010 is broken. Of course, the CAR didn't get discovered until the day *after* 2010 SP1 was already finalized for release. WORKAROUND: Change the constants going into the For Loop into controls. (The ones wired to the type cast primitives are fine to leave as constants.) I'm really embarrassed by this bug. I'm reviewing our test coverage because this was a fully tested case, I thought. Clearly something isn't right in the test suite for this to have shipped. It WILL be fixed in 2011. Along with a whole lot of other issues. 2010 is really starting to piss me off as a release... it really appears to be a more stable release than its predecessors, with fewer CARs affecting fewer customers. But the few CARs that are in there... wow. It's like some elf went through the code and decided to just move all the entropy bits into one pile so they'd be really easy to spot when we're doing cleanup for 2011.

No, I'm talking about the compiled code block. The source code block *is* the block diagram.

So that the Value property is up to date if you were to read it . Also, if you did open the panel, Copy Data would work right because it would have the last available value. And, when you finish execution, you might want to do "Make Current Value Default".

No. No.A) A VI's code block is not in either the panel or the diagram. It is a separate piece entirely. The panel is not necessarily loaded with a VI. It is loaded for a top-level VI, but subVIs will not load their panels until they are needed unless something in their VI Properties or block diagram indicates that the panel will always be needed. Examples are configuring the VI as a dialog VI in Appearance or having a statically linked property/invoke/reference node on the diagram. B) The panel can be in memory even when not open. C) Reasons for the panel to be in memory include a statically bound control property/invoke node on the diagram, a static control reference node on the diagram, a dynamically opened control reference existing in memory... or the VI could just have unsaved changes, in which case the panel stays in memory. D) If the panel is in memory, for any reason, running the VI takes time to update the controls/indicators on the panel. E) Save will unload the panel if the only reason it had for staying in memory is that it had unsaved changes. You shouldn't think of Save as a way to "fix bugs in LV where LV forgot to unload something." It just clears one of the reasons the panel might be hanging around, and if that's the only reason, it unloads. Obviously if the window is still open, it won't unload. F) It doesn't matter how you invoke save -- File >> Save, Save All, Save All This Project, programmatic save -- all of these will check to see if the panel can now leave memory.

Earlier in this thread, I highlighted a performance problem that I found when trying the test VIs Gotz originally posted. I generated a CAR from that. That CAR finally made it to the top of the priority heap. And, like so many before it, it is being closed as user error. Only this time, the user is me. If you turn off dynamic dispatching, you should indeed achieve essentially the same speeds between classes and clusters. However, if you leave the front panel in memory, you'll take the performance hit of updating the panel controls/indicators. So when you modify the VI to turn off dynamic dispatching, make sure that you close the front panel of the Write Boolean VI and then do File >> Save All before you run the performance test again.

If you Google for connection closed by peer you will find this is the standard description for this error for lots of programming APIs. For example http://technet.microsoft.com/en-us/library/cc957018.aspx This is one of those cases where LV described the behavior using industry standard terms, which is sometimes a "damned if you do, damned if you don't" situation... very helpful for those who know the networking standards and are working in LV, somewhat misleading for LabVIEW programmers working with networking standards.

That's the inverse of what I was arguing... you're saying "don't use Object if there's a more specific term that applies." I'm saying "If you do use Object, it better be because you're applying to a generic hierarchy."

Libraries allow for private methods, so the encapsulation of methods would not be a reason to keep these collections as classes. No, he's not. That's the whole "stateless" part of his original post. With no data in the cluster, and no inheritance to add any (either real data or the meta data of runtime type), there's no object instantiation at all. I would consider it a style fail to name a terminal "Object" unless the terminal was some type of class (LV class, .NET class, VI Server class, etc).

Merely uncommon.

Nope, it can't go on the FP of a panel because that would enshrine private data as a public interface. As a control, that would make it possible to set private values in ways not allowed by the class API, leading to logically insane objects (i.e., objects whose private fields are inconsistent with each other according to the rules as defined by the class methods). As an indicator, that would be more acceptable, but it would still be showing the private aspects of a class which would be inappropriate for a typical user of the class (by which I mean a programmer who is using the class to write another program) to know about. We deliberately did not include this ability because, we thought, "Hey, we've got XControls, which address this problem!" The expectation was that XControls would be the means by which a class author defined the display of the contents of the class, displaying the information that was appropriate for a given class to display. Classes and XControls were designed simultaneously, and it turns out that the labor of building an XControl is extremely high, something we didn't really grasp until XControls had been in user hands for a couple years. We have played around with ways to change XControls to lower the labor costs, with minimal success. My own opinion -- and I haven't really discussed this with the rest of the team, so I don't know if there's consensus here -- is that we just need a whole new "something" for class authors who want to define the display, something with much lower labor requirements. That something is going to take a while to build, and working on the problem at all is, at the moment, a lower priority than other projects.

I would say, yes, you should demote it to a mere library (although, since it already is a mere library -- because a class inherits from a library and thus fulfills the "is a" relationship -- it might be better to say "only a library"). If the situation is as you describe, then the functions are just a collection of VIs. Creating a data type and then not using it is just wasting system resources, however small they might be. And, implied in that, I would not have Object In and Object Out terminals. What would be the point? If you wired them, all you would be doing is creating false data dependencies between functions. Now, having said all that ,before you actually build the new library, I'd pause a while and ask, "Am I absolutely certain that these functions belong together at all? What data *are* these functions operating on? Should they be packaged with whatever class represents that data?" Maybe they really are math operations or string utilities, but I don't see many programmers creating large libraries of those.

Oh, actually we have... alliance members don't produce NI products, but they sure as heck provide support for them, often in a contractually binding way. :-)On another point... earlier someone mentioned the distinction between quality products and quality support, and I was thinking that there would be an obvious solution -- separate our certification into Gold Product and Gold Supported Product, or something like that. But I got to thinking -- part of being a quality product is that it gets at least enough regular attention to continue operation as time goes by. Maybe no one is actively adding features, but making sure that it works with the next version of LV, or the next version of the operating systems, or the latest hardware. Without some sort of committment there, it would be hard for a mission critical project to adopt an OpenG tool, unless they had the internal staff expertise to update the tool when LV/OS/HW changed. That's a very different kind of support than the "I have a bug, can you find me a workaround" type of support. We haven't been discussing that sort of "updating" support, but I think that is possibly more important than the "I have a bug" support. Thoughts?

That's unfortunate. Only those of us who work on pre-alpha builds of LV should ever develop the save-continuously reflex. Definitely need to get LV 2011 out stable!

Ok. Turns out no user has ever asked to do that before, and since the Sim team wasn't aware of OO features and the OO team wasn't aware of Sim features, no one knew to proactively add the feature. So simulation diagrams do not support dynamic dispatching. I filed the CAR (#280810) so that it gets attention. I tagged the CAR for LV 2011, but because we are fairly late in the dev cycle for the release, it wouldn't surprise me if the fix has to wait for a future release.I'm sorry you got burned by this communication failure on our part.

I've heard of that module but never worked with it. Let me ask around and see what I find out.

Been working on LV for 10 years, but I have no idea what "New simulation subsystem" means. Is this some module or toolkit addon? If so, which one?

Using OO to mitigate the problems that arise when hardware is obsoleted before the system that needs that hardware goes obsolete: http://zone.ni.com/devzone/cda/epd/p/id/6307 (There are two examples attached to this document... use hal_version_2.zip, as that's the one that has been recently revised. We're leaving the old one up as reference just for a short while in case people are still using that as a reference example.) You might also hunt around for one of the "creating a framework that 3rd parties can plug into" examples.

I am closing this CAR as Not A Bug. I realized later that changing this conflicts with our UI guidelines that we established for LV classes. A VI that is static dispatch could have the unshared clones setting enabled and then the user could change it to be a dynamic dispatch VI and then to unbreak the VI would change the settings to use shared clones. Likewise, a VI that is currently shared clones and dynamic dispatch could need to be changed into a static dispatch VI with unshared clones. When there are two directions for setting a pair of settings, we do not want users to have to change them in a particular order (i.e., graying out one setting until you fix the other one) because the direction is arbitrary: should we gray out turning off dynamic dispatch as long as the VI is sharing clones? If the options are mutually exclusive, that would force users to have to turn off reentrancy entirely, then go change from dynamic to static dispatch, then come back and switch on the right form of reentrancy. Also, with the gray out, there's no place for users to learn why the option is grayed out. For LV classes, we have tried very hard to instead follow a policy of breaking the VI when settings conflict and giving a thorough error message to explain the conflict, rather than trying to force any particular order for configuring your VI or class. Therefore, I am closing the CAR.