Aristos Queue

QUOTE(yen @ Oct 5 2007, 06:11 AM) That is wrong. It is all VIs in memory in all application instances. It always has been in all versions of LV.

CAR 4E3FECJ1

All the VIs in memory, across the board, including the private ones that are part of LV itself. The only exceptions are VIs that are currently reserved for running. If a VI is not in memory, it doesn't get recompiled. LLBs have no meaning after loading, so the fact that one VI from an LLB is in memory doesn't cause the other VIs in the LLB to be recompiled.

I LOATHE THAT ERROR MESSAGE. The message you are seeing is the message for error code #1. Error code 1 is "bad input to function." It is the least helpful error message in LabVIEW. In an attempt to make it more helpful, someone added the information about looking for a badly formatted path. Now everyone assumes that this error has something to do with paths. It doesn't. You can get that error code from lots of places. The Enqueue primitive returns it if you try to enqueue into a refnum that has already been released, for example. :headbang: Having said all that... this one probably is path related. The "addendum" onto the standard error text says The file '' is not a valid LabVIEW file. My guess is this... there's something that your exe is linking to (probably a DLL) that is the problem. Your EXE was built and saved in a directory something like c:\alpha\beta\gamma\MyApp.exe. The DLL was located in c:\XYZ.DLL. So the EXE stored the path "..\..\..\XYZ.DLL" . Now you move your app to another directory such as c:\muchhigher\MyApp.exe. When LV tries to change directories up three levels to find the DLL, it ends up with an empty path that it can't do anything with. Now, all this is just a guess. But I'd look around for something like this.

Go, Jim, go! Jim answered most points. There's only one other to which I want to reply. QUOTE(Gabi1 @ Oct 3 2007, 09:24 AM) Any tree can show only a single hierarchy. It is logically impossible for a tree to show multiple indepenent hierarchies. Although LV R&D has been working very hard to invalidate the logic of the universe on several key points, at this time, we are unable to circumvent "A == A" and "1 != 0". The project tree shows the ownership hierarchy (so if a library owns your class, the class will be listed under its owning library). It does not show the VI call hiearchy. It does not show the LV Class hierarchy. It does not show the disk hierarchy (though in LV8.5, we added a second tab to the project that shows the disk hierarchy). It does not show the palette hierarchy. Other tools -- such as the two hierarchy windows -- exist to view other relationships between elements. If we want to show many different types of relationships in the same display, that requires a graph, not a tree, which might be more complexity than many people care to deal with. So the project window remains a tree. However, one excellent tool for displaying and interacting with the graph will soon be released. Keep an eye open for the UML tool from Endevo which should be available soon.

QUOTE(rolfk @ Oct 2 2007, 01:29 AM) You have this. You can set it in "Tools>>Options", but it is also available at "Edit>>Disable panel grid alignment". It even has a shortcut key.

The delay in replying to all the points here is a) I've been out of the office and b) I got a new computer that can build LV really really fast so I no longer have huge pauses during my day to check and reply to LAVA. I will return to this project, but it'll probably be a bit. I do want to get answers posted to the various questions, but this is sort of an ongoing side project rather than mainline work, so it keeps getting deprioritized.

QUOTE(alukindo @ Oct 1 2007, 08:58 AM) Sorry I wasn't more helpful. Over the weekend I didn't have time to type an actual reply and I thought you might be stuck waiting for an answer to this question, so I figured I'd encourage you to keep searching by assuring you there was a post out there that covered it. Reminds me of a joke. How do you search for an elephant in Africa? The novice programmer wanders around randomly searching for an elephant. The experienced programmer walks back and forth, scanning Africa latitude by latitude, searching for an elephant. The master programmer does the same as the expereienced programmer, but he puts an elephant at the tip of South Africa to make sure he stops eventually.

This is a well documented aspect of LV. You should be able to find an answer by searching LV's online help. If not there, I guarantee there are posts here on LAVA about it.

QUOTE(PJM_labview @ Sep 29 2007, 01:36 PM) Then change the layout of that VI to be a size 13 grid. But to open existing VIs with random (effectively) grid sizes such that the size used to achieve that layout is not preserved makes it impossible to make adjustments without blowing away the layout. You mentioned the arrow keys and alignment tools. Those predate the alignment grid. They were ruled insufficient for laying out at VI. The alignment grid makes it possible to quickly do layout using certain rules (buttons should be XYZ size, controls should be N pixels apart, window border around controls should be Q pixels...) without having to count with arrow keys or copy a screenshot of the FP into a paint program to count pixels. By your argument, the background color of the VI should change when loaded on a system where the programmer has changed the default background color instead of being saved with each individual VI. The grid size used to construct a front panel is integral to preserving the look/feel of a VI.

