[youtube http://www.youtube.com/watch?v=9cKBdn4uHyY%5D
Props go to [Michael Nash] for establishing an interface between National Instrument’s labVIEW and an Arduino (an example video using a potentiometer is above). Personally, from the one time we were forced to use labVIEW, we hated every second of it.
One reason it’s so terrible, is the Data Acquisition Modules cost well into the hundreds of dollars, yet the documentation and help resources are very scarce. By using an Arduino instead of the modules, the price and difficulty decrease a considerable amount. Which begs the question why has it taken so long to get a decent (and so simple) of a setup working?
I used this software at school. My first concern is the fact that this software cost thousand of dollars, is extremely buggy, takes hours to load, lag, and eat resources like shit. This software is a shit,, programmed like a shit, act as a shit. To do the same very thing in c, we could do things that take 1% of the resources, don’t bug and we have a better control over it.
This software is made so people that aren’t capable of using a computer are able to program things. I never understood the point of programming with picture and lines (in fact I don’t understand any kind of hi-level programation)
I think this “hack” illustrates an inexpensive way for students that are not programmers to collect data without paying a premium for high end analog to digital conversion that isn’t really necessary. I personally use cypress PSoC with USBUART or USBFS (firmware written in C) tethered to Labview and it works great.
I followed one of the links above to SciLab thinking that it would be an open source alternative to Labview as mentioned above, and it is not. It is an open source alternative to matlab.
Matlab != Labview
Oh how I wish I would have had a guide like this when I was doing research on a miniscule budget at school. The college had a site license for Labview, but nobody had hardware for it.
It’s great! I love it. Very intuitive way of programing. If you understand it, you can whip out a program to do something very quickly. Much faster than typing it in line by line, no matter what language you’re using.
As for input boards, I always worked with boards at work, or the ones I got from work, so that was never an issue.
(believe it not, the company I worked for bought a full package and boards, then when I transferred out of the lab, just tossed it all out. So now it’s MINE!)
Another interesting example fo labview with a serial cpu board: http://www.hotsolder.com/2010/06/cost-effective-digital-io-for-labview.html
Another alternative is to write your own control software (if you can !). For one of my projects I put together a quick charting software that I called “SerialChart” it is written in C++ using the QT IDE. I decided to go with my own software because I can tweak it the way I want and nothing compares to the speed of compiled C++ ! You can see an example of it’s usage here , including screenshots:
http://starlino.com/imu_kalman_arduino.html
I now updated the software to support USB HID as well as other binary encodings besides RS232 with CSV output. I am also planning to build some simple controls like dials/sliders. This project is open source so feel free to tune in !
http://code.google.com/p/serialchart/
There are two types of people on this thread. Those who like LabView and those who hate it. These can also be called ‘knuckledraggers’ and ‘software engineers’. If you are a knuckledragger, then LabView may be just fine to cobble something together. Software engineers have to worry about crazy things like maintainability, documentation, source control, etc.
I was former NI Apps Engineer and worked as Developer for an Alliance member… All in all did about 5.5 years worth of LabVIEW with 3.5 years of TestStand and some MySQL. I got out of that and I’m doing ERP systems now. I found it boring working with hardware.
Some ideas about LabVIEW
1) If you plan on being a test engineer or doing rapid prototyping stuff… Than LV is good for that.
2) If you plan on doing process automation, factory automation and all that. Pick up ladder logic and PLC based hardware. Very few people will trust LabVIEW for Oil & Gas control based projects. If you’ve seen the “Insane Object Error” you’ll know what i mean… The Programmable Automation Control (PAC) argument or 80/20 rule where a PAC can be used for the 20% of the work is essentially the so called niche projects that are fairly non repeating business and garbage that the bigger vendors won’t waste their time and money on.
3) If you want to head into MIS/IT/Business Apps development… Learn anything else except LabVIEW.
To the guys who are complaining about labview being slow, maybe you should catch up and get a better computer, it doesn’t run well on old crappy systems.
Thanks to all of the contributors to this forum. I have read it to understand what the best tools are for my projects (yes, plural). I am a newbie to LV. (As of 2 days ago!). Can I ask a question of you? I like working with flowcharts, then coding in C for an embedded processor application. Some of the projects I do are for industrial control purposes, others for machine control. I see advantages to using LV in both areas.
1. Machine Control: Using LV to create flowcharts that actually work, then coding PIC processors in C from the tested flowchart.
2. Industrial System Control: Using LV to create flowcharts and control panels that work in a virtual environment. I can then confirm visually with my colleagues that my designs match their criteria. After that I would be able to write the C code and assembly code for microcontrollers which will be the actual industrial process controllers. (I am thinking of Ian’s comment above, that LV is not suitable for controlling safety critical industrial processes).
A last thought. I work in a foreign language environment, and as they say, ‘a picture is worth a thousand words’. I believe confusion can be avoided with good graphical tools and good demonstrations. So, if some of you folks have a view that a different package is better for my needs, please consider the visual demonstration requirements. Thanks everyone.
With the advent of datatypes and the ability to very easily integrate scripted language wherever you desire, Labview would be an absolutely fantastic general purpose programming language if they could manage to release a stable version and get rid of several thousand reported bugs. I wish I was joking about the number of bugs. Glance at the support forums for ten minutes if you don’t believe me. I like Labview. But it’s genuinely unusable for serious projects in its current bug-riddled state. Corrupted files, frequent crashing, memory leaks, and completely unpredictable behavior make Labview a VERY bad choice for a large project. Each new release has introduced more new bugs than have been fixed. Again, that’s not an exaggeration. I have enough work debugging my own code without having to help National Instruments debug their overpriced development platform. I sincerely hope they fix it some day, and I believe that they shall since they’ve grudgingly admitted that they have bad problems with stability and crippling bugs. Until then, avoid it. Cheers.
According to wikipaedia, similar to lv is opendx, but opendx seems to have the advantage of being able to save visual programs as scripts.
I know this post list is getting old, but…
I am the exact opposite here. I have been using LV on and off for over 10 years at work, have built some cool automated projects even at home. I just now am getting into these microcontrollers and am saying to myself – this would be so much easier in LV! But I do see the Pros/Cons to all systems and it IS WORTH YOUR TIME TO LEARN. It pay$ off in the long run.