Why upgrade?

[zoogies]

I guess this might be a pretty standard question. One thing is I'll need IMAQ for 1394 features; is it better to go out and get a version of NI-IMAQ for 1394 compatible with Labview 7.1, or upgrade totally with IMAQdx and Labview 8.2? I don't think LV8.2 is *necessary* per se, so I'm leaning towards sticking with 7.1 (besides, don't particularly want to deal with porting issues right now). But I just wanted to gather you guys' insight; maybe there's some awe-inspiring new feature in LV8.2 that should jump out at me? (I don't think Mathscript counts)

Although, I'm having a bit of trouble finding a NI page for "NI-IMAQ for 1394"...hm...I came up with this but can't tell if it's right. I could've sworn I had found such a page earlier...oh well.

[LVfan]

Project Explorer!

[Neville D]

QUOTE(zoogies @ Jun 25 2007, 02:05 PM)

I guess this might be a pretty standard question. One thing is I'll need IMAQ for 1394 features; is it better to go out and get a version of NI-IMAQ for 1394 compatible with Labview 7.1, or upgrade totally with IMAQdx and Labview 8.2? I don't think LV8.2 is *necessary* per se, so I'm leaning towards sticking with 7.1 (besides, don't particularly want to deal with porting issues right now). But I just wanted to gather you guys' insight; maybe there's some awe-inspiring new feature in LV8.2 that should jump out at me? (I don't think Mathscript counts)

Although, I'm having a bit of trouble finding a NI page for "NI-IMAQ for 1394"...hm...I came up with http://sine.ni.com/nips/cds/view/p/lang/en/nid/12892' target="_blank">this but can't tell if it's right. I could've sworn I had found such a page earlier...oh well.

Why don't you talk to your local NI rep? He can guide you through the upgrade type questions. I think you can't get the old-style IMAQ for 1394. You have to buy the latest IMAQdx. But it comes with the last frozen version of the old driver as well. It should work with LV7, as before, but there won't be any new features/functions in the old driver (depending on what version of the old driver you have).

Also, the newer versions of IMAQ support Gig-E cameras which are becoming more popular than FireWire cameras.

As for latest features, check out the whats new for LV 8.2.1 to get all the upgrades & features. You might even look at bundling the IMAQ/Vision with LV under the SSP, that significantly reduces your upgrade costs in future. Talk to your rep.

LV 8.2.1 with Vision 8.2.2 and the latest IMAQ is fast and fairly stable (I haven't used any of the OOP stuff which might be a bit more delicate) apart from the slowwww startup time of LV 8.2.1.

LV 7.1.1 was pretty stable too.

Neville.

[Aristos Queue]

QUOTE(zoogies @ Jun 25 2007, 04:05 PM)

But I just wanted to gather you guys' insight; maybe there's some awe-inspiring new feature in LV8.2 that should jump out at me?

I didn't spend six years developing LabVIEW classes so that you guys could stay at LV7.1.

Yes, LV classes should jump out at you as awe inspiring. Unfortunately, it's hard to sell them as awe inspiring (an ongoing problem I'm working on).

If you're doing any substantial desktop development (classes don't yet go to the various target platforms) then classes:

1) ... help write more organized VIs

2) ... help make VIs that are easier to debug

3) ... help write VIs that are easer to extend with new features

4) ... help write VIs that are easier to hand off to the next developer

5) ... help write VIs that are easier to reuse

The folks who've heard my sales pitch in person know that I mean every one of those claims. Not everyone believes me, but the number of converts is growing.

Stability? Yes, there were seven ugly bugs in LV8.2 that are fixed with the 8.2.1 patch. There are still some glitches in LV8.2.1, but it just keeps getting better. I can't promise that LabVIEW classes are the way of the future for LabVIEW development, but they will be if I can convince enough people to try them and to realize the power and potential.

[Omar Mussa]

QUOTE(Aristos Queue @ Aug 2 2007, 05:04 PM)

The folks who've heard my sales pitch in person know that I mean every one of those claims. Not everyone believes me, but the number of converts is growing.

I use classes. I think they are useful and powerful, however in my opinion it is not just 'stability' issues that are preventing users from adopting LV classes. I think it is still difficult to actually 'use' classes from a development/developer standpoint.

