Val Brown

QUOTE(Ben @ Aug 16 2007, 11:52 AM) 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) 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) 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) Clearly it was a scalable comment.

QUOTE(lavezza @ Aug 14 2007, 07:37 PM) Yeah, that's what I thought and that's really disappointing on several levels.

QUOTE(Aristos Queue @ Aug 14 2007, 02:10 PM) 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) 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) 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) 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) Absolutely -- it's a really cool, intuitive and easy to use feature.

QUOTE(Val Brown @ Aug 4 2007, 11:11 AM) 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) I thought perhaps by cRElF...

QUOTE(Michael_Aivaliotis @ Aug 3 2007, 09:54 PM) Is that by reference or by value?

QUOTE(i2dx @ Aug 3 2007, 11:29 PM) 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) 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) Does evaluation mode pose any functional limitations?

QUOTE(jaegen @ Aug 3 2007, 11:37 AM) 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) 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) 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) 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) 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) 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) 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.