Developer A writes a VI with grid size 10. Developer B opens the VI on his machine to add a control to the FP. His default grid size is 13. If we used the environment setting for VIs when they were opened, instead of having each VI remember its alignement, then no matter which grid square Developer B uses, the new control does not drop aligned with respect to the other controls already on the FP. The environment setting is the grid size for new VIs so that you can define the layout for each new VI. But after a VI is made, edits to that VI should stick with the layout chosen for that VI. Thus each VI remembers its own layout. No, there is no programmatic interface (not even with some magic .ini token) for setting the alignment grid size on a VI.

QUOTE(NormKirchner @ Sep 26 2007, 06:02 PM) Translation: An element of class Alpha is a control of class Beta. You want to set the default value of this control to be Gamma, which is a child class of Beta. To do this, you must have LV8.5. It won't work in LV8.2. Open a blank VI. Drop a control of type Gamma. Popup on the control and choose "Copy Data". Then go to the private data control of Alpha and popup on the Beta control and select Paste Data. Then popup again and choose "Make Current Value Default." Save Alpha. Viola!

QUOTE(Ben @ Sep 25 2007, 08:50 AM) Sorry, Justin... Ben is right. When you're playing "hide the dots" on an RT system, order of terminals does matter.

QUOTE(BOBILLIER @ Sep 21 2007, 07:03 AM) One of the uses of tags is to tag copyright information onto the VI. Another use is to tag a VI that was created by a "wizard" tool. Then when the user opens the VI to edit it, the wizard tool, running in the background, can see that this VI has the tag on it and know to intercept the VI and instead open the wizard up to be the interface for editing the VI. Ultimately, however, you ask for a use of the tags... tags are not published parts of LV and were never designed for non-NI use. Thus any use you come up with for them is not something intended.

QUOTE(BOBILLIER @ Sep 19 2007, 11:02 AM) Objective reasons to use the VI's conpane or some form of VI-to-VI communication: 1) Using a tag is a global storage mechanism. You could just as easily use a Global VI or LV2-style global or, as has been mentioned, Set Control Value (variant). The advantages of the Global VI or LV2-style global is that you can use Find to detect all the places in your code where you are reading or writing the value. With Set Control Value or the tags, you have no such mechanism. 2) Making it part of the conpane means that LabVIEW can do some dataflow optimization as far as copies of the data are concerned. In your case, the data is small, but this would be something to consider if you're passing larger amounts of data to the VI via tags. Tags are extremely heavyweight compared to direct wiring (in fact, tags are more heavyweight than Global VIs in terms of how many times data gets copied during the transaction). 3) Reading and writing tags requires switching to the UI thread in order to be thread safe. That will slow down code. 4) Reading and writing tags is not type safe at compile time. You put the data into a variant; you pull the data out of the variant. No type information exists on the diagram, so if you change the type of the data you're writing into the tag, you won't know until runtime that you forgot to change the reader of the tag. 5) Making it part of the conpane ensures that the data is sent for to the slave VI and the slave VI only. Putting it in any global storage (be it the Global VI or the tag, which is readable by anyone who opens a VI Server ref to the slave VI) is an invitation to hacks. If you come to rely on these tactics generally, you will eventually find yourself unable to resist the temptation to have someone else shim in between the master and the slave for some reason, perhaps to do some pre-processing before the slave runs, and eventually you end up with a mess of a spaghetti code system. I've seen it happen many times. QUOTE(mike_nrao @ Sep 19 2007, 09:37 AM) Here's the mystery: Where in memory is the tag data stored? Memory usage for LabVIEW.exe in the Windows Task Manager shows increasing memory usage BUT the VI profiler doesn't show it piling up in any particular VI memory space. That's because the data isn't in any VI's data space. It's off in a side "tags table" and only gets made part of the VI during save. And, you're correct, the intent of tags was to store data about the VI, never to serve as a communications medium. But, as I said above, if you provide a global store, eventually someone will abuse it as a hack because they see it as a convenient place to shovel data, rather than taking the time to actually put the data in the function interface. It is always easier to hack than to architect.

QUOTE(David Boyd @ Mar 31 2004, 12:06 PM) It would be possible. File this with the http://digital.ni.com/applications/psc.nsf/default?openform' target="_blank">Product Suggestion Center.

