Aristos Queue

MikaelH, I already put this info in e-mail to you, but I didn't know it was also here on LAVA. For the rest -- this is a behavior common to all libraries, not specific to LV classes. The AppBuilder was built in a time when all VIs were expected to have a unique file name. So when it bundles libraries into the EXE, it has to rename any VIs that collide. For LVClasses, we put in a hack that saves the dynamic VIs outside of the EXE, since those VIs *must* have matching names. But for static VIs, they follow the same behavior as other VIs in any library. A workaround that might work is to make your static VIs dynamic, even though you're not expecting to override them. I don't remember if the hack for dynamic VIs is invoked simply by a VI being dynamic or if that gets invoked only when the VI is overridden. This behavior is going to require significant changes to AppBuilder to fix, and it is an area outside of my purview. It gets annoying since it impacts the Factory pattern for LVClasses, which calls for an identically named static VI on a series of classes. If you do find a good workaround, please post it here.

Check the sound VIs (search the palettes for "sound"). There's the traditional "volume" icon. The only other icon would be a sinewave getting larger.

C'mon, ladies and gentlemen. Surely someone has an opinion on this! There's no right/wrong answers here... this is a grand experiment. So even if you have only read about LVClasses, perhaps you can put forth some thoughts on how you might use classes for the instrument driver. This is an unexplored topic, and I was kind of hoping that we might see some wild ideas coming to the fore. One note, please don't polute this thread with conversations about "by reference." We've hashed that to death. But I'll guarantee that there are ways that LVClasses can improve the API of an instrument driver written in LV. Dan's question above is mostly about the instrument driver class itself -- representing the instrument. Some other uses of LV classes that I've contemplated are encapsulation of commands to the driver, packaging of data, and error handling. So let's hear some brainstorming!

Ye, gods, gentlemen!!! Close your Context Help window! That's the crash. I reflexively close the Context Help. So when I tried to replicate what you were seeing, I never could. The data type is recursive -- the class uses a VI reference that has the class on its own conpane. While this is perfectly acceptable from a data standpoint, when the CH tries to display the data type of the wire -- when you mouse over it -- it goes into infinite recursion and crashes.

These recompile bugs are known and will be fixed in the next bug-fix version.

