LabVIEW Developers Feature Brainstorming

[TRW Design TEE]

My favorite way to learn "new tricks" is to have a monthly code review meeting where everyone discusses coding techniques around the nice hot projector drinking a warm cup of tea.

[bogdani]

Hi Takata Test

Could you tell me where can you learn LV in that way, because I want to join to your group :-)

[ChrisReed]

Well I don't know about you guys, but I'm finding it increasingly difficult to keep up with all the new improvements in LabVIEW.

1) I find the best method is to attend a seminar presented by a LabVIEW expert/ NI who actually shows you how all the new features work, shortcuts, tips, things to watch out for etc..  I can learn more in a two hour lecture than spending days on trying to learn it myself and because they are free they are very cost effective

2) Training Sessions (NI / Third Party) are also very effective, but they don't seem to cater for the person who has good knowledge of LabVIEW, but is no expert and wants to learn all the tricks for good large scale development software.  They also tend to be fairly expensive, but are worth the money in the long term.

3) Some of NI's video tutorial's and web events also give you a good audio/visual description, but they tend to be fairly basic.

4) After that it's basically scouring the Example VI's, Developer Zone, infolabview, Open G and LAVA (not necessarily in that order) to get some idea of how a concept works.

[handbone]

Back Ground first.  I started with Labview 3.1 and I am using 6.1 now. I have tried 7.1 and 8. I hate both of them. Quit changing the interface MICROSOFT!!! I have a 21" screen and still don't have enough real estate. Get rid of the giant icons... If you need it that simple(which never works for me) sell it in a different product, leave Labview alone.

I have to agree, the Help is Lame. And when you dig deeper into help you get another lame (short) discription of what a function does. Inverably there won't be an example for it either.

What got me going in the begining in Labview what the example programs. Also, that was the best thing about borland C. If I wan't to know what a function does there is an example I can cut and paste in my code.

So, I would like to see more function and more examples and more discription in the help. CTRL H. Leave the interface alone, I don't want it, and I am not using it. It's only a bunch of Fluff and not much more usable code.

I think you are trying to please the Newbe's over the Oldbe's, Us Oldbe,s just might say screw it and go back to Microsoft.

Ok, I feel better now.

[bogdani]

Chris Reed wrote: (...) 1) I find the best method is to attend a seminar presented by a LabVIEW expert/ NI who actually shows you how all the new features work, shortcuts, tips, things to watch out for etc.. (...)

I must agree with you, I always was on NI seminars, but last time when I went there I was borring, because there was so many marketing talk.  I need information about new function, how to use it, etc. but they talk about what many we earn with LabVIEW. ...

Now I am trying to read forum (that forum) and LAVA, and of course my Polish LabVIEW forum.

I thing talk with others and solving different problems that is the way to practise and be the best in my profession.

bogdani

[shoneill]

I like to learn LV by thinking "Hmm, I've never used X" and then just sitting down and trying them out.  Usage of the help is optional, but often advantageous.  The exmaples provided with LV are generally very good.

Examples of X could be Queues, Notifiers, Menu items, State machines, Typedefs and so on.

This is actually how I've learned a lot of the LV functions.  I learn them one at a time, at my leisure (or requirement) and I don't know HALF of what LV can do.

I've only recently bought my first LV book (Software engineering approach to LV) and found that I already know a lot of what's in it.  I've never taken a LV course.  I've been to a few LV marketing talks (sorry, I mean Information days) but that didn't really give me anything new.

Of course I also learn a lot from the LV forum.  I find it a great source of what's being done with LV, where common problems are and so on.

My 2c

Shane.

Message Edited by shoneill on 02-28-2006 02:58 PM

[Baturin]

I learn new things when I need to do something that I have not done before or just remake some old idea to new level. Usually the first thing that can be enough is to slide over function palette, maybe using search. Something like 50 % that I will figure out what I need from that. The graphical nature of language and icons are very impressive by the speed to get an idea how it can be used. The Ctrl-H is of course the #1 must have thing.

Secons step is to experiment a bit, look into suitable examples and modify it.

On-line help is nice, but I have experienced a lack of links to in-depth discussions about topic. The manual and help refer each other, but without direct links! On-line help is great when you need to refresh something or just refer to correct format etc, but very short for learning.  My idea is to have direct links to manual if possible and even better  to have a links to devzone section or enything else describing the particular topics in on-line help (to gen an overview and what's under the hood). How about to glue together Manuals, appnotes and on-line help in one place?

Another thing is that on-line help tends to explain everything that couple of day LabVIEW user will never need again like the description of error in and out for each of xxxx LabVIEW functions. Maybe providing a link is better there?

[waldemar.hersa…]

I normally start with the examples, then with Help, Online tutorial, experimenting and the dicussing it with collegues. And at last I use the discussion forum.

[Daklu]

I may be a bit late to the party, but since I just starting learning Labview last week I'm in a unique situation. What I did was attend a half-day informational session that explained the very basics of LV. I picked up a demo copy, brought it home, and found the Tic Tac Toe coding challenge.

From there I spent several hours going over the code, tracing the execution path, and probing the wires until I had a pretty good idea what was going on. After that I started working up my own algorithm using the 'two steps forward, one step back' approach. This has worked reasonably well for me so far, but it's not really my preferred method...

First choice - A printed manual with good explanations of not only on HOW things work, but WHY they work that way and WHEN it is appropriate to use them. With a printed manual I have the option of reading while taking my kids to the park or sitting in front of the computer with the book. I prefer short examples over longer ones -- short ones are easier to understand right off the page.

Second choice - Mentor/Mentee (or is it Mental?) relationship. Having someone knowledgeable and nearby who can answer questions immediately and to the point is invaluable. But... I suppose it's a bit much to have NI ship a support tech with every copy of Labview... *sigh*

Having a supportive and knowledgeable online user group is good too, but nothing beats face to face discussion.

Third choice - Finding online source code and using the help files. The problem with example code is twofold.

1. Rarely can one find code that does exactly what they need it to do. Usually there is some (unknown) key difference that makes it difficult to use the example code directly in my own app.

2. Online source code (be it samples or programs) are rarely documented to the level required for someone who is learning about that particular area. We're left to sort out what is going on using a combination of execution tracing, help files, and online searches. If I'm lucky I can piece together what is going on.

And as someone mentioned previously, help files are okay if you just need to refresh your memory on how something works, but they are inadequate for trying to learn it.

(A recent example of an issue I am having is trying to figure out how to correctly implement error handling in my application, including how to throw errors if I need to. The help files have been nearly worthless.)

Fourth choice - Training courses. Generally effective, but the expense and time off of work can be very hard to justify. In person training courses invariable move at the pace of the slowest person in the room, so they can get tedious. 'Work at your own pace' tutorials and training videos are a bit better, but lack the instant response to questions and explanations.

Just my sqrt($1/2500)

[Albert.Geven]

error handling in labview is so easy that a good example seems to fail

Always wire an error in and error out and inside check for error and skip if an error is already present.
You never want to mask the first real error.

If you have parallel error wires use merge error (still looking for a way to gather all errors) but the most important one has to be in error out.

That is all to make error handling work, but the finer details are for chapter 2