The occurrences are *really* low level tools. The queues and notifiers are implemented using them. But the ability to do "wait on multiple" requires much more coordinated information than the occurrences have. You mentioned that you use notifiers a lot, but not when you just need to signal because the notifiers transmit data and you don't have any data to transmit. In that case, consider just using notifiers of LVBoolean. The notifier will only allocate a single byte for its data, and you'll have the rest of the management structure for complexity of "wait on multiple".

QUOTE(jdunham @ Sep 17 2007, 01:19 PM) Nope. No plans for protected data. In LV8.2, we introduced private data. One of the major time sinks was creating get/set accessor VIs to the data. In LV8.5, we introduced the tools to accelerate this process. In much the same way, I want to see us add tools to support protected access to data. Note, I said "protected access to data", not "protected data." Such tools would allow you to create a set of VIs on the outer class whose block diagram is simply "unbundle element and call the element's member VI". These generated wrappers could be public or protected. A user might use the tool to wrap a contained element's interface and then might choose to delete some of the created VIs so that not all operations are exported, resulting in a very precise set of available operations for callers. Creating a language where you must go through functions to access data, and the only direct access to data is in a limited, known set of functions, is a very high priority for code correctness in a massively parallel programming language (aka LabVIEW). The integrated development environment for such a language (aka LabVIEW's editor) needs to support shortcuts for users to create the accessor functions. But time is far better spent on such tools than on cutting holes in the language syntax that result in ambiguous code execution. I realize that the vast majority of programs are a single developer who isn't worried about someone else on the team corrupting the data. But even in the single developer case, LabVIEW, as a test and measurement language, ought to be able to *certify* the correctness of code. The ability to identify all access points to a piece of data is critical in that code correctness. You can just provide get/set access to the data if you want -- get a contained object, call some methods on it, then set it back into the owning object. Those get/set VIs can be made protected scope. And, if you really want public or protected data with all its insides splayed out for the vultures of the world to dig into, use a cluster. A quick "get/set" accessor for the entire cluster will make it so that you can do arbitrary work on the data.

QUOTE(jpdrolet @ Sep 18 2007, 08:27 AM) That's a type difference. To me it follows the same rule -- the data would behave different on the diagram at least insofar as you would get a coercion dot between data of the same typedef and data of different typedefs of the same type. The characterization of the rule is, by the way, just my own statement of it. I don't own that code. This is just what I've derived from practice and reading between the lines of the documentation. The docs talk about the things that Variants are supposed to be able to do (sortable, for example) and that necessitates certain aspects of comparison. Simple comparison is only going to tell you that two variants are different. If you want to know *how* they are different, use the Variant type analysis VIs in vi.lib: vi.lib\Utility\VariantDataType\

QUOTE(jpdrolet @ Sep 17 2007, 02:22 PM) The rule is consistent: Variant equality tests "does the data inside this variant have the same behavior as the data inside this other variant." On a case-insensitive platform, c:\ABC and c:\abc behave the same. So the two variants compare as equal. On all the platforms, NaN behaves the same as NaN, so two variants containing NaN compare as equal. This is not the same as comparing the contents of the two variants (otherwise you'd get NaN != NaN) nor as comparing the flat form of the data (where you'd get that flattened c:\ABC is not equal to flattened c:\abc).

QUOTE In LV8.5 the unwired constant won't be in your final compiled code. I don't know when this behavior was added to LV.

QUOTE(Jim Kring @ Sep 14 2007, 12:06 AM) You made a good point, so I talked so some of the other owners of type propagation. There's still discussion going on, but I've filed the CAR (49F8C1J1). We'll see what comes of it.

QUOTE(cmay @ Sep 13 2007, 07:13 PM) Yeah.... I should've put a typedef'd enum into the cluster -- same trick that the GOOP Toolkit uses to create a guaranteed unique datatype. But I figured this was pretty close to sufficient, and I didn't take the time. Just pretend that I typedef'd the cluster itself -- that'll keep the variant comparison from claiming the two values are equal unless someone is deliberately trying to break the VI by using the VI's own typedef. ;-)

Try bundling a double and an int32. Then try to convert that cluster into an array. You'll find that you get a broken wire, not an array of doubles. The cluster-to-array node requires identical types. Otherwise we'd have an ambiguous coercion dot -- a coercion dot that affects one or more data values within the cluster, but gives no indication about which ones. LV tries to avoid this. I don't see this as a bug. You need to either a) Upcast the two nodes before you bundle them in or b) Specify a cluster type when you bundle the two nodes together that is a cluster of the common parent type.

QUOTE(Jim Kring @ Sep 13 2007, 10:24 AM) Or you've started using string constants on the diagram for documentation.