Aristos Queue

Another option: Stop using OpenG namespaces and instead put the whole kit and kaboodle into a LV Library to provide namespacing. If you do that, your paths aren't changed at all. You can still use OpenG to namespace that top level library if you so desire, but all the stuff inside that library retains its original path and filename.

QUOTE (neBulus @ Feb 4 2009, 10:49 AM) The minimum is slightly above 4000 queues, although you probably won't see anything that soon because the refnum is made up of three components, one that is a cycling number and one that is based on something like the tick count and one that is random. Probability is in your favor until you get up around 10000 refnums of the same kind (meaning that if you create 5000 queues and 5000 notifiers, you're probably still safe on both).

This has been confirmed as CAR 136680. Summary: "Queue/Notifier references can become unexpectedly invalid when using "Force Destroy" option for long-running VIs" Details: A bug has been discovered with the queue and notifier refnums that affects all versions of LabVIEW from 6.1.0 through 8.6.1. It can only occur when you have multiple top-level VIs that are all using queues or notifiers AND you occasionally use the "force destroy?" option when releasing refnums AND your VIs run for an extremely long time without stopping. If you are seeing queue or notifier refnums becoming invalid unexpectedly, this bug may apply to you. When you use Obtain Queue or Obtain Notifier, LabVIEW records that refnum so that if the VI that allocated it goes idle (stops running), the refnum will be automatically released. If you call Release Queue or Release Notifier explicitly, then the refnum is released and is removed from the list of refnums that need to be automatically cleaned up. However, when calling Release Queue or Release Notifier with the "force destroy?" option set to TRUE, all refnums that refer to that same named queue are invalidated, but only the refnum that is explicitly passed to the Release function is removed from the automatic clean up list. The result of this is that all the refnums are now available for LabVIEW to reuse for future calls to Obtain and Release Queue that are used by other VIs. The result is that a first top-level VI can obtain multiple references to the same named item, then "force destroy?" those references. A second top-level VI could now obtain a refnum to a different item. When the first top-level VI goes idle, it will automatically destroy the refnums that were incorrectly left on its list. This results in the refnums, which are still in use by the other top-level VI, returning errors when they are used for operations. Because released refnums are reused only when LV wraps around on the refnum count, the first top-level VI must be running for a significant amount of time before this bug can occur. It has taken as long as three days to manifest in some of the applications that were experiencing problems with this bug. Workaround: Avoid using "force destroy" to destroy all the refnums for a given item (queue or notifier). One solution to this is to use the NamedRefnumManager.vi in the attached VI file. Unzip the attachment and take a look at "DemoWorkaround.vi" for more information. Download File:post-5877-1233763916.zip Status: This bug was not isolated in time to be included in the 8.6.1 bug fix release. It will be fixed in the next release of LabVIEW.

QUOTE (Omar Mussa @ Feb 2 2009, 08:33 PM) Well, actually, you don't have to worry about that because of the known issue in LVClasses that my team still hasn't been able to fix that even when a VI is private in the parent the child class is broken if it has a VI of the same name. It was going to be fixed in LV 8.6, but in LV8.5 someone (not on the LVClass feature team) wrote some new features for another part of LV that depend upon that uniqueness of name and enshrined it. Darn software -- it grows when you're not looking.

QUOTE (Daklu @ Feb 2 2009, 06:16 PM) You can always hit the run button on any VI for short, quick checks of functionality. And if you just want to run a quick test, it should be just as easy to run the public VI that calls your private VI as it would be to run the private VI directly. When we start talking "test suites", I'm thinking nightly builds and automated testing on a regular basis. Those auto tests have no business, IMHO, running the private VIs because, as I said, a parameter sweep across them may result in false error reports or may put your object into an unexpected bad state that can never actually occur in real uses -- and I do mean *can* never occur not *should* never occur. That's the thing about privacy enforced by the compiler -- outsiders *cannot* call that VI with arbitrary values. Since this *cannot* happen, we don't have to worry about testing for it.