It does not replicate inside NI. Another of the LabVOOP team did get it to crash while he was on remote working in California, but cannot get it to replicate now that he's here at NI in Austin. I downloaded a fresh copy of your VIs from LAVA. I tried wiping out my .ini file. I've tried reinstalling my LV8.2 just to make sure I'm clean. I've tried another machine. Nada. I tried Brian's original instructions and Jimi's variations. Nada. You guys are working in MSWindows right? This isn't a Linux or Mac bug that I'm hunting, right? So at the moment, the best I can say is that when our developer gets back to California, I'll have him investigate this bug. And if it really does replicate when he gets back out to Calif, then I may just hang up my tools and find a new profession. For what it's worth... This was reported to R&D (# 43JCLR2K) for further investigation.

"Technical Data Management Streaming". Introduced in LV8.2. It's a file format created by NI and useable with CVI, LV and Diadem specificially for handling data -- streaming, archiving, reviewing, manipulating -- and is designed for huge data sets. That's everything I know about it. Check the online help for LV8.2 for more information.

I cannot replicate this. I've tried everything. I've followed instructions verbatim, I've tried variations, I've tried loading without the project, etc. No crashes when I delete - wire - delete - rewire.

After the producer loop, drop a Release Queue primitive. When that prim executes, it will invalidate the refnum. Any waiting Dequeue in the consumer loop will stop waiting and return an error. Have your consumer loop stop if an error is returned. Your second question is something I'm going to leave to others with more experience with determinism, but I suspect the Timed Loop is what you're looking for. Though, with a timing window of a full second, just putting a Wait Milliseconds wired with 1000 into your loop might do the trick.

I have no idea. What does the documentation say?

The "case structure" must have good wires in all of its frames. The "diagram disable" structure may have missing subVIs, broken wires, unwired required terminals and other broken bits in the disabled frames. The "code disable" structure is for multi-platform loading. "I want this to be enabled on Platform XYZ, and that to be enabled on Platform PDQ". This handles cases where you used to have a constant wired to the case structure for "Mac" that, when you loaded on a PC, you had to remember to go find all the instances of that constant and change them to "PC". It's also able to handle other configuration changes using the keywords that you define as part of the project environment. ("I'd like to build a debug version of my VIs, which has all this slow sanity checking code, and now, with just a change to the project, I'd like a release version which leaves out all the double-checking.")

I would include the teammate sitting at the next desk. Remember that a lot of OO stuff is about enabling team programming as much as it is about creating encapsulated distributable libraries. And it isn't so much about them not understanding. It's a case of remembering to do so. The goal is to cut down on the memory load of the other developers. That would also work, but honestly the language ought to handle this. It's a problem to consider in the long run.

Suppose I drop a block diagram constant of Car. That Car will have whatever the default values is, since no method has ever modified it. If I wire it to "Get Speed." Jimi would like the value of zero to come out. If I drop a block diagram constant of Ferrari, it will also have default values for all of its private data, including the default value of zero for speed, and if I wire it to "Get Speed", I will get the value of zero. But Jimi wants a way such that a virgin instance of Ferrari will give a value of 200 when passed to Get Speed. We could require that any time you drop a BDConst of Ferrari, you must wire it to an initialization method that sets 200 into the speed field. But that puts the burden on the user of the class to remember to initialize. That's problematic. Ideally the language would have support for letting a child class set the initial values for its parent fields. I know a way to make LV robust in this manner, but it is non trivial to implement correctly, and there are other higher priorities. So as a workaround, I'm suggesting that we add a boolean, "Virgin speed?" that defaults to TRUE. Then when Get Speed is called, it can output 200 for Ferrari if and only if that boolean is set. If the boolean is not set, then output whatever the current value for speed happens to be. The work around makes it so that virgin instances of child classes behave as if they have different default values than the parent class. A slight simplification would be to have the default value of speed be something special, say NAN (not a number). "Get Speed" would detect NAN and output the correct constant value for the class if NAN was detected, and otherwise output whatever value had been set into speed. This eliminates the need for a separate boolean field. If you have many fields that need to differentiate, then this would be a better way than having a different boolean for each field. The problem with just letting the child class fill in values for its parent fields to be used in all default instances is that those values might not be legal values, as defined by the parent's API. We're going to have to work into LV a way to initialize those fields through calling a VI that can call parent API functions, instead of just setting the fields directly. That's a more challenging integration into the language, especially since, as Jimi points out, such initializations would want to be able to be constant folded. Doable, but not immediately.

There's a weird piece of LV functionality that might help with this. Drop an subVI onto any block diagram, then popup on it and choose "Enable Database Access". This puts a funky yellow halo around the subVI with extra terminals. This lets you do FP querrying for historical values of the FP of the chosen subVI. Details are here: http://zone.ni.com/reference/en-XX/help/lv...Logged_FP_Data/ This is a feature that doesn't get used often, but I've always thought it was an interesting idea. It seems like there ought to be more you could do with this "halo" concept, but it's never really been expanded on, and most LV developers think its kinda lame. Still, it might be interesting for you in this case.

No. Acutal LV source code is in <labview>\resource\... Just look for any file with a .vi file extension. ;-)

Merely because I have a sense of humor doesn't mean you're safe. I might be the kind of sick bastard who thinks if (wireType == kInt) return (0==StrCmp(username, "crelf")) ? kOrange : kBlue; else if (wireType == kDouble) return (0==StrCmp(username, "crelf")) ? kBlue : kOrange; is hysterical... :ninja:

I have this horrible vision of high pitched noises leading to bug reports about "I was debugging my diagram and I kept getting attacked by my dog when the Divide primitive had a zero wired to the bottom. I have attached the VI in question and my dog." I think my response would have to be "LTTFM" -- "Listen To The Freaking Manual."

Actually... EXCELLENT job. You've got the right general direction. There were changes to your inheritance hierarchy that I made -- not fine grain enough. Keep each class focused on a particular aspect of the system. Detailed comments are included in the refactored project (see attachment) both in comments on the VIs and the HTML file that I've added to the Project tree. Download File:post-5877-1163786011.zip

Sure. Tools>>Advanced>>Edit Palette Set... Oh, you mean permanently, as in, move it in the next version of LV? Probably not. We don't like to move the palettes around. It makes existing users cranky. We only do it when we have a good reason. And, like an oncoming train, I can hear the question coming, "So what was NI's good reason for moving it in the first place [or any of the rest of the palette reorg]?" Today, I'm tired. I don't feel like trying to explain the reorg, its reasons or its final benefits. So I'll leave this question hanging and let you contemplate hypotheses. FYI, the hypothesis that "NI likes causing users pain" is probably wrong. A lot of VI developers who've been using LV since LV N where N is a very small number helped with this reorg, so it can't be all caprice. Unfair. This one I do feel like defending. Hit Search button first time in LV8.2 right after launch on fresh reboot of LV: 13 seconds while full palette set parses. Exit LV and restart LV8.2, and immediately hit Search button: 1 second (files are in OS cache) Successive hits of Search button without restarting LV: instantaneous If you launch LV and don't use the search in your first couple minutes of programming, the palettes quietly load in the background, in the spaces between mouse clicks, and you'll get pretty close to instantaneous time on first use. Similar times for LV8.0, though the background loading isn't as smooth. The only way you'll get a spare "half hour" is if you keep your palettes and vi.lib on a remote network drive somewhere off-continent.

