NI products versus other products - your experience?

[jimmyinCT]

I can honestly say, i think NI has some problems.  Alot of people dont really know what is going on with the language in comparison to other languages, includes people at NI as it is a difficult to learn the foundations.. People see this and are discouraged.  Example. I have 4 user names and name aliases and call up for upport under the same topic and often get 4 different answers.  Its very troubling.  Its the same thing with the sales people as they sometimes sell the wrong tools for the job..  The group im currently working was sold a $10,000  fpga w/ modules (hard to program) from the ni sales rep having never done NI programming and they didnt even didnt need embedded control for the task they were consulted on. Needless to say, the group has adapted an anti NI attitude as the project has taken far to long as cost to much money.    

  Yea, am I still learning new stuff with NI, yes, almost every day, especially with new products new to me such as the crio but its not really even that relevant here..  Very few people can do matlab, c++, vb, hardcore electronics, nor for as long as i have, so i figured i just give you some thoughts.   I think there is alot of room for improvements in the way the language works that would help it be taught and debugged, such as ways of changing the IDE. I was going to give you some sincere recommendations today, but not now. good luck.  

Message Edited by jimmyinCT on 10-02-2009 09:02 AM

[LV_Pro]

1. What is your experience? and
2. Why did you decide to use NI products or not to use NI products for your application(s)? (if the case)
3. Have you used sometimes NI products and sometimes other company's products for your or customer's applications? What made you select one over another?

I'm not sure what you mean by #1, but my experience is 25+ years in the test, measurement and controls world, using a variety of software and hardware.

#2. As Stu put it, there is a design tree, which is sometimes driven by customer preferences, sometime just by the engineering aspects. If it is a critical system, where a glitch can put expensive equipment at risk, or much more importantly, put a person at risk, then using a PC as the primary control wouldn't be a good idea, regardless of the software used. If the requirement has high data acquistion, then a PLC isn't a good choice. Etc. Now for much of my work NI makes appropriate hardware (they have "stuff" that doesn't depend on Microsoft's glitchy OS's, so more of that is showing up in my "critical application" proposals), and while other companies make good DAQ hardware, the integration of the hardware with my software is much easier with NI. Measurement and Automation Explorer is one case in point, works with NI stuff, notwith others, has allowed me to troubleshoot hardware hookups without any of my code running, saving me a lot of time and $.  As to the discussion regarding the cost of LabVIEW, etc., well check out what Allen-Bradley/Rockwell charge for their software, look at what a SCADA package such as Wonderware or Intellution IFix costs. Price a AB usb-RS485 adapter...

#3 Sometimes I have used a mix of NI and non-NI hardware, where there was some capability not available in the NI catalog, or where the difference in price might be a deal breaker. But, if the idea is to use LabVIEW and non-NI hardware, tred with caution. I have been burned when a vendor claims that they have LabVIEW drivers for their piece of hardware. All too often the LabVIEW vi's they supply look to have been written by the engineering intern student they had that summer, where they threw a copy of LabVIEW on "his" desk and said "your project is to create some LabVIEW vi's for our product". Ouch.

As too LabVIEW speed versus programs written in other languages, well in development speed I find it can't be beaten, in actually execution speed, there are many ways to make your LabVIEW code run really slowly, but I have a number of programs out there that are running pretty complex, pretty high speed tasks.

[RPJ]

Gentlemen,

I was away for a while and now I am back. I would like to thank you for your answers, some of which I have awarded kudos.

A 'quick' question for Putnam: how long have you been working in this field and how long did it really take you to reach this level?

When you come from a different environment (like I do), things are not so easy to envision / understand - therefore my question on this forum.

So far the reply and comments have demonstrated that the programmer / engineer fellowship is alive and well. 

I look forward to receving more opinions.

Thank you.

[LV_Pro]

Sorry for the delay in answering you. I have been in the test, measurement and controls world for 25+ years, started using LabVIEW with version 2.5 in the fall of 1992, when it was first released on the Windows (3.1) O/S. Prior to that I had programmed test systems in a variety of languages, and actually continued to do so for a while longer. Those languages were traditional "text based" languages including Pascal, C, Atlas (similar to Fortran for the test world) and HP Basic. I also developed "test vectors" which were tables of input stimulus and expected output results, using VHDL or Verilog, to be run on commercial digital testers to test the digital boards the company I worked for manufactured. Since 1996 I have been consulting, predominently in the LabVIEW environment, helping a number of companies build test systems for their products. Some of these customers had existing LabVIEW programmers, so I was just augmenting their staff, or supply some specialized knowledge, others have been customers that recognized the need to automate testing of their product, but didn't have the inhouse skill set. It takes a while to become skilled in any field, and while the sales folks at NI tend to sell LabVIEW as "so easy a caveman"... wait that is Geico's ad, LabVIEW is a feature rich language, with its own quirks and techniques. I know that my head hurt when I first started using it, the structure was so different, I had a hard time visualizing the structure of my code, something that wasn't a problem with the other languages I regularly worked in. Now I occasionally dream in LabVIEW when I have a tough problem that isn't coming easily to me!