Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 9 years ago.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Improve this question
I'm trying to implement a system that can produce a sheet of music for a piano piece as and when it is being played, that is, it should be a real time transcription and not that of a recorded piece.
So far I've been testing on wav files, using FFt on MATLAB, but when it comes to real time, the system needs to be really-really fast.
Any suggestions on what kind of approach I could use, the type of board (I've thought of using Arduino). I could use, because I'd like to directly transfer my MATLAB code rather than converting it to C.
Any suggestions on what kind of approach I could use, the type of board (I've thought of using Arduino). I could use, because I'd like to directly transfer my MATLAB code rather than converting it to C.
You can have different approaches to your project that I can think of:
First there are some pianos that have an electronic device that can output the played notes through a midi interface, with velocity and position. It's the most accurate and fast solution to track played notes, though not much DIY. On the computer side, you'll only need a midi interface (that can be easily done using an arduino) and have a software that transforms MIDI notes into a score ;
Then, you can mimic that behavior, by wiring the keyboard of the piano to sensors that will be able to measure velocity and which note has been played. There are many strategies you can use (from using lasers on the mechanics, to pressure switches...), it all depends on the investment you're ready to make ; There an arduino (like the mega or the due) can be a good solution.
But as you were talking about FFTs, I assume you want to record the sound made by the piano and detect keys. There you hit state of the art knowledge on music research, the problem you'll meet is the multiple f0 detection in polyphonic music, though there are strategies specific to piano, it's still a very active research field.
Let's assume you're only doing monophonic detection for the transcription. The problem will be that the Analogical-Digital-Converter included in the Arduino just sucks, it has a definition of 10bit which is way too low to detect anything useful. With the Arduino DUE, you may have a bit more definition as it features a 16-channel 12-bit 1Msps ADC. Which is still not much for a good transcription. So you'll either have to create use an external ADC like the Linear LTC2383-16 which is 16bit 1Msps and has a SPI interface, the minimum to begin playing. Behind that you'll need to find the correct microphone and create the good electronics between the ADC and the microphone (which I don't know much about).
Finally, would'nt it be easier to take a small computer (like the Beaglebone or the RaspberryPI5), plug in a really good USB ADC/sound card, and use that board to pipe through the transcription? You may as well run your software on a cloud server (like google appengine or AWS) that has enough processor to make your Matlab run happily.
So to make a good real time and embedded transcription of music, the best solution is the first solution (or second if you really want to go DIY). If you really want to go through the "air" interfaces, I think the good solution is the fifth.
And finally, about the code, I'd advice you to convert your code from Matlab to Python (if you don't want to write C/C++ code) it will run significantly faster. So you can figure out how bad Matlab is, when I was working for the IRCAM, I have written a tool that was converting Matlab source code to C++ source code, and once compiled result were 40x faster.
HTH
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
after a long term of reading the theory behind neural networks I finally want to stark to do my own project in object recognition.
However I struggle to find a practical entry point. I want to use either C#,C++ or C however all new tutorials seem to involve newer languages such as python.
For starting I would especially like to reprogram the theory concepts of Yann LeCuns publications about object recognition.
Which programming language is recommended to use? And much more important: Which framework do I use? There seem to be docents of frameworks (AForge, Apache Mahout, OpenCV) and my theoretical knowledge seems to be too impractical to differentiate the usage of these.
I want to program a simple independent neural network application which should be easy trainable plus I don't want to reprogram classes such as neuron or layer in order to focus on the architecture for the beginning.
Thanks and sorry for the simple probably often ask question, however I just couldn't find anything matching.
Greetings
Nex
disclosure: i'm not an expert.
depends on what exactly you want to do.
if you want to build something from scratch, probably the easiest language to start prototyping is matlab/octave because it's high level and offers pretty fast matrix manipulations, nice math support (like numeric derivatives) and robust plotting to quickly verify your models. when you have your prototype, you can port to to c/c++ to make it faster, more space efficient, portable etc.
if you want to just use exiting tools/techniques and just play with parameters (preprocessing, feature selection etc) to find the best model for you, i would recommend start from R and caret package or python (don't remember the package name)
if you want to use NN in cluster on big data then i would try using existing frameworks like openCV (not sure if mahout provides NN)
Google just released their tensorflow framework.
Its perfect to start with and offers even for high skilled NN-architectures a lot of feautes. I highly recommend it for everyone.
I m doing a research project on "Object detection using my a digital camera".
Some suggestion on how to build and program the Matlab code.
In particular, I have a picture of one object, say a screen of my laptop. Than I rotate the laptop and I shot a new picture. I would like to know the difference on the position of the screen. I think I can use the edge detection after a subtraction of the two images but... it is quite difficult for me to implement it.
Some suggestion on how to build and program the matlab code.
That largely depends on the goal you want to achieve. Can you be more specific? Are you streaming the frames or are you tracking offline?
In particular, i have a picture of one object, say a screen of my laptop. Than i rotate the laptop and i shot a new picture. I would like to know the difference on the position of the screen.
There are many ways to do this, and an extensive litterature on the subject. I don't believe anyone would write up the equivalent of a survey paper on the subject as an answer on StackOverflow. Why don't you get started with an object tracking survey paper and then ask a more precise question?
hi, I m doing a reasearch project on "Object detection using my a digital camera". [...] I think i can use the edge detection after a subtraction of the two images but...is quite difficult for me to implement it.
What is your question? Are you asking us if this is a good way to track objects? Are you asking us if this is a new approach and has never been done? Are you asking someone to implement it for you?
Object tracking is a hard problem. I doubt that technique would succeed in any but the most basic scenarios. However, if you look at a survey paper, you might be pointed to a paper that already implemented this an presents results. Finally, I think you should brush up your programming skills because most (successful) object tracking techniques are not trivial to implement. If you don't want to program it yourself, there are online services where you can hire people. StackOverflow is not one of those places.
EDIT: I could deduce that you're new to both programming (in MATLAB) and in object tracking, hence in my answer. Don't mis-understand me, I'm trying to help. Let me re-phrase my suggestions as list:
Your question is far too general. You will get a lot more help from the SO community if you ask more precise questions for two reasons: A) general question result in general answers; and B) the way you asked your question could easily be interpreted as "someone, please do my work for me" even if that's not what you think you're asking.
Get acquainted with the problem domain. To ask more precise questions, you must be close to your answer. For good knowledge on the "object detection and tracking", find a good survey paper. If you're starting off on a research project, people in your lab should be of help to point you to a good one.
Learn to program simple things first. All of the most proficient (effective and efficient) programmers I've ever met struggled with the bubble sort when they were introduced to sorting. None of them would have been able to program an object detection algorithm as a first assignment. Get yourself a good image processing book that has exercises in MATLAB, go through execises one by one. If you can't do them all, choose those that are relevant to what you're trying to accomplish.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
To learn FPGA programming, I plan to code up a simple Neural Network in FPGA (since it's massively parallel; it's one of the few things where an FPGA implementation might have a chance of being faster than a CPU implementation).
Though I'm familiar with C programming (10+ years). I'm not so sure with FPGA development stuff. Can you provide a guided list of what I should do / learn / buy?
Thanks!
Necroposting, but for others like me that come across this question there is an in-depth, though old, treatment of implementing neural networks using FPGAs
It's been three years since I posted this, but it is still being viewed so I thought I'd add another two papers from last year I recently found.
The first talks about FPGA Acceleration of Convolutional Neural Networks. Nallatech performed the work. It's more marketing that an academic paper, but still an interesting read, and might be a jumping off point for someone interesting in experimenting. I am not connected to Nallatech in any way.
The second paper came out of the University of Birmingham, UK, written by Yufeng Hao. It presents A General Neural Network Hardware Architecture on FPGA.
Most attempts at building a 'literal' neural network on an FPGA hit the routing limits very quickly, you might get a few hundred cells before P&R pulls takes longer to finish than your problem is worth waiting for. Most of the research into NN & FPGA takes this approach, concentrating on a minimal 'node' implementation and suggesting scaling is now trivial.
The way to make a reasonably sized neural network actually work is to use the FPGA to build a dedicated neural-network number crunching machine. Get your initial node values in a memory chip, have a second memory chip for your next timestamp results, and a third area to store your connectivity weights. Pump the node values and connection data through using techniques to keep the memory buses saturated (order node loads by CAS line, read-ahead using pipelines). It will take a large number of passes over the previous dataset as you pair off weights with previous values, run them through DSP MAC units to evaluate the new node weights, then push out to the result memory area once all connections evaluated. Once you have a whole timestep finished, reverse the direction of flow so the next timestep writes back to the original storage area.
I want to point out a potential issue with implementing a Neural Network in FPGA. FPGAs have limited amount of routing resources. Unlike logic resources (flops, look-up tables, memories), routing resources are difficult to quantify. Maybe a simple Neural Network will work, but a "massively parallel" one with mesh interconnects might not.
I'd suggest starting with a simple core from OpenCores.org just to get familiar with FPGA flow, and then move on to prototyping a Neural Network. Downloading free Xilinx WebPack, which includes ISIM simulator, is a good start. Later on you can purchase a cheap dev. board with a small FPGA (e.g. Xilinx Spartan 3) to run your designs on.
A neural network may not be the best starting point for learning how to program an FPGA. I would initially try something simpler like a counter driving LEDs or a numeric display and build up from there. Sites that may be of use include:
http://www.fpga4fun.com/ - Excellent examples of simple projects and some boards.
http://opencores.org/ - Very useful reference code for many interfaces, etc...
You may also like to consider using a soft processor in the FPGA to help your transition from C to VHDL or Verilog. That would allow you to move small code modules from one to the other to see the differences in hardware. The choice of language is somewhat arbitrary - I code in VHDL (syntactically similar to ADA) most of the time, but some of my colleagues prefer Verilog (syntactically similar to C). We debate it once in a while but really it's personal choice.
As for the buyers / learners guide, you need:
Patience :) - The design cycle for FPGAs is significantly longer than for software due to the number of extra 'free parameters' in the build, so don't be surprised if it takes a while to get designs working exactly the way you want.
A development board - For learning, I would buy one from one of the three bigger FPGA vendors: Xilinx, Altera or Lattice. My preference is Xilinx at the moment but all three are good. For learning, don't buy one based on the higher-end parts - you don't need to when starting using FPGAs. For Xilinx, get one based on the Spartan series such as the SP601 (I have one myself). For Altera, buy a Cyclone one. The development boards will be significantly cheaper than those for the higher-end parts.
A programming cable - Most companies produce a USB programming cable with a special connector to program the devices on the board (often using JTAG). Some boards have the programming interface built in (such as the SP601 from Xilinx) so you don't need to spend extra money on it.
Build tools - There are many varieties of these but most of the big FPGA vendors provide a solution of their own. Bear in mind that the tools are only free for the smaller lower-performance FPGAs, for example the Xilinx ISE Webpack.
The software comprises stages with which you may not be familiar having come from the software world. The specifics of the tool flow are always changing, but any tool you use should be able to get from your code to your specific device. The last part of this design flow is normally provided by the FPGA vendor because it's hardware-specific and proprietary.
To give you a brief example, the software you need should take your VHDL and Verilog code and (this is the Xilinx version):
'Synthesise' it into constructs that match the building blocks available inside your particular FPGA.
'Translate & map' the design into the part.
'Place & route' the logic in the specific device so it meets your timing requirements (e.g. the clock speed you want the design to run at).
Regardless of what Charles Stewart says, Verilog is a fine place to start. It reminds me of C, just as VHDL reminds me of ADA. No one uses Occam in industry and it isn't common in universities.
For a Verilog book, I recommend these especially Verilog HDL. Verilog does parallel work trivially, unlike C.
To buy, get a relatively cheap Cyclone III eval board from [Altera] or Altera's 3 (e.g. this Cyclone III one with NIOS for $449 or this for $199) or Xilinx.
I'll give you yet a third recommendation: Use VHDL. Yes, on the surface it looks like ADA. While Verilog bears a passing resemblance to C. However, with Verilog you only get the types that come with it out of the box. With VHDL you can define your own new types which lets you program at a higher level (still RTL, of course). I'm pretty sure the Xilinx and Altera free tools support both VHDL and Verilog. "A Designers Guide to VHDL" by Ashenden is a good VHDL book.
VHDL has a standard fixed-point math package which can make NN implementation easier.
It's old, because I haven't thought much about FPGAs in nearly 20 years, and it uses a concurrent programming language that is rather obscure, but Page & Luk, 1991, Compiling Occam into FPGAs covers some crucial topics in a nice way, enough, I think, for your purposes. Two links for trying stuff out:
KRoC is an actively maintained, linux-based Occam compiler, which I know has an active user base.
Roger Peel has a logic synthesis page that has some documentation of his linux-based workflow from Occam code synthesis through to FPGA I/O.
Occam->FPGA isn't where the action is, but it may be a much better place to start than, say, Verilog.
I would recommend looking into xilinx high-level synthesis, especially if you are coming from a C background. It abstracts away the technical details in using a hdl so the designer can focus on the algorithmic implementation.
The are restriction in the type of C code you can write. For example, you can't use dynamically sized data structures, as that would infer dynamically sized hardware.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have come upon another class where I need to find an idea for a project, and since my last posting on SO for a project idea was so successful, I've decided to ask here again.
I'm taking a class titled Computer Vision for Human-Computer Interaction, and we need to come up with a few ideas for a project that we will have about 2-4 weeks to complete. We have the option of working with 1 or 2 other people, although I will probably be going solo on mine.
In the class we've covered things like image formation, image features, segmentation, shape analysis, object tracking, motion calculation, and some applications. Our homework assignments have been completed in Matlab for convenience, although its not required for use in our project.
I have come up with few possibilities: tracking the motion of a golf club and ball in full swing and doing some analysis, or possibly using eigenface techniques to do some sort of facial recognition and matching.
I would enjoy building an application that I can put on the web for others to play around with, but most of all I want to complete a project that could be of good use to someone (whether for entertainment or more useful purposes).
So... any ideas? Thanks!
Its fun and challenging to go from static image processing to doing analysis in real-time. For example, analyze video from a webcam and have the user play a primitive video game by waving their hands.
Or, if you want to continue with your face recognition idea, try writing software to highlight famous faces in a running video in realtime.
Use google image search to gather training data and then see how well your software can do at identifying the president of the US in different settings , for example. Can you train all of the former presidential candidates and differentiate them all?
Also, look into using OpenCV for fast real time computer vision processing in C.
Take a look at these for examples:
http://en.wikipedia.org/wiki/Category:Applications_of_computer_vision
http://www.cs.ubc.ca/~lowe/vision.html
There are some funky projects in this ongoing course:
http://www.seas.upenn.edu/~cis581/
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
This is marked as a subjective question, I hope I won't get too many down votes though.
LV seems to offer a nice graphic alternative to traditional text based programming. As I understand, it's not a just-virtualization/data acquisition programming language. Nonetheless, it seems to have that paradigm pegged to its creator's name.
My question comes up because it doesn't seem to be widely used for multi-purpose applications. I'm not a LV-expert of any kind, I'm more like a learner. I'm still getting used to LV.
Labview is fantastic if you have National Instruments hardware, and want to do something like acquire, plot and log the data.
When you start interfacing to custom devices the wiring between modules gets complicated having to do all the string manipulation work for input and output to a device.
At my place of work, we found that we got annoyed with having to make massive, complicated VI's to interface to devices and started writing them in .NET and interfacing them to Labview.
In the end we ended up scrapping Labview all together and using the NI Measurement Studio for Visual Studio to give us all the lovely looking NI controls (waveform plot, tank, gauges, switches etc) with the flexibility of C#.
In summary, even with a couple of 24" screens, sometimes the wiring for Labview code can get too complex and becomes impossible to comment, debug, and make extensible for any future changes. I suggest taking a look at Measurement Studio for Visual Studio and using your favourite .NET language with the pretty NI controls.
My two experiences with "graphic alternative[s] to traditional text based programming" have been dreadful. I find such languages to be slow to use, hard to edit, and inexpressive. Debugging them is a nightmare. And they offer no real advantages.
To be sure, it has been quite a long time since I looked at one, but the opinions of others I've asked about them have been only luke warm, so I have never taken the time to look again. Reasons to look again are welcome and will be taken on board...
Labview can be used to author large, complex software projects. Labview is unquestionably much more fun to use than a syntax based language. I have programmed mathematically dense, dynamic simulations using labview. Newer versions of Labview include alot of exciting features, especially for utilizing multiple processors. I like Labview very much. But I don't recommend it to anyone.
Unfortunately, it's an absolute nightmare for anything other than simple acquisition and display. It may one day be sufficiently developed to be considered as a viable alternative to text based languages. However, the developers at NI have consistently opted to ignore the three fundamental problems that plague labview.
1) It is unstable and riddled with bugs. There are thousands of bugs that have been posted to the labview support forums that are yet to be fixed. Some of these are quite serious, such as memory leaks, or mathematical errors in basic functions.
2) The documentation is atrocious. More often than not, when you look for help with a labview function in the local help file you'll find a sentence that merely restates the name of the item you are trying to find some detail on. e.g. A user looks up the help file on the texture filter mode setting and the only thing written in the help file is "Texture Filter Mode- selects the mode used for texture filtering." Gee, thanks. That clears things right up, doesn't it? The problem goes much deeper in that; quite often, when you ask a technical representative from national instruments to provide critical details about labview functionality or the specific behavior of mathematical functions, they simply don't know how the functions in their own library work. This may sound like an exaggeration, but trust me, it's not.
3) While it's not impossible to keep graphical code clean and well documented, Labview is designed to make these tasks both difficult and inefficient. In order to keep your code from becoming a tangled, confusing mess, you must routinely (every few operations) employ structures like clusters, and sub-vis and giant type defined controls (which can stretch over multiple screens in a large project). These structures eat memory and destroy performance by forcing labview to make multiple copies of data in memory and perform gratuitous operations- all for the sake of keeping the graphical diagram from looking like rainbow colored spaghetti with no comments or text anywhere in sight. Programming in labview is like playing pictionary with the devil. Imagine your giant software project written as a wall sized flowchart with no words on it at all. Now imagine that all the lines cross each other a thousand times so that tracing the data flow is completely impossible. You have just envisioned the most natural and most efficient way to program in labview.
Labview is cool. Labview is getting better with each new release. If National Instruments keeps improving it, it will be great one day as a general programming language. Right now, it's an extremely bad choice as a software development platform for large or logically complex projects.
I **have been writing in LabVIEW for almost 20 years now. I develop automated test systems. I have developed, RF, Vison, high speed digital and many different flavors of mixed signal test systems. I was a "C" programmer before I switched to LabVIEW.
It's true that you can build some programs quickly in LabVIEW, but just like any other language it takes a lot of training to learn to build a large application that is clean easy to maintain with reusable code. In 20 years I have never had a LabVIEW bug stop me from finishing a project.
Back in the day, NIWEEK would have a software shootout every year. LabVIEW and LabWINDOWS (NI's version of "C") programmers would both be given the same problem and have a race to see which group finished first. Each and every year all the LabVIEW programmers were done way before the 1st LabWINDOWs person finished. I have challenged many of my dedicated text based programming friends to shootouts and they all admit they don't stand a chance, even if I let them define the software problem.
So, I feel LabVIEW is a great programming tool. It's definitely the way to go if you’re interfacing with any type of NI hardware. It's not the answer for everything but I’m sure there are many people not using it just because they don’t consider LabVIEW a “real programming language”. After all, we just wire a bunch of blocks together right? I do find it funny how many text based programmers snub there noses at it as they are so proud of the mess of text code they have created that only they can understand. A good programmer in any language should write code that others can easily read. Writing overly complex code that is impossible to follow does not make the programmer a genius. It means the programmer is a “compliator”(someone who can take a simple problem and complicate it). I believe in the KISS principle (KEEP IT SIMPLE STUPID).
Anyway, there’s my two cents worth!**
I thought LabVIEW was a dream for FPGA programming. Independent executable blocks just... work. In general, I use LabVIEW for various tasks interfacing with my DAQ and FPGA hardware, but that's about it. It seems (again to me) that this is LabVIEW's strong point and the reason it was built, but outside that arena it feels "cumbersome." As far as getting things done, it's like any other language with a learning curve - once you figure it out it's not too bad for getting work done. I've seen several people give up before that thinking the learning curve was permanent or something.
Picking up a 30" monitor made a huge difference.
I know one thing that people dislike is the version control integration.
Edit: LabVIEW/hardware is hella expensive for "just for fun" use. I dropped $10K on their hardware (student prices) and got the software for free from school for making toys around the house.
Our company is using LabVIEW for the last 10 years for measuring, monitoring and reporting of our subject (trains).
Recently we have started using LabVIEW as GUI for databases with lots of data, the powers of LabVIEW with the recent new features (Classes, XControls) allows use to create these kinds of GUIs for a fraction of development costs at other platforms. While we don't need external programmers at consultancy rate.
Ton
I first started using Labview in a college physics lab. Initially, I thought it was slow and cumbersome when compared to other text-based languages. It was too difficult to create complex logic and code became sloppy real fast (wires everywhere).
Then, a few years later, I learned about using sub-vi's and bundles. What a difference! At this point, I was using labview for very high level functions. I was taking raw input from a camera, using all kinds of image filters and processing to ultimately parse out the lines in a road so that a vehicle could drive itself down this road with no driver - it was for the DARPA URBAN CHALLENGE. I was also generating maps from text waypoint data, making high-level parsing functions, and a slew of other applications that had nothing to do with processing data from input devices. It was really a lot of fun. and FAST.
After leaving college, I am now back to using text-based languages. I've been using: PHP, Javascript, VBA, C#, VBscript, VB.net, Matlab, Epson RC+, Codeigniter, various API's, and I'm sure some others. I often get very frustrated in the amount of syntax I have to memorize in order to program with any significant speed. I find it annoying to have to switch schools of thought based on the language I am using... when all programming languages essentially do the same thing! I need a second monitor just to have the help up at all times so i can find the syntax for the same functions in different languages. I miss Labview very much, it's too bad it's so expensive otherwise I would use it for everything.
Graphical based programming I think has a huge potential. By not being constrained by syntax, you can focus on logic instead of code. Labview itself may still be in its infancy in terms of support and debugging, but I believe conceptually it beats out the competition. It's simple a more intuitive way to program.
We use LabVIEW for running our end of line test equipment and it is ideal for data acquisition and control. Typically measuring 15 to 80 differential voltages and controlling environmental chambers, mass flow controllers and various serial devices LabVIEW is more than capable.
Interfacing with custom devices can be simplified greatly by using the NI instrument driver wizard to create reusable VI's, interfacing with custom dll's if needed. On a number of projects we have created such drivers for custom hardware and once created there are reusable in future projects with no modification.
Using event driven structures user interfaces are responsive and we regularly use LabVIEW applications to interface with a database.
Whatever programming environment you choose it's the process of designing the application that matters most. I agree that you can create some really horrible and unreadable block diagrams in LabVIEW but then you can also create unreadable code in Visual studio. With just a little thought and planning a LabVIEW block diagram can be made to fit on a single 24" monitor with plenty of space to add comments.
I would use LabVIEW over Visual Studio for most projects.
But people do use LabView for purposes other than data acquisition and virtualization. Of course LabVIEW is mainly used in labs and production environments because it is (or was) one of the main NI's customer target.
However you can do a lots of various things with LabVIEW, like programming a robot that would perform a lot of image analysis, and then tweet the results. Have a look at videos from NI Week 2009 on you-tube, and you'll see how powerful this tool is. For instance, there is possibility to write code and deploy it to ARM MCUs (see this Dev Monkey article from 2009.08.10).
And finally check this LabVIEW DIY group
I have been using LabVIEW for about two years for developing automation. If given due care and proper design we sure can develop maintainable and really good looking application in LabVIEW.I think this is the same for all the other languages out there. I have seen equally bad code in LabVIEW primarily from people who use it only to develop quick and dirty working automation. IMHO Graphical programming is a lot easier to code and understand if rightly done. But that said I feel text based programming 'feels' more powerful!
LabVIEW is primarily marketed for industrial automation, has inherent support for lot of NI hardware and you can get the third party hardwares working with it pretty quickly. I think that is the reason you see it only in automation field. Moreover it is pretty costly and you are locked down with NI as you do cannot even open your code if you do not buy the software from them!
I've been thinking about this question for decades (yes, since 1989...)
Like all programming languages, LabVIEW is a high-level tool used to manipulate the flow of electrons. Unless you are a purist and refuse to use anything other than a breadboard and wires; transistors, integrated circuits and programming languages are probably a good thing if you wish to build something of any consequence.
But like all high-level tools, just wielding one does not make you a professional craftsman. Back in the day of soldering irons, op-amps and UARTs it required a large amount of careful study before you could create a system that actually functioned. The modern realm of text-based languages is so overly dominated by syntax that the programmer must get it just right before it will compile and run. In order to write code that works, the programmer must increase their skill level to create systems much larger than "Hello World".
LabVIEW is not dominated by syntax, but by Data Flow. Back in the day, reaching for your flow charting template and developing the diagram of a well-balanced information system was the art and beauty part of the job. Only after you had the reviewed flowchart in hand would you even consider slogging through the drudgery of punching out the code. (yes... punch cards)
LabVIEW is a development system that allows the programmer to use flow charting tools to diagram the complete information system and press "run"..... LabVIEW "punches out the code" and compiles it for you. No need to fight through the syntax of text language A or language B.
With such a powerful tool, novices can build large, working programs rapidly -- implying some level of professional craftsmanship since it runs at all. However, if the system does not perform elegantly, or the source code diagram is a mess, it is not the fault of LabVIEW.
People often point to "LabVIEW is only good for developing large data acquisition systems." Perhaps those people should consider the professionalism of the scientists and engineers that are working in data acquisition. If they know enough to get the actual wires right for the sensors and transducers, it may be a good bet that they are expert at developing LabVIEW wiring diagrams as well.
I do use LabView at home, as it is part of Lego Mindstorms, which my son loves. And I really like the way to compose systems like this.
However, in my work (embedded systems), it is generally to restrictive. But also here, I'm trying to move up in abstraction:
- control and state behavior: Model based design (i.e. Rhapsody)
- data algorithms etc. Simulink
Sometimes a graphical model can require more clicks than a piece of code. But this also includes the work a good programmer need to do in design & documentation; not just the code typing. The graphical notation takes many hassles away and is generally much faster if the tool is powerful enough for the complexity at hand. So I expect these kinds of tools will gain more popularity in the next years as they mature and people get familiar with them.
I have used LabView for some 10 years. It's brilliant for Scientific prorgamming ie like Matlab or Simulink but 10 times better. If you are having problems then you are doing something wrong. It takes time to learn like any language. As for using .Net instead - are these people even on the same planet? Why would you go to the trouble of writing eveything from scratch when you can say pull up an FFT etc and use alread written code. .NET is fine for simple programs but not so good for Scientific processing. yes you can do it but not without oodles of add-ons for graphics etc. Prorgamming in G is far easier than text based for Scientific problems. You can of course program in c if you are interfacing and use the dll. Now there are things that I would not use LabView for - speech recognition for example may be a bit messy at present. More to the point though, why do people like programming in outdated text form when there is an easy alternative. It is as if people want to make things complicated so as to justify their job in some way. Simplify Simplify!
Somebody said that LabView is only sued in the Automation field. Simply not write at all. It has applications in Digital Signal Processing,Control Systems,Communications, Web Based,Mathematics,Image Processing and so on. It started as a data aquisition method and they invented the name Virtual Instrumentation but it has gone far beyond that now. It is a Scientific programming language with a second to none graphical interface. It is way beyond Simulink and if you like Matlab then it has a type of Matlab scripting built in for those that like such ways of programming. It is evolving all the time. The one thing I found difficult was writing code for the Compact Rio - tricky but far easier than the alternative. It's expensive but you get a quality product. I personally have not found any bugs in ordinary programming. It is an engineers language but anybody could use it to program.