Val Brown

QUOTE(Ben @ Aug 16 2007, 11:52 AM)

I was trying to sit back and try to learn something but your last comment has me smiling becuase of two statements from people around me.

One said "It is like using a bunch of "goto" statements". The other was my wife who has repeatedly said "Goto statements introduce chaos."

Ben

FWIW, I used to use that as a way to talk about the difference between assignment and equality tests:

GOTO=CHAOS <> GOTO==CHAOS

QUOTE(jzoller @ Aug 15 2007, 09:33 PM)

Something I haven't seen on this post: money. Depending on the organization, it may be the only language your boss' boss knows, speaks, or cares about.

Your NI sales rep should be able to quantify benefits for you there as well.

Joe Z.

P.S. Orko, that was magnificent

Yep, money is a good one and, given all of the others, if the organization doesn't go for using LabVIEW as its standard, it will be pretty clear that it really wasn't and isn't a "technical" issue but an identity/"religious" one. And they're the toughest of all to deal with.

QUOTE(Aristos Queue @ Aug 15 2007, 03:43 PM)

An effective demo... get a C programmer or Java programmer to write the standard "random number strip chart" VI ... two parallel loops updating two displays. Compare the code between them. Point out to your boss that anything that C/C++/JAVA can do, LabVIEW can do as well since they're all complete programming languages. The advantage is the natural parallelism and the code readability to layity. The very fact that your boss can understand the LabVIEW code and probably not the other may go a long way to convince him that the overhead of bringing a new hire up to speed on a LabVIEW code base is generally less than the overhead of getting them to learn a C/C++ code base. That savings right there may be enough to convince.

Bear in mind that this is really a religious question masquerading as a data/scientific/programming issue. It's the old question of: "who's a REAL programmer and what language do they use" And it's driven by the "other guys" who probably use C/C++ and are really terrified at how simple and easy LabVIEW is in comparison. Of course, they undoubtedly don't think of it that way -- they think of it as a "functionality" issue (and, of course, LabVIEW is a "toy" or "just not serious") or some other "spin" -- but the bottom line is that you can use what they do -- easily -- in your code but the converse isn't true. That's one big vote for consolidating operations using LabVIEW and not the converse.

So remember that for "the other guys" it will feel like a fight to the death -- it won't be an academice or rational discussion about the real pros and cons of any particular language. And it won't be that BECAUSE it's an identity issue. As has been pointed out above, it's really difficult to not see how LabVIEW is really the better choice. There are simply too many ways it which it really outstrips other languages, esp in terms of support, scalability, maintainability and ease of learning.

And, yes, bring your DSM into this loop. Let NI know what's at issue and see how much they bring to the table to help you present your case. If the bosses et al are al all interested in functionality -- and not just driven by their prior committments to other language and such -- it will be a virtual "no-brainer" for your company to standardize on LabVIEW.

QUOTE(NormKirchner @ Aug 15 2007, 01:41 PM)

WOW... $2.00. Must be an increase because of the premium membership

Clearly it was a scalable comment.

QUOTE(lavezza @ Aug 14 2007, 07:37 PM)

NI.com lists it as $1499 in the US and CAD1800 for you Canadians.

It it marketed as a Module (on the same level as Real-Time, FPGA, PDA, etc.) and not as a toolkit (like database, VI analyzer, etc.). Most other modules are available with a significant discount if purchased with the NI Developer Suite, but it doesn't look like the Statechart module has been added as a Developer Suite option yet.

Pat Lavezza

Yeah, that's what I thought and that's really disappointing on several levels.

QUOTE(Aristos Queue @ Aug 14 2007, 02:10 PM)

I think we'd need some more details about what exactly you think is behind us. NI just released the new Statechart Module for building really advanced state machines. I don't think that architecture is behind us. Are you simply referring to programming individual state machines should be avoided in favor of using some reusable framework? Because that I agree with.

Quick question on the Statechart Module -- is that included in 8.5 or is it a separate (purchased??) module/toolkit?

