I've accepted a new position and I am told there is a significant amount of exiting test code writtin in LabVIEW, a language I briefly used a decade ago. Much has changed since.

While I can bang out a rudimentary vi and even use that in another vi, I know I am missing some fundamental concepts and believe it is time to buy a book or manual on the language.

My local sales rep only suggested some online tutorials (which I will view shortly but have found lacking in the past).

Is there anyone out there who uses this language and can make a book recommendation?

 

I use Labview. But a good book about it. I am not sure. Have not needed such thing in many years. What will be your type of application? You good also try a search on Google books. Just to get a preview. If you give me list from Google books. I might be able to tell if the book are good or bad. In Labview you must think data flow like then drawing a schematic. Do NOT try to implement C structure and thinking

 

Labview will rot your brain. Just kidding. I friend of mine uses it. He write programs by making a flowchart in a graphical interface, and gets executable from it. It's a sort of dumbed down programming environment.

Sorry, I know I'm not helping. Maybe next time

 

the GML style of Labview is hardly a dumbed down programming method. Labview has powerful functions, and when compiled to executables, runs briskly, and, under several architectures.

I've found online to be the best resource for learning Labview, along with the many examples offered in their distributions. Much of applying labview becomes an investigation into the quantums of the problem at hand, searching for articles that deal with applying Labview in those specific cases.

 

I didn't say it it didn't run briskly or wasn't powerful. I said my friend got executables without writing any code. That's the dumbed down part.

 

I didn't say it it didn't run briskly or wasn't powerful. I said my friend got executables without writing any code. That's the dumbed down part.

Why is drawing the code as opposed to writing the code "dumbed down"?

 

I wouldn't really call it drawing code. You make a flowchart, and the code falls out of it. I'm sure there is more to it than just the GML entry method. I scarfed a book on Labview, never read it. It might be a little dated, but I can send it if you want, and if I can find it.

 

Thanks for the offer. Yesterday I selected a book on Amazon with a 2012 date so it covers the current version.

It arrives Tuesday so I've got this covered.

 

I attended a 5 full day course on Labview. The NI instructors are really good. I think this would be the fastest way to pick up Labview programming provided that your budget allows.

 

I attended a 5 full day course on Labview. The NI instructors are really good. I think this would be the fastest way to pick up Labview programming provided that your budget allows.

I agree! I did something similar last year. The National Instruments Group has plenty of training courses, technical help and support lines as well as user groups that you can benefit from. It is in your employers interest to fund your knowledge. Personally, I think LV is great but NI certainly make a good sales pitch trying to ensure you also use their hardware, albeit high quality.

Good luck.

 

Hi ErnieM. If you're still looking, one of the guys I worked with at the university (prof. Timothy Johnson) put together an online manual for the students to use in their labs. Here's a link: http://myweb.wit.edu/johnsont/Classes/LabView_Labs/LabVIEW_Resources.htm

They are fairly in-depth and may be very useful to you.

Best of luck!
Matt

 

Interesting link Derstrom, took a peek, will look some more later. Thank you (and Andreas too) for your warm wishes.

Diving into this stuff I first got (as soon as they made me an offer) Hands-On Introduction to LabVIEW for Scientists and Engineers, which is a very good intro book. But it never progresses beyond creating a single virtual instrument, or VI.

See, in LabVIEW (or G as it is known), a VI is akin to a subroutine, and it's basic unit of functionality. Using a single VI is like writing a program without any functions: sure, you can do some nice stuff, but it's kinda limited. So I keep looking...

One interesting find for me is The LabVIEW Style Book. It is interesting because it is written by Peter Bloom, "the founder and president of Bloomy Controls, Inc., a National Instruments Select Integration Partner" and the company contracted to create a test package I have to support. I've yet to crack the spine but this has to be the company bible for coding standards for the stuff I have to support.

Lastly... end of the day poking about my office computer I come across a LabVIEW icon, click it and version 4 starts running. It's horrible, VI's lack any naming ability and just appear as start data types with no detail on what they are. Yuck... as soon as I get home I discover Amazon still has listing for some version 4 books, and they are dirt cheap. I mean $1.66 cheap, $5.65 with shipping.

So I'm not upset at all when I learn we actually have and use the 2012 version on the floor. Cool.

The book comes today. The seller noted it had the disk. I forgot to ask was it a compact disk or a floppy disk:

Yep... there's the floppy disk!

LOL, I don't have any drives hanging about either.

 

The LEGO NXT robot kit uses a version/permutation of LabView (apperently both originated at Carnegie Mellon University). It is powerful but I somehow felt limited when i worked with Lego NXT with some school kids. Everything could be done as I would have with C on a PIC, I just needed to get my head around the "NXT way" and alter my thinking a bit.

My wife used LabView in 1989 - 1990 on an original Mac. All kinds of NI interface cards are available (USB / PCI / ...). Just connect your wires into Analog pins, digital pins, or what ever. The interface cards and software take care of the rest.

There is so much programming already done that the vi Developer only has to enter numbers in each icon, add some logical conditions in diamonds and make connection to sensors and motors. No code required.

I think "programming" in LabView is like doing number crunching in Excel when you were used to doing it in FORTRAN. NOTE: I didn't put " " around Programming to offend anyone, I just did it to make sure nobody thinks programming is required. LabView is more "Setup" than programming.

 

That was sort of my point earlier. Many tools are coming online that makes it possible for a non-something person to do that something. Labview was one of the first, though it can be reasonable argued that it's just a tool to help programming. I used such an graphical programming environment years ago and found it to be clunky. Eventually I just started hand-editing the underlying code.

 

I scarfed a book on Labview, never read it.

I can well see the depth of your informed opinions. Pray continue to bless this thread with your wisdom.

 

I can well see the depth of your informed opinions. Pray continue to bless this thread with your wisdom.

Oh no, you're the foremost expert. You have a book with a diskette and everything. We shall all bow down to your eminent expertise.

 

At least try to NOT use many Express VIs. It may be tempting but they only create problems in the long run. They highly mess up meduim and large program. No Labview pros use them