Here are 5 usability issues I've found that bug me a lot (in no particular order):

1) If you right click on a class wire and select insert, the context menu you see shows '[class name] Pallete' (grayed out) and 'All VIs ...' --

I expect to see the cluster pallette so I can insert a bundle or unbundle by name (assuming I'm in a class method). If I navigate to the bundle/unbundle by name function, LabVIEW miswires the inputs and I have to manually reconnect them. This is really a bad behavior from a class developer perspective.

2) Class inheritance data is not exposed properly to child classes -- there is no protected data. I want to unbundle protected class data -- I should be able to unbundle/bundle (i.e. access) protected properties of a parent class from a child class.

3) You can't 'find' dynamic dispatched VIs using a standard LabVIEW search. This means you also can't 'Find All Instances' of your dynamic dispatch VIs. This makes debugging applications a real pain and means you have to be very selective of which VIs you want to make dynamically dispatched.

4) (This issue was raised earlier by Jim Kring but I reiterate its usability issue for me) -- you can't drag a class onto a Filepath control. This annoys me a lot -- I really hate having to do this from Windows Explorer.

5) The object primatives are not easy to find... there should be a LVOOP pallette. Its really annoying to have to navigate to the 'App Control' pallette to access functions like 'To More Specific Class' and even worse 'Call Parent Method' -- LabVIEW treats objects as second class citizens -- which then translates to the development community treating them as such as well.

These issues seem painfully obvious to me as someone who uses LabVIEW a lot. I think as these issues are handled better, adoption will increase. I look forward to the next round of fixes.

[Jim Kring]

One LVClass usability feature that I'd really like is to see (in addition to the ones you mentioned) is...

When I right-click on a class method (or class wire) and choose Replace>> (or Insert>>), I'd like to see a list of the member VIs that I am allowed access to call (for example: private, protected, and or public) from the VI whose diagram I am working on.

[Val Brown]

I understand that THEORETICALLY classes SHOULD really simplify things, make the coding process easier, maintenance better, etc, etc, etc; however, practically I don't yet see those benefits.

Now I'm an old dog in a lot of respects -- I know how to make a lot of things just work for my use of LV. I am open to new tricks and even new paradigms -- and I hope to get a big sense of that during NI Week. So, I'm really looking forward to seeing what's available to help me "see the light".

[jaegen]

QUOTE(Omar Mussa @ Aug 2 2007, 06:01 PM)

...

Here are 5 usability issues I've found that bug me a lot (in no particular order):

...

I have to wholeheartedly agree with all 5 of these issues. I've just really started investigating classes, and I've actually been quite pleasantly surprised - they work better than I'd thought - but these little issues make the experience somewhat less than perfect.

Jaegen

[Aristos Queue]

QUOTE(Omar Mussa @ Aug 2 2007, 08:01 PM)

1) If you right click on a class wire and select insert, the context menu you see shows '[class name] Pallete' (grayed out) and 'All VIs ...' --

I expect to see the cluster pallette so I can insert a bundle or unbundle by name (assuming I'm in a class method). If I navigate to the bundle/unbundle by name function, LabVIEW miswires the inputs and I have to manually reconnect them. This is really a bad behavior from a class developer perspective.

We created classes to be able to generate new LV datatypes. One of those requirements is that the new datatype be able to look like a new type and not specifically a LabVIEW class. So the popup palette for a LV class is completely definable through its Properties page. We didn't add a default palette. This is a decision that has been both praised and damned and may be revisited in the future. One of the issues is "Should you show the App Control palette (with the To More Specific prim) or the Cluster palette (with the bundle/unbundle)?" We'll talk about this topic more when we get to your point #5.

QUOTE

2) Class inheritance data is not exposed properly to child classes -- there is no protected data. I want to unbundle protected class data -- I should be able to unbundle/bundle (i.e. access) protected properties of a parent class from a child class.

Sorry... this is correct behavior and is not subject to review. Create a protected accessor VI to give children access to parent data. All the arguments for why there is no public data apply to why there is no protected data. There are so many programming benefits to channeling access to data through accessors that any weakening of that wall is going to take a pretty compelling use case, which no one has yet proposed. We will be making it substantially easier to create such accessor VIs in upcoming LV versions.

QUOTE

