Aristos Queue

*sigh* I wish we had heard about this during the beta program... the only feedback during the beta program was that this was a great feature and a major improvement to the usability of probes. We discussed a popup option on wires "Create Probe Inside Watch Window" and "Create Probe Outside Watch Window", and we decided that was loading up the popup menus too much. We talked about the multiple-select to pop probes out of the watch window, but the feature wasn't implemented because there didn't seem to be any desire for it from our users, so the developer spent time on other aspects.

In his opening post, PJM_LabVIEW says he wants to see multiple probes at the same time. The text view in the Probe Watch Window does show you the value of the probe, and for all the use cases that we heard about, this was not only acceptable for that use case, it was preferred because it meant that all the probe values were lined up in a column where it was easy to monitor which value didn't match the other values in the list, instead of having probes scattered all over the screen.

If the text portion of the default probe does not show you the information that you are most interested in, one workaround is to create a custom probe. There's a new output from custom probes, a string, that is the string that will be displayed in the text portion of the probe watch window.

To the best of my knowledge, there is no undocumented config token to change the behavior of the probe watch window.

1. What happens if the class can't find the xcontrol? Is the class broken? Or, since the xcontrol is essentially a window into the class data, does the fp representation default to the cube? If that's the case, considering that the xcontrol isn't a class member, doesn't it violate the classes private data?

Mark Yedinak answered this part succintly in his post above regarding friendship and community scope. The class would not be broken if the XControl was missing. This is an editor only feature and we wouldn't want it to affect the run-time behavior of the class itself. This is merely an annotation on the class that says "when the user is creating a control/indicator of this class, if that ctrl/indicator is not on a member VI of this class nor of any subVI used by the class then the new control/indicator should be of this particular XControl instead of the cube."

2. Is the intended use case for the class designer to implement and deploy xcontrols with the class or to leave that to the class users?

The intended use case is for this to be something that the designer of the class creates. Thus if I create the Timestamp.lvclass, I could go ahead and create Timestamp.xctl which implements the calendar FP control. That way when users of my class are working, they don't see a class, they see a native LV data type with all the bells and whistles that everyone expects from a LV built-in data type.

Users of the class can already create an XControl for any given class that they want. What's missing is the hook into the LV editor for that XControl to be the default display for the class whenever LV needs to automatically create a display for the data. Currently LV uses the cube whenever it automatically creates one.

I'm skeptical of the above description, though. I like that on a subVI the class control and indicator are cubes or boxes. This is one advantage over using large clusters. (Something like visual encapsulation, maybe?)

Of course it would be good to have a way to display the contents of an object easily on a UI, and I can see how XControls are well-suited for this task. I just want to ensure I can still use the box control or indicator on the front panel (or the block diagram as a constant).

I'm sure we would encode some way to explicitly drop the cube, but the use case this is intended to handle is one where such an option would rarely/never be desirable. Suppose I use "Create SubVI From Selection" to create a subVI with a timestamp input. Would you want an opaque cube to show up instead of the calendar display? Almost certainly not. LV users are used to being able to see the values of their data on the FP in every subVI. Is there runtime overhead associated with this? Only if the FP is loaded. As long as the FP is not loaded into memory* then the XControl doesn't get updates and its code never runs, so it doesn't get in the way of fast subVI execution. You suggest that for hiding large clusters, this might be useful. A) For a class where you're not interested in seeing the private data, don't create any default XControl. :-) or B) You can always create a small XControl that only displays a small portion of the relevant data, or is perhaps growable/shrinkable to crunch down to small form.

* FP is not loaded as long as window not open, no open ctrl/vi refs, no use of local variables or statically bound property/invoke nodes.

This is a good question and if nothing else the user of the class should have the ability to override the X-Control with their own version.

I agree. It should be as easy as "Create new child class. Create XControl for child class. Set the XControl as the default for the child class. Change nothing else about the child class." It now has the exact same behavior as the parent but with a new display.

Is this related to how the new plots are implemented in 2009?

Are the FP Objects here, associated with a default class (or in this case an array of classes)?

Or is this totally different?

No, this is not related. The new plots all have LV built-in data types -- numerics, waveforms, arrays, etc. This is for creating displays for the class data types that users create. The new plots do use classes as part of their implementation, but their data type (the type of the FP terminal itself) is not a class type.

A couple more notes:

1. There probably needs to be an option for "should this XControl be used when probing this class or should the generic probe continue to be used"