QUOTE(Aristos Queue @ Aug 13 2007, 01:52 PM)

You're talking all data types, not just LV classes, right? ...

I don't particularly like open-ended plugable functions (aka operator overloading). With the dynamic dispatching of classes, I can view the class hierarchy and know whether or not a given class has a given functionality. With arbitrary overloading, I become less sure at every turn whether that "add" primitive that I see on the diagram is actually an add.

James Gosling, the inventor of JAVA, left operator overloading out of JAVA because he saw C++ and noticed that it was now *ANSI standard* to use the left shift operator for output to a file. I've seen C++ code where "a == b" was overloaded to not actually evaluate whether a equals b but instead was a special type of assignment (deep assignment instead of shallow assignment, for those who know pointers). That sort of horrific situation is not one that I want LV to enter into.

Absolutely. This has been one of the biggest concerns I've had over what APPEARED to be (but actually wasn't/isn't -- I hope) a headlong rush to make LV into LV++. After hearing some of the buzz at NI Week, I feel much more comfortable with the development as it's proceeding. Nicely done, esp to you AQ and esp re: the Tarot deck ;-)

QUOTE(Michael_Aivaliotis @ Aug 12 2007, 12:35 AM)

Yen, I have to say that I went to NIWeek for two years before I figured out that there's a whole other underground "track". This track is where all the cool LabVIEW developers mix with the advanced LabVIEW users and have thought provoking discussions you don't find in the normal tracks. I'm talking of course about discussions during lunch, evening, hallway chatter and hanging out at the JKI booth.

It's kind of like that old idea of developing v1 to throw it away -- go to your first NI Week to prototype the experience and then throw all of the assumptions and expectations you brough to that first "failure" and do the real deal at the next one, your own personal NI Week v2.

QUOTE(i2dx @ Aug 10 2007, 11:21 PM)

/signed

~~~~~~~~~~

I like the "In place nodes", too. It seems we are getting pointer operations in LV without the hassle of pointer arithmetics. Great! :thumbup: I'd like to see more of that

The coupling between file hierarchy and project hierarchy also helps a lot to keep track of your project. Thanks

My impression about LV 8.5 so far is: there are many improvements "below the surface", without annoying the users with bells and whistles (..which the marketing departments like so much )

Yes, yes, yes and yes. I've already deployed my next release using 8.5.

An additional day geared towards advanced users sounds like an excellent idea. I'd also like to see more judicious scheduling. There were a number of times where interesting (at least to me!) presentations overlapped so you were forced to choose one. Some times this will happen -- I certainly understand that -- however, that saturing of some time slots was juxtaposed to some slots were there really weren't topics of interest (at least to me!) for the intermediate to advanced user.

Now I don't want my comments to sound negative. I think that overall NI Week was really quite good. It's the first one I went to and I've been using LV since 98. Before this it really did seem like it would be worthwhile to come down. I don't know that the prior ones were NOT useful or worthwhile!!! Again I'm not wanting to be negative. But I can say that this one was really informative and revelated some interesting things --- like LAVA underware. Having used BRIEF a long time ago that somehow reminded me of....OK I won't go there.

I did pass along my comments about trying to schedule more "advanced" programming sessions and it was pretty well received from what I could tell. So, at this point, I suspect that I'll be coming back next year. I can't bear to think that I'd miss the LAVA BBQ. And of course it was great to meet everyone face to face otherwise I might have continued to believe that crelf only wears a tuxedo.

QUOTE(Ben @ Aug 7 2007, 06:44 AM)

A big "ata-boy" to whoever got that in place. It made avery good first impression on me.

Ben

Absolutely -- it's a really cool, intuitive and easy to use feature.

QUOTE(Val Brown @ Aug 4 2007, 11:11 AM)

OTOH as a single developer working primarily on my own deployed product, I expect to be up and running in 8.5 as my IDE by the end of NI Week. Perhaps even sooner... ;-)