3) You can't 'find' dynamic dispatched VIs using a standard LabVIEW search. This means you also can't 'Find All Instances' of your dynamic dispatch VIs. This makes debugging applications a real pain and means you have to be very selective of which VIs you want to make dynamically dispatched.

A definite weakness. Something that is on the "must be fixed soon" list.

QUOTE

4) (This issue was raised earlier by Jim Kring but I reiterate its usability issue for me) -- you can't drag a class onto a Filepath control. This annoys me a lot -- I really hate having to do this from Windows Explorer.

CAR'd for bug fixing.

QUOTE

5) The object primatives are not easy to find... there should be a LVOOP pallette. Its really annoying to have to navigate to the 'App Control' pallette to access functions like 'To More Specific Class' and even worse 'Call Parent Method' -- LabVIEW treats objects as second class citizens -- which then translates to the development community treating them as such as well.

Yes. There should. (*yells over shoulder* Hey, rest of LV R&D, you see, at least one user agrees with me!! ).

Let me highlight part of your quote again:

QUOTE

LabVIEW treats objects as second class citizens

I *sooooo* agree. :-) I have been told that to be a first class citizen, a feature has to have users first. There's a chicken/egg problem here, but I have been slowly assembling a chicken from spare parts. Continuing this odd analogy, perhaps I should start giving out certificates to early adopters. "Congratulations, you're part of the LabVOOP Chicken!"

QUOTE

These issues seem painfully obvious to me as someone who uses LabVIEW a lot. I think as these issues are handled better, adoption will increase. I look forward to the next round of fixes.

Congratulations, you've just identified some, but not nearly all, of the major usability issues with LV classes. I will now dance happily since none of these are *functionality* issues. Functionality for the 8.2 release. Usability comes next. There's only so many hours in the day to work classes into all of LV's nooks and crannies. :-)

[Omar Mussa]

Thanks AQ for the update. Am sure there will be a lot of LVOOP discussion this year at NI Week as (some) people have braved the waters and actually have implemented real LVOOP use cases now.

QUOTE(Aristos Queue @ Aug 3 2007, 12:47 PM)

A definite weakness. Something that is on the "must be fixed soon" list.

I just installed LV 8.5 evaluation and it looks like you can now 'find' dynamic dispatched VIs as expected now -- both from the traditional 'Find All Instances' and the new project 'Find Callers'.

:thumbup:

[Val Brown]

QUOTE(Omar Mussa @ Aug 3 2007, 01:06 PM)

Thanks AQ for the update. Am sure there will be a lot of LVOOP discussion this year at NI Week as (some) people have braved the waters and actually have implemented real LVOOP use cases now.

I just installed LV 8.5 evaluation and it looks like you can now 'find' dynamic dispatched VIs as expected now -- both from the traditional 'Find All Instances' and the new project 'Find Callers'.

:thumbup:

This is all good news and I for one am looking forward to being convinced about this idea. In that re: any specific suggestions about sessions/events to attend for this purpose?

[Aristos Queue]

QUOTE(Omar Mussa @ Aug 3 2007, 03:06 PM)

I just installed LV 8.5 evaluation and it looks like you can now 'find' dynamic dispatched VIs as expected now -- both from the traditional 'Find All Instances' and the new project 'Find Callers'.

Oh. Hey! Look at that! 8.5 is available.

(I never know when that's going to happen... R&D hands over the final CD to a figure in shadowy darkness who disappears into the night, and sometime after that everything goes live.)

In that case...

Perhaps you should check out the new "Cluster, Class & Variant" palette on the block diagram. ;-)

[eaolson]

QUOTE(Aristos Queue @ Aug 3 2007, 02:47 PM)

Sorry... this is correct behavior and is not subject to review. Create a protected accessor VI to give children access to parent data. All the arguments for why there is no public data apply to why there is no protected data. There are so many programming benefits to channeling access to data through accessors...

I'll admit my ignorance and confess I've never understood these benefits. If you're talking about get() and set() methods working on a private data member, I don't see any significant benefit of doing things that way compared to just using a public data member. You lose both data encapsulation and data protection.

I assume these benefits exist, I just don't understand what they are. Visual C++ went so far as to add the property keyword which sort of automates the creation of a data object along with its get and set accessors.

QUOTE