2. See VI Properties dialog, Editor Options page. This page allows you to set which type of control to create on the FP when doing Create Control or Create Indicator. This feature would probably need to allow users to set different XControls for modern, classic and system displays.

The new icon editor in LV2009 is written entirely in G and the VIs are shipped without password protection. There are many amendments and additions that the community might want to add. NI would like to collect that feedback and fold any innovations into the next version of the icon editor. The author and maintainer of the icon editor has created a new community on NI.com specifically for the icon editor. Any feedback you have about the editor should be posted there.

http://decibel.ni.com/content/groups/enhanced-icon-editor-2009

The new icon editor in LV2009 is written entirely in G and the VIs are shipped without password protection. There are many amendments and additions that the community might want to add. NI would like to collect that feedback and fold any innovations into the next version of the icon editor. The author and maintainer of the icon editor has created a new community on NI.com specifically for the icon editor. Any feedback you have about the editor should be posted there.

http://decibel.ni.com/content/groups/enhanced-icon-editor-2009

All of what Yair said is true, and one additional point:

Within dataflow, LV's compiler knows that it can make certain optimizations. For example, if you do something inside a loop, LV can examine the operation and decide, "Hey! I only need to do this once... I'll just move that calculation outside the loop." But with a reference, that optimization cannot be done because the source of the data, the reference, *might* have been changed in some other diagram somewhere. So the data gets recalculated every time even though the result is actually going to be the same each time, but LV can't know that because the data is by reference. There are other compiler optimizations that LV can do for dataflow that it cannot do for references, and these will become substantially more common in the next two LV versions, and probably into the indefinite future.

The "Show Buffer Allocations" tool works for objects just as it does for any other LV data type. LV objects are a scalar data type, so enable the check box for "Scalar" and you'll be able to see where buffer allocations are created for your class wires.

Take a look at the Delegate pattern in the design patterns document. It's relevant to what you're asking.

I had the exact same thought. These functions have absolutely nothing to do with placing new nodes on the block diagram. But whatever. There they are. CTL+SPACE and then another CTL combo. RCF makes so much more sense in this matter.

Talk to Darren N. He's the one who felt these went with Quick Drop.

Has this been posted somewhere so that we can see what happened? This is an important tip because I'm sure some would understand DVR as meaning "unlimited by-ref" had come to LVOOP.

Unlimited by-ref has come. And that's the problem. :-) His program was not a case of LV having a bug, but rather he just coded something where Diagram Alpha was using a reference and Diagram Beta tried to acquire that reference, and was waiting, and, meanwhile, Alpha was waiting on Beta before Alpha would release the reference. And his program sat and waited on itself.

This is my attempt to depress, suppress and restrain the excitement running through the community regarding Data Value References in LabVIEW 2009.

Yes, they are cool.

Yes, they are powerful.

Yes, they solve problems real programming problems.

Yes, you should occasionally use them.

No, they are not a silver bullet.

But please, for the love of LabVIEW, don't go overboard. They are references. They are not dataflow. You can kill an app's performance by needlessly using references of any kind -- queues, file i/o, GOOP, and, yes, DVRs. Think before you use the references. Ask yourself if you need the references. Even if you think you do, try to not use them first. I have seen more than one user app where a knee-jerk reaction to wrap *everything* in a single-element queue and passing references around kills performance.

We have developed DVRs to be as parallel-safe as possible, but there are still hangs that can occur if you use them in some ways -- Jim Kring found one just last week, and thought he was looking at a bug in LabVIEW, but it wasn't. When you use references, you open up a whole new world of race conditions, recursive deadlock, and on and on.

Let the LabVIEW community celebrate the new Data Value References. But, please, celebrate calmly.

I don't understand the math entirely either, but I'm confident it is correct if only because two math nerds explained it to me twice. I actually understood it for a brief moment after the second explanation, but then I forgot.

If the VI didn't know about the library:

• Scope enforcement would not exist. A VI is broken unless its library is loaded... this is because LV assumes that if the library is missing, you're trying to access a VI that is marked as private by the library.
• Loading a VI needs to load its library so that it is *always* namespaced. Otherwise loading a large VI hierarchy would suddenly fail unless you loaded all the necessary libraries first because you would have a bunch of VIs with all the same file name colliding with each other.
• Classes, XControls and StateCharts -- all of which are libraries -- would not work.
• Licensing restrictions from NI would not work

That's it. ;-)

No need to wait anymore. Just watch the video and download the installer.

As far as OO is concerned, the video says "there are lots of OO enhancements in LV 2009, including targeting to real-time hardware." The list is WAY longer than that. I'll write something up for next week (when the release is official).