OK so here's a follow up note -- in a few hours the actual (ie non-Alliance members part of) NI week begins and I have already transitioned my 8.2.1 project to LV 8.5. It was an interesting process -- which gave me a great introduction to the "Resolve Conflicts" feature of the new Project interface deployed in 8.5. That was a bit of a ride since my project is over 1400 VIs and spans several different folders on my development system but, I must say, the built in process did work, and worked well, in resolving all of the conflicts that arose during the transition.

If that process works well with as complex -- and problematic! -- as my Project was, I can only assume it will be a much needed and much valued tool for those with less challenging migrations.

The other issue that was interesting concerned the Database Connectivity Toolkit (DCT). It kept on throwing errors re: the DB Variant to Data functions. It took a bit of detective work but here's the fix for this (at least it's something that I found that worked). It's probably not at all "official" but it did work for me FWIW.

There is a new folder in the 8.5 installation:

<labview path>\vi.lib\addons\_DB Variant To Data in prior iterations of the DCT there was a similarly named folder in: <labview path>\vi.lib\addons\database -- so <labview path>\vi.lib\addons\database\_DB Variant To Data This earlier folder needed to be zipped -- so it could no longer be found by LV (8.5) when it loaded. After zipping that folder my DCT functions loaded and compiled without problem. Prior to zipping up the older _DB Variant To Data folder loading DCT function generated an error in LV 8.5 around the DB Variant to Data functions. I suspect that as the release matures there will be a more "natural" way to transition 8.2.1 DCT-related functions -- perhaps a reinstall of the DCT or???? But the procedure I've just described worked and I'm now happily exploring 8.5 with a legacy project. So far so good and so far so cool! There are lots of really great features. :thumbup:

QUOTE(crelf @ Aug 4 2007, 01:17 PM)

By val Val.

I thought perhaps by cRElF...

QUOTE(Michael_Aivaliotis @ Aug 3 2007, 09:54 PM)

crelf, don't forget that there are TWO Salt Lick locations. Make sure the directions are to the correct one. We have more people this year so we are going to be at the big place right?

Edit: Just confirmed with crelf. He's got the right address.

Is that by reference or by value?

QUOTE(i2dx @ Aug 3 2007, 11:29 PM)

lol, the same with me. I started my first LV 8.2 project in April this year. I have just finished to upgrade my largest project to LV 8.2.1 from 7.1.1 and now ... we have 8.5. puh, it seems, I have to work a little bit faster to catch up with the prodictivity of NI R&D

Not to forget, I just rewrote my Tool Chain a few weeks ago for LV 8.2.1 ...

OTOH as a single developer working primarily on my own deployed product, I expect to be up and running in 8.5 as my IDE by the end of NI Week. Perhaps even sooner... ;-)

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?

QUOTE(jaegen @ Aug 3 2007, 12:54 PM)

I've installed it now with no problems. I don't think their activation server is ready for 8.5 yet though. It didn't like my serial number when I tried to activate automatically, and the website version drop-down only had 8.0 and 8.2 in it, so I'm currently running in evaluation mode.

Jaegen

Does evaluation mode pose any functional limitations?

QUOTE(jaegen @ Aug 3 2007, 11:37 AM)

When I click on the link it takes me to the little questionnaire for downloading 8.5 - and as far as I know I'm a mere mortal too. I got there through http://digital.ni.com/demo.nsf/websearch/14F9CE475127ADE786256AC60070926C?OpenDocument&node=157200_US' target="_blank">here, even though it says it's for 8.2.1.

Jaegen

Yes I understand they're actually doing the update to the website manually so we're riding the bleeding edge of that one...

Have you done the update yet? If so, anything "interesting" in that process, or should I just take the plunge?

QUOTE(jaegen @ Aug 3 2007, 10:26 AM)

Evaluation Software Online Request Form is up too.

Jaegen

But apparently nothing is available -- at least to us mere mortals -- until Monday: ie the Alliance Day of NI Week.

Can I stand the suspense of waiting S O L O N G

OK, latest breaking news from the front: https://lumen.ni.com/nicif/us/lveval/content.xhtml