Up until recently, NI employees couldn't take the various LV certification exams because there just weren't enough graders and priority was given to customers. That's changed this year, and today I took the CLAD, along with a large faction of NI, including many of the LV R&D team. Yes, I did pass. I thought it was an ok exam, with a few wording problems I hope we can get cleared up for future test takers. I only had a serious problem on two of the questions, one of which was wording and the other was a case of me knowing too much about how LV works behind the scenes. CLD? Maybe. But a part of me wants to hold out for a CLD exam that includes LV classes. I mean, I'd kind of be undermining the prostelytyzing I've been doing the last few years if I actually admitted that someone could be a true LabVIEW developer without classes! On a tangent note: Q: What are you if you are naked while answering a 40-question multiple choice exam about LabVIEW? A: SkyCLAD! Q: What are you if you swim 1 mile, bike 20 miles, run 2 miles and then take a a 40-question multiple choice exam about LabVIEW? A: IronCLAD! Others are welcome to try their own puns, but I should warn you... the only other word in English that uses the letters "clad" together is "clade" and making jokes off of it won't be easy. You may have more success in other languages.

QUOTE (shoneill @ Feb 2 2009, 10:36 AM) True, but the NI Median implementation is not returning the data we are looking for -- namely the index of that median. If we put a new requirement on the NI implementation, I'm sure they'd have to change their calculations to find that value somehow. I was just commenting on benchmarking the "sort then search" method vs the "cluster then sort" method.QUOTE I still maintain however that the index of a median position is in upwards of 90% of the time a non-existent entity. Mathematics would be in a sorry state today if people gave up searching just because the entity was non-existent. Are you familiar with Stanislaw Lev's Cyberiad? One of my all-time favorite quotes, posted on my desk at work... Everyone knows that dragons don't exist. But while this simplistic formulation may satisfy the layman, it does not suffice for the scientific mind. The School of Higher Neantical Nillity is in fact wholly unconcerned with what does exist. Indeed, the banality of existence has been so amply demonstrated, there is no need for us to discuss it any further here. The brilliant Cerebron, attacking the problem analytically, discovered three distinct kinds of dragon: the mythical, the chimerical, and the purely hypothetical. They were all, one might say, nonexistent, but each nonexisted in an entirely different way...

Hmm... Jim... I think theory and practice are closer in this case. Try this on: You *shouldn't* test your private VIs. You should only test your public VIs. Why? Your private VIs are written to assume they are being called from within the class. Your private VIs may not be able to handle boundary conditions because the public API prevents those boundaries from ever being tested. Your private VIs may not have any error handling because their inputs are always sanitized by the public API. There may actually be logical errors in many many parts of your private VIs, but that's ok because there is absolutely no way for those ever to be invoked from the public API. Given all this, if you test your private VIs, you're going to become aware of defects that don't matter, and you'll waste development time fixing them. You may even cause slowdowns for your class by adding error checking and bounds checking code to the private parts of your class, replicating the work done by the public VIs. Or, to put it another way... Surgeon General's Warning: Testing your private parts directly may result in decreased performance, wasted development, and redundant material. Avoid testing your private parts in favor of having someone else test you through your public API. Now, this is *theory* only. What are the thoughts from the practical experimentalists? PS: Friend classes, should they ever come into being, won't do what you just said you expect them to do, ie, give free, uncontrolled access to the private parts of the class. An object doesn't mind if friends come inside the house, but following the object into the bathroom is going too far. That's one feature that I think is poorly implemented in C++ and JAVA, and if LV ever gets it on my watch, we're going to do something just a bit different...

QUOTE (jdunham @ Feb 1 2009, 10:54 PM) Bah. "Median" is the middle number of the set... and an array is an ordered set. So I'll contend that for an array, giving the middle value is technically valid. But I will concede that the subVI in question gives -- what I would call -- the median of the sorted permutation of the array, which does make the finding of the median more difficult. Having said that ... you recommended clustering the value with the index and then sorting... I wonder if that would really benchmark well compared with just calling Sort 1D Array, calculating the middle and then using Search 1D Array on the original array. Sorting an array can be done without any new array allocations, and the data movement is significantly less that moving around the value plus an additional 4 bytes of index. The Search 1D Array is linear, but a multi-core CPU might break that down pretty quick compared to the actual data movement incurred in the larger sort -- after all, if your data is type double then the double+int is larger than a single assembly "move" instruction. [Note that for any array less than a few milion elements this sort of performance discussion is probably pointless on a modern CPU, but I find the thought experiment interesting nonetheless.]