That doesn't provide the initialization guarantee that Jimi is hoping for -- a scoundrel programmer on your team could still drop the class directly instead of dropping the initializing VI. Jimi: I did think of one workaround. Parent has member data "speed" which is a double. Parent also has member data "default speed" which is a boolean. Parent has a protected dynamic member VI "GetDefaultSpeed" which returns a double. Parent has a public static member VI "SetSpeed" which sets the value of "speed" AND clears the "default speed" boolean. Parent has a public dynamic member VI "GetSpeed" which checks the boolean. If the bool is true, it calls GetDefaultSpeed, which dynamically dispatches out to children. If the bool is false, it returns the current value of "speed" Each child then overrides GetDefaultSpeed with their desired value. I know -- a lot of overhead for the programmer. I have a solution in mind, but it's going to be a while (almost certainly not the next release) before I can get to this.

This was reported to R&D (# 43EEI1J1) for further investigation.

No method exists. This is noted in the design documents white paper as a limitation that needs to be addressed in future versions.

Within NI, I have to use rings instead of enums because rings can be localized into various languages without recompiling the diagrams (the data types don't change).

You're welcome. I do want to stress that the runtime functionality of LVClasses seems to be clean, and the problems only arise while developing. In a 1.0 release, I'd be uncomfortable with LabVOOP running the control rods at the nuclear power plant, but perfectly happy if it was controlling the lawn sprinkler systems. After the bug fix release, then I'd be ok if you go create "Nuclear Power Plant.lvclass". And, before anyone else asks, no I can't supply a date for the bug fix release.

Jimi: I have appreciated your adoption of LabVIEW Object-Oriented Programming (LabVOOP). Both your bug feedback and your feature feedback have been valuable. LV8.2 includes the first release of LabVOOP, and, yes, LV classes do tend to make projects unstable. This is due to, by my count, seven significant bugs that have been found since the release that will be patched in the next bug fix release. FYI, three of those bugs have been found through your testing. I can offer you a workaround for the majority of the problems. To begin with, make sure all VIs for your application are in memory when editing the class' private data control, and always do Save All after editing the PDC. This is not necessary for most edits to the PDC, but it prevents corruptions from developing in some edge cases. If you do begin experiencing problems where the VIs become corrupt (and crash as soon as you hit the run button), then load your project and open the top-level VI and then hit ctrl+shift+run arrow on the top-level VI. This forces a recompile of every VI in memory. That rebuilds various tables from scratch completely. On a large project of 585 VIs being developed inside NI, this process takes about a full minute. After it completes, save *everything.* The runtime system of LabVOOP appears to be stable. It's the editor environment where bugs are appearing. Within NI, I am aware of three major projects that are using LabVIEW classes (there are likely others, but these are the ones I've watched closely to get a feel for problems developers are finding). These have been able to replicate the large-project bugs to which you refer. My team has been tackling them as fast as possible. These three have hit problems, yes, but development has proceeded and seem likely to be successful. You said you were moving away from LabVIEW for development. LabVIEW 8.2 is very stable, as measured against various prior LabVIEW releases. The next bug fix release should bring the LabVOOP components up to the quality of the rest of LabVIEW. I would be very sorry to lose you as a developer. I understand your frustrations, but I ask your indulgence. It took C++ multiple years to get compiler stabilization, and I think we're well ahead of that standard. The power of classes to the end programmer comes because the language tracks so much information on the programmer's behalf, and getting that tracking right is tricky. The core of LabVIEW is stable. LabVOOP is not core. It is a recent extension that is being stabilized. I understand if in the short term you move away from LabVOOP. But moving away from LabVIEW as a whole would be overkill, in my opinion. You have a house with a good foundation. I'm sorry the toilet in the new bathroom keeps backing up; we'll have it fixed in short order, but in the meantime, you can live in the rest of the house, which has stood for 20 years. You don't have to move out. Our commune would miss you. And I can guarantee your new place would have poorer wiring. -- Stephen R. Mercer -= LabVIEW R&D =- Lead developer for LabVOOP team