You may have to go through ni.com/downloads then evaluation 8.2.1 and then 8.5 becomes available using the link above. I'm downloading it even as I'm writing this.

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".

QUOTE(JoeLabview @ Aug 2 2007, 02:38 PM)

I heard something about a "Salt Lick / LAVA OpenG BBQ"...

:thumbup: :beer:

OK, but what that "Salt Lick / LAVA OpenG BBQ"...

And now, being a little bit more serious, does anyone know of anything happening on the Friday???

QUOTE(fliesskomma @ Jul 18 2007, 08:11 AM)

Hi Val,

I began using legacy serial drivers with LabView 6.0 which worked quite well with most devices to communicate with.

Later on, I developed Software for some serial communication with several serial ports, beeing busy at the same time. Every time when there was a continous (115kbd) bytestream to read, with a size above of a couple kByte, serious dataloss occured.

So I changed to VISA (Lv6.1 ... Lv7.1), where I could adjust read- and write buffer size and all communication errors vanished.

The adjustable buffer feature of VISA was the deciding reason for me to change. I didn't find this feature in the legacy drivers. Please tell me, if I'm wrong.

Maybe this information could prevent you running into problems.

Interesting -- I haven't had problems with the legacy code (except being able to use it at all at one point!) but, then again, I've always allocated a 5K buffer, at least. On each init call, the buffer size CAN be set -- what difference that actually has is difficult to assess because of how serpdrv and its related code works.

QUOTE(yen @ Jul 18 2007, 03:23 AM)

Do you have the RT module installed on that PC?

If I remember correctly, there are two versions of the legacy VIs - one which uses VISA internally and another which uses serpdrv. I remember seeing the second kind in a computer with RT installed, but I suppose it's also possible it is installed by default if you do not install VISA.

No I'm not using RT and no the legacy serial i/o VIs are not installed by default any longer (since about v7x I believe) in their original form. Since v7x (or so) what were called the Legacy Serial i/o or Compatibility i/o VIs were just wrappers for VISA calls. The original "legacy" serial i/o VIs used the serpdrv file and to use them now requires copying some additional libraries to overwrite/replace the standard serial library. It's not difficult to do but you have to use the actual, legacy VIs etc or you will just be left with wrapper for VISA calls.

QUOTE(BrokenArrow @ Jul 17 2007, 01:21 PM)

Great stuff, from the horse's mouth!

OK, so I've got an opinion! Yes!

It has been our experience that XP and serpdrv work OK together. I'm sure VISA is better*, and I'd take a reduction in pay to be able to change our old 5.1 code to 8.2.1 / VISA, but they know it would be a month-long project, and we be a tiny company.

THANKS for all the suggestions.!

* VISA functions also have error in/out and more easily follow LabVIEW style. They are worth it for that alone. No one mentioned that, thought I would!

Absolutely the error flow is great but SOME measure of that can be implemented even with the legacy serial i/o VIs. The problem that I found with VISA was, quite simply, the amount of overhead that it took to support.

I also want to be clear -- you COULD change your code to LV 8.2.1 and NOT use VISA but continue to use the legacy i/o VIs. THAT is what I've done with our current deployed code, which runs on XP as well as Vista.

QUOTE(yen @ Jul 17 2007, 02:32 PM)

:thumbup:

Likewise. Very good.

Oh dear, is that the http://forums.ni.com/ni/board/message?board.id=170&message.id=259564#M259564' target="_blank">second Blues Brothers reference today? :laugh:

I still say go with BUGGER.

Could also go with LaGOOP or even LabGOOP...

Actually Aristos, common use trumps copyright -- it has to be unique to be copyrighted -- same thing for trademark and patent. The biggest issue isn't the US legal system -- it's the best that money can buy. The biggest issue is that everyone thinks that it's the only or best way to handle these kinds of issues. And that means that the issue comes down to who has the deepest pocket -- ie who can buy the most justice. Getting a patent isn't all that difficult -- enforcing it, esp re: software, now that's a very, very different issue.