The median is just the middle number of the array. In the case where the array has an even number of elements, the median is the average of the two elements at the middle. But the *index* of the median is always (size of array / 2) rounded up. So all you need are the Array Size function, the Quotient&Remainder function and the Add -- all of which can be found by searching the palettes. Just get the size of the array, use quotient and remainder to divide by two and then add the resulting remainder to the quotient. (If the remainder was zero, then you had an even array and you have the lower index; if the remainder was 1 then you have the index of the middle element of the array).

QUOTE (syah85 @ Jan 31 2009, 08:06 PM) Most databases have types for the entries in their tables -- integer, string, key, char, etc. Generally there is one called "blob" which is used for storing binary data. Use google.com and enter "database blob" and you'll find a good chunk of info.

Post your best attempt so far and people are more likely to try to help you, but no one can help you from such a vague description. Upload your VIs. The community is far better able to answer specific questions than general ones.

QUOTE (Mark Yedinak @ Jan 30 2009, 04:42 PM) I have thought so too, but IANAM*.*I Am Not A Marketer

QUOTE (PaulG. @ Jan 30 2009, 09:35 AM) Try checking the VI Hierarchy window. If you reeeeeealllly want to hide code, you need to make the icon blank AND mark the VI as a system VI so it hides in the hierarchy window.

QUOTE (jdunham @ Jan 30 2009, 03:22 PM) Except that it hasn't been a problem for most of our history. Our bread and butter comes from the zero-experience-with-CS engineers and scientists. Those of you who are skilled programmers and use LabVIEW as a "fully armed and operational battle station" are a much smaller group, though you're growing. But because the bulk of users are in that first group, we do tend to spin LabVIEW for only that first usage. Heretofore it has paid the bills well and we've spread in more advanced contexts by word of mouth and the lone LV user who smuggles a copy of LV into his/her circle of C++-using co-workers. It certainly will be a problem in the future if the "large, full applications" group starts eclipsing the "one while loop around three Express VIs" group, but my understanding is we're still a ways away from that inflection point.

If anyone wants to chime in: http://tech.slashdot.org/article.pl?sid=09/01/30/1443203

QUOTE (crelf @ Jan 29 2009, 02:47 PM) That's because a control is not an instrument. A *control VI* is an instrument, and those you can save. To highlight the difference, let me point out that you could open a VI reference to a control VI and then get a control reference to the single control on that VI's front panel. A control reference is always to a part of a VI, which is not a file in and of itself. QUOTE (crelf @ Jan 29 2009, 04:44 PM) Once again, all the folks on LAVA prove their worth (and thanks also to those who came to my rescue through twitter!) It was the unnamed method that I was looking for: You could also use methods for Copy Selection / Paste Selection to copy the control from one VI to another blank VI and then save that blank VI.

I suspect that if LV made you enter your password for every individual VI while you're developing -- say, when you double click on a subVI to open it, and then when you tried to open the next subVI, and the next -- someone would come to NI and shoot whoever made that change. It is DEFINITELY NOT A BUG.

QUOTE (Ton @ Jan 27 2009, 11:14 PM) None of the private events fire for this. Events in LV are only for things within LV. To the best of my knowledge, none has ever been added for items outside of LV... and, believe it or not, window position is not "inside LV". It is a purely OS event that LV doesn't have to react to for any reason, so it isn't one for which LV itself registers, thus it isn't available to pass along to users.

I believe there is a MS Windows system call that you can make to tell the OS to lock two windows together. My memory says that I've heard another LV programmer use such a technique, but I know nothing more than that. If you're on non-MSWin systems, you might see if that OS has such a function.