And another thing!!! My understanding (based on watching one of NI's videos) is that Requirements gateway looks for the same type of tag. But, finding one doesn't prove that the requirement is covered, it just brings you to the place where someone said it is. It still remains to be demonstrated that the purported requirement-covering code actually does what it's claiming to do, and that takes an auditor that understands the test language. No?

The NI Requirements Gateway interacts with the NI Unit Test Framework. It matches the tags in the code against the tags put on a given test against a given test requirement from the original spec document to show that a) the requirement was implemented in code b) there was a test written for that specific requirement and c) that test is passing.

Session ID:AD2650

Title:Tools and Techniques for Total System Configuration

You know what makes this NI Week so exciting? OO being used in so many places, I'm not even aware of all the presentations, demos, etc, that are using it!

Good thing I looked at this. I didn't realize the BBQ was at a different place than last year!

Should be a much better venue, IMHO.

1. ByRef Objects

Your dreams are too limited. Think broader...

2. Interfaces

Your dreams are too broad. Insufficient time has elapsed for such a grandiose feature to come into being.

3. Constructor/Destructors

Would you settle for one out of two?

That said, based on the timeless principle of induction accompanied by a heavy dose of wishful thinking, my prediction for LV2009 OOP new features is...

User defined namespaces -- or at least improved namespacing.

Some of you may be thinking, "But I thought .lvlib files are namespaces." Yeah, that's what I thought too. But after conversations with Daklu, I know that what he's asking for is the ability to have namespaces that can span multiple library files, something, perhaps, like X1.lvlib and X2.lvlib, etc, that, when loaded in memory, are all the X.lvlib namespace. Or something like that. This is in no way shape or form a hint of things to come -- off the top of my head I can think of several problems with that particular implementation -- but it's what Daklu is hoping for. His use cases are as a way of having a single module developed in several separate parts, without having a central file be the bottleneck for development, or so that a company could have a top-level namespace for all of its separate products.

Curiously enough, of the top three big improvements to OO, none of them make your list. But I think you'll like your presents none the less. ;-)

PS - Doesn't having Norm behind your back (where you can't keep an eye on him) worry you?

Don't tell Norm -- we're having bars installed on the door to his cube... ;-)

Check out the new NI Requirements Gateway. Your local NI sales rep should be able to demo it for you. It's a great tool for highly-regulated industries. I was shocked at the documentation level that some industries require and the hours and hours required to generate those docs, and I saw the Requirements Gateway reduce the time needed to generate AND TRACK those documents back to the source VIs from hours to minutes. Amazing tool, if you're in an industry that needs it.

It depends... Is your cluster also a type def? - if you edit the type def, you may lose the string array constant data. Even if it is not part of a type def, editing the cluster could result in your string data being lost. You may want to change the way you are initializing the data -- either loading it from a file or manually bundling in the data to prevent changes in your cluster from affecting the string array values.

LabVIEW class constants are immune to the data wipe that can occur when you edit a typedef. You might consider that approach (though I'll be the first to admit that the way you go about creating a class constant with your values set into it -- writing a VI that puts the values into an indicator and then converting that indicator to a constant -- is less than easy-to-use).

As the owner (NOT the original author) of vi.libutilityerror.llb, let me just say: "If you use any VI not exposed on the palettes that is included in this error.llb, you should be aware that in any complete overhaul of error.llb, it may be wiped out, refactored or renamed. In particular, GEH Core.vi was created so that I could have a subVI that I could adapt and change to suit the needs of strange callers, such as Automatic Error Handling, the project providers, the FPGA compile system, etc, and that VI may need a lot more inputs, which may result in it going to the ridiculous 6x6 conpane in the future. This is true of any VI in vi.lib that isn't in the palettes, but is especially true of error.llb that is, at this time, being strongly considered for a near term refactoring (no guarantees)."

But, hey, it's your code! ;-)

I want to see an NI marketing announcement where they do mention anything else but the advantages of their product over competitors (besides of a feature list and one or more enthusiastic user comments) !

Come to the "What's New In LabVIEW OOP" session at NI Week. Known issue CAR numbers right up front in the PPT. There was some conversation about the wisdom of that. What ultimately carried the day was the comment from someone on my team: "We're talking about what's new, and, honestly, that crash *is* new..."

In general I don't see the design pattern as a strict dogma and vary them as needed.

Completely correct. That's part of why the patterns aren't something that can be implemented once and reused by everyone who needs them. They vary in details for every implementation.