I *sooooo* agree. :-) I have been told that to be a first class citizen, a feature has to have users first. There's a chicken/egg problem here, but I have been slowly assembling a chicken from spare parts.

So you're creating a Frankenchicken?

[Omar Mussa]

QUOTE(Aristos Queue @ Aug 3 2007, 01:14 PM)

Perhaps you should check out the new "Cluster, Class & Variant" palette on the block diagram. ;-)

Aside from having a really long name, I like it!

The first thing I tried to do when I saw the palette was to open one of my existing class methods, right click on a class wire and select 'bundle by name' from this snazzy new context menu with a really long name... broken wire! Doh!

:headbang:

And then, it hit me, or rather I hit it ... on accident I right clicked a tad further to the left of a vertical class wire ... let's call it on the left side of the vertical class wire... insert bundle by name and *presto* it actually had the bundler wired correctly. Soooo close to usable. It won't work at all on a horizontal wire as far as I can tell.

So, if you can ensure that you have very precise mouse skills, you can actually bundle in object properties 'by name' without having to disconnect the broken wire and then reconnect the wire to the correct terminal of the bundler.

[Aristos Queue]

QUOTE(eaolson @ Aug 3 2007, 03:33 PM)

I'll admit my ignorance and confess I've never understood these benefits. If you're talking about get() and set() methods working on a private data member, I don't see any significant benefit of doing things that way compared to just using a public data member. You lose both data encapsulation and data protection.

I assume these benefits exist, I just don't understand what they are. Visual C++ went so far as to add the property keyword which sort of automates the creation of a data object along with its get and set accessors.

Advantages of a write accessor:

1) Suppose that you have a cluster that has a wrong value in it. Where did that wrong value get set? You search your entire LV hierarchy for all the bundle/bundle by name nodes, set a conditional custom probe on each one, and run until you find which one is the problem. Compare that with you open the only VI that is ever used to bundle new values into the cluster, set a single conditional probe, and run until you find the problem.

2) A given field of a cluster is supposed to always have a value in some range. Everytime a VI bundles a new value into the cluster, you have to remember to put the range checking code down. Compare that with only a single VI able to bundle new data in, it becomes easy to enforce range checking on values.

Advantages of a read accessor:

1) Suppose you have a cluster of data about a person. One of the fields is "age". Your program works great. But the next year you realize that you have to update your entire database to add one to everyone's age. You realize that you were silly to store "age" as a numeric. You change to store a Timestamp and whenever someone asks for age, you subtract from the current date. If you have a raw cluster, you now have to visit every point in the code where they were directly unbundling "age" and change it to call a subVI that unbundles Timestamp and does the subtraction. Had you had an accessor in the first place, you wouldn't have to revise any of the code except the accessor VI.

These are the big three: debug, range check, and refactoring. There are other smaller advantages. The debug advantage is so pervasive as to warrant using accessors for all data that will be accessed outside the class itself (and sometimes it pays to use the accesssor method even on VIs that are inside the class).

QUOTE

So you're creating a Frankenchicken?

Yessssssss.... who wants to be Igor? Submit resumes at NI Week!

QUOTE(Omar Mussa @ Aug 3 2007, 03:41 PM)

And then, it hit me, or rather I hit it ... on accident I right clicked a tad further to the left of a vertical class wire ... let's call it on the left side of the vertical class wire... insert bundle by name and *presto* it actually had the bundler wired correctly. Soooo close to usable. It won't work at all on a horizontal wire as far as I can tell.

LV 8.5 hasn't been out for a full day yet, but I already get to post this:

This is known and already fixed in a future version of LabVIEW. *sigh*

[Omar Mussa]

QUOTE(Aristos Queue @ Aug 3 2007, 01:49 PM)

LV 8.5 hasn't been out for a full day yet,

This is the age of information

QUOTE(Aristos Queue @ Aug 3 2007, 01:49 PM)

This is known and already fixed in a future version of LabVIEW. *sigh*

So did you 'fix the glitch' (ie remove it completely) or decide to make it work despite your arguments for accessors (which btw, will ultimately need to unbundle and bundle data from a class wire)?

[Aristos Queue]

QUOTE(Omar Mussa @ Aug 3 2007, 04:00 PM)

This is the age of information