QUOTE (jfazekas @ Jan 26 2009, 01:24 PM) Shouldn't have any effect -- if the array needed to be copied then the class will need to be copied. Basically, if you're doing something that requires a copy, then a copy is going to be made. Whatever it is, stop doing it. :-) Some things that would cause a copy:* Using any sort of Global VI to store your data * a functional global where you use get and set actions to copy the value out of the global and then back into it later * forking the array wire to two write operations (such as Replace Element or Sort 1D Array etc). As long as you never fork the wire or fork to all readers or to a single writer and the other branches are all pure-functional readers, then you shouldn't have any data copies. What are you doing in those analysis functions? Are they "destructive analysis"? In other words, do they do stuff that replaces values in the array, which would cause a copy to be made so that you can call the next analysis function?

By the way... could someone else check my work? I don't want to mislead anyone who reads that, and I just typed it from memory without actually working through the steps.

You say you're having trouble coming up with the inheritance hierarchy... here's an easy way that might not be optimal but would get you started: Pretend you're writing the enum-wired-to-Case-Structure that you talked about initially, with one of your DUT VIs in each frame. We're going to use that as a starting point for the class hierarchy... Create or open a project. On "My Computer", pop up and select "New >> Class" and name the class "ParentDUT.lvclass". This creates the class and its private data control. Ignore the private data control -- we're going to leave it empty. Pop up on ParentDUT.lvclass and select "New >> VI From Dynamic Dispatch Template". Edit this VI so that it has the connector pane of your DUT VIs, but leave that "class in" control alone -- it is going to be the placeholder for the typedefs that you were talking about in your original post. Leave the block diagram untouched. Save this VI as "DUT.vi" Now, for each frame of that case structure that you were building, create a new class and name that new class one element of the enum. So if the enum has strings "DUTA" "DUTB" and "DUTC", you're going to end up with three classes named "DUTA.lvclass", "DUTB.lvclass" and "DUTC.lvclass". Save the class -- save every one of these classes to a separate subdirectory. Common practice is to name the directory the same as the class without the .lvclass file extension. Pop up on the "Whatever.lvclass" and select Properties Go to the Inheritance entry. Click on the "Change Inheritance" button. Change the inheritance so that "ParentDUT.vi" is its parent. Hit OK to close the Properties dialog. Double click on the private data control for "Whatever.lvclass". You'll get a control VI with an empty cluster on it. Fill that cluster in with all the stuff you would've put in the typedef. When done, save and close the control VI. Pop up on "Whatever.lvclass" and select "New >> VI for Override..." When the dialog appears, select DUT.vi. A new VI is created. Fill this VI in with whatever functionality you want for this type. You can unbundle that class wire to get at all the data that you packed into the private data control. Save the new VI -- LabVIEW will start you off in a directory and assume a VI file name. Just accept both the default name and location --- that will put each DUT.vi next to the class that owns it. When finished, do File>>Save All. Alright... there's your inheritance hierarchy. Now we need to invoke it... Create a new "Run my tests.vi". In all the following, when I say "the VI", I'm talking about that one. In the example code that you posted, you used the DUT enum to pick out a VI to load from your support\boards directory. We're going to do the same idea but altered just a bit. Given the value of an enum, build up a path to the class -- remember that each one is in a directory that is the enum string and is a file that is the enum string plus the file extension. On your diagram, drop the "Get LVClass Default Value.vi", found in the same palette as the bundle and unbundle nodes. Wire the path up to the input. Drag from your project to the block diagram the "ParentDUT.lvclass". You now have a block diagram constant of the parent class. Drop a "To More Specific" primitive on the block diagram (also in the same palette as bundle/unbundle). Wire the constant to the middle terminal of "To More Specific". Wire the output of "Get LVClass Default Value.vi" to the left input of "To More Specific". Drop DUT.vi as a subVI (just drag any of the DUT.vis from the project tree to the block diagram -- it doesn't matter which one you drag). Wire the output of the To More Specific prim to the input of the DUT.vi. Wire up any other inputs to the subVI that you want. Run your VI. There you go. Dynamic dispatch magic over a VI hierarchy, generated, almost by rote recipie, from an enum and a set of typedefs. Good luck!

QUOTE (Tomi Maila @ Jan 26 2009, 03:10 AM) Nope.

What is the annoying message? Can you tell? That might help identify something to be done about it.