So did you 'fix the glitch' (ie remove it completely) or decide to make it work despite your arguments for accessors (which btw, will ultimately need to unbundle and bundle data from a class wire)?

I fixed the bug that made insert of a Bundle node not find the right terminal for the LVClass. In a future LV version, Bundle will insert correctly when you are on a member VI of the LV class. We're not ever going to have public or protected data on my watch.

[Omar Mussa]

QUOTE(Aristos Queue @ Aug 3 2007, 02:09 PM)

I fixed the bug that made insert of a Bundle node not find the right terminal for the LVClass. In a future LV version, Bundle will insert correctly when you are on a member VI of the LV class. We're not ever going to have public or protected data on my watch.

Bundling/Unbundling outside of a class member VI would be a violation of encapsulation... no prob there :thumbup: .

As for protected/friend properties, I'll just say I'm not passionate enough about it to argue for it at this point. I, for one, will be crossing my fingers that the automation of accessor VIs will be as helpful as advertised.

[crelf]

QUOTE(eaolson @ Aug 4 2007, 06:33 AM)

So you're creating a Frankenchicken?

I wonder if they serve that at the Salt Lick?

[eaolson]

QUOTE(Aristos Queue @ Aug 3 2007, 03:49 PM)

Advantages of a write accessor...

See, answers like this are why I bother to ask questions. I had been thinking of the refactor reason myself, but using it for range checking makes it go from "handy" to "damn useful." To be honest, I'm surprised that subVIs don't enforce the Data Range criteria for front panel controls for this very reason.

QUOTE

This is known and already fixed in a future version of LabVIEW. *sigh*

So just how many working branches of LabVIEW are there at NI at any one time? Or do you just occasionally spin off the "cool stuff that's working" into a new version?

[Aristos Queue]

QUOTE(eaolson @ Aug 3 2007, 05:06 PM)

See, answers like this are why I bother to ask questions. I had been thinking of the refactor reason myself, but using it for range checking makes it go from "handy" to "damn useful." To be honest, I'm surprised that subVIs don't enforce the Data Range criteria for front panel controls for this very reason.

There's a good reason for this but I can't remember it right now. It made sense when it was explained to me long long ago.

QUOTE

So just how many working branches of LabVIEW are there at NI at any one time? Or do you just occasionally spin off the "cool stuff that's working" into a new version?

Spin off, fork, merge... you name it, we've probably had a reason to do it. The Mindstorms NXT was a fork of the entire source base at one point, for example. It does make versioning and VI mutation rather interesting sometimes. I honestly don't know how many forks/revisions are in development at the moment.

[crelf]

QUOTE(LV Punk @ Aug 6 2007, 09:18 PM)

An Aussie should know better than the rest of us... http://www.frankenchicken.com/''>http://www.frankenchicken.com/' target="_blank">http://www.frankenchicken.com/

From the frakenchicken website: "As the country's most famous and prolific fast food company, Crispy Aussie Chook (C.A.C.) maintains the highest quality standards that its customers deserve. Unfortunately, their customers don't realise that they deserve tainted, genetically modified, and altogether non-chicken material in their 'Fun Fried Fancy' packs."

That sounds kinda cool...

[orko]

QUOTE(Aristos Queue @ Aug 2 2007, 05:04 PM)

I didn't spend six years developing LabVIEW classes so that you guys could stay at LV7.1.

Yes, LV classes should jump out at you as awe inspiring.

Soooo..... why isn't there an NI course that has LV classes in it? Let's get real here. It's difficult to impossible to find the time (read: get paid) to learn "on-the-job". When it comes to my employer, I can sell a fixed amount spent on a course but I can't sell getting paid to learn on my own.

I'm still waiting for the courses with LVOOP and LV Classes to appear before I "convert".

[LAVA 1.0 Content]

From the NI website: "As the industry's most famous and prolific data flow programming company, NI maintains the highest quality standards that its customers deserve. Unfortunately, their customers don't realise that they deserve project-oriented, self-optimizing, and altogether non-G code material in their 'SSP' subscription packs." Give us some GOOP to dip into and we're happy!

[orko]

QUOTE(LV Punk @ Aug 6 2007, 10:24 AM)

Give us some GOOP to dip into and we're happy!

As disgusting as that sounds, I agree!