NI products versus other products - your experience?

[RPJ]

To all users of NI products:

For automation in industry (for example monitoring and controlling of various equipment), usually people prefer PLCs, daq cards, and other electronics that are not NI. They feel comfortable controlling these cards and programming their applications using "classical" programming languages such as Visual Basic, Visual C++ or C#. When I ask them why, they mention that it is due to either "too often upgrades" of the NI software, or the cost of equipment and software and its maintenance, or the difficulty to adapt to a new programming environment (I almost feel they have a lack of trust in NI software when they say that).

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 appreciate your time to read and answer.
I would also appreciate not making this a thread that will tell how good and great is LabVIEW and how you can do anything with it. We know this already...;-)

Thank you.

[aeastet]

I work in a testing lab that is responsible for design validation for the products that we design. We have many different applications for controls. We have cycling amchines that move parts hundreds of thousands of times over the period of the test. We have an airbag facility and many federal goverment crash testing evaluation pieces of equipment. We have pressure testers, leak testers, environmental chambers loading fixtures torque testing amchines ect...

I my case I use a few different systems. If I am building a cycling fixture we use a PLC. It is reliable runs forever with out fear of shutdown or opreating system failure. I can replace a PLC very quickly and reload the software and be running again in very little time. The cost for the development software is minimal compaired to LabVIEW. If I am not doing data acquisition then a PLC is the best method for this.

When I am do data acquisition I will use a PC front end and a PLC for safety (interlocks, position monitoring, Light gates etc..). If the computer goes down I can not afford to get someone killed because the PC did not see the light curtain chage states.

There are times when LabVIEW cannot do what I need it to do effeciently. These time I code C++ and make a dll to interface to LabVIEW.

All in all I do not believe that there is one solution that can do everything.

[F._Schubert]

Although none of us engeneers and similar professionals would state it, we actually base these decisions on unsientific symathies. You would never try to make someone to use LV if he/she is biased against it. Even if they use some ancient BASIC they will make better software if they like it. It's all about the motivation, it makes this forum great and rants/prejeduce against LV somewhere else.

On the hardware side, I'm a big fan of NI's M-Series DAQ. They have a very good ADC. If you take the high precision things, you have 18-bis at 625 kS/s for little over 2k €. I'm not aware of any product that can meet these specs. But for DMMs another brand is already well established and we won't do a lot of code changes to fit in the NI DMMs, so I never compared the specs in this field (you see, it is not based on sientific data). In addition there are fields we don't find the hardware on the market, so we need to develop that stuff on our own.

So let me go deeper into the advantages of the DAQ. I have a broad range of hardware (high precision vs. low cost vs. high speed, as well as PCI vs USB) that works with the same code (rare exeptions, such as that analog triggering doesn't work with low-cost). So I save a lot of time (learn the syntax/device driver, implement/code it, test it, integrate it ...).

This implies that I really know my DAQ very well, which makes it multi-purpose. This is the reallity of what the marketing people allways talk about as 'virtual instruments' or 'modular instruments'. If I have a DAQ in my ATE and I need to monitor some kind of signal and do some analysis, well that is a really easy job: do some wires and throw some express vi's together and end up with a FFT analysis in 10 min.

Well, this advantage really goes for like DAQ + like LV + has a lot of time/applications with both.

Felix

[RPJ]

I would like to thank those who answered so far.

Unfortunately, I have very little experience with PLCs and I am more familiar with daq cards and cDAQ and cRIO. Knowing very well there is no solution that can do everything, I am trying to determine what else I should take into consideration when looking at machine or equpment monitoring solutions. PLCs or PMCs and a 'deployable' software that can be installed on a PC or on the PLC itself?

The customer will always want something cheap but the producer will have to make sure it has enough 'platform' to implement what the customer wants.

Now if I want to use something else than daq cards and cDAQ and cRIO where should I start (at least learning and looking)?

Thank you.

[aeastet]

If you want to learn PLC programming. It should be easy compaired to LabVIEW because it has so many limitations. You will find it a little more frustrating than LabVIEW if you are like me. I have considered for a few years now developing a module in Labview that I can drag nad drop PLC code and then push a button and program a PLC. If you want to learn this most manufacturers have class that you can attend. Some of the software can be expensive (Allen BradleyMin $2500 and up) and some is moderate Mitsubitishi ($900 got me everything). PLC's are great for non data acquisition systems. They can control and keep up with things but are poor at math and data acquisition.

We have done high breads with a PC to PLC interface to save mone on the control side while sitll getting the advantage of the math and data logging. Getting a consultant that is very good at what he does would be what I would recommend to see your possibilites. This is not a job request I have a full time job. I am just suggesting that when I want to see something new I hire someone that has some experience and learn from them. But you can alsways take calsses. That is the easiest way for you to be that person.

[RTSLVU]

While my experience is a bit limited...

For GPIB, it is worth buying NI cards or USB-GPIB devices because of the extra little hoops you have to jump through to get other brands of GPIB cards working in LabView.

For DIO/DAQ devices I prefer Measurement Computing USB devices because they are cheaper and have drop-in VI's and do not have to be treated as a DAQ like NI devices.

For analog measurements I prefer the Agilent 34970A because the cost per channel ratio is far less than any NI solution.

[jimmyinCT]

The problems is that in my honest opinion, in a huge amount of applications I did or was following, NI limits the speed of application to the point where it has no value.   This is not just my opinion, this is something you hear over and over when people complain about NI.

 On many occasions, ive gone through and recoded projects made in labview in other languages (ie vc++, vb, matlab)  and typically get factors of 1000x improvement in execution speed.   On the other hand rather than recording.. Ive put in dedicated hardware, plcs (specificaly PICs) or electronics, etc, so that the project seems functional and responsive. 

 Before you go and jump on me saying i dont know what im doing in defense, ill say ive put in my time, almost 15 years now in labview.     I put in many calls to NI tech support when im unsure or looking for hints to speed up the program and often time find it of little use.  Its takes just days to recode projects and they work without limitation where as you can waste weeks trying to figure out how to get more speed to no avail.  

I better not say to much though or I wont get any more answers when i post on this user forum  🙂

Message Edited by jimmyinCT on 10-01-2009 02:11 PM

[hecmar.arreola]

Hi Jimmy.  I would have to agree with your stance to a large degree.

I've always looked at LabVIEW as a RAD (Rapid Application Development) environment language.  There seems to always be a speed problem with RAD type languages.  I do not know the technical details, but most of my applications do not require super fast response.  For me, being able to code something in the time frame of an afternoon as oppose to the time frame of a week or more is what makes LabVIEW worthwhile to me.  Time is money.  My buisness is client driven, and reducing development costs is key to our success.

NI hardware is also super ideal for my work environment.  Their multifunctional DAQ devices have everything I need for solid test systems.

My problem with my personal LabVIEW coding when compared to other languages:

1. My LabVIEW always turns into speghetti code.  I'm getting better... but the UI keeps growing and growing as my users want more and more.

2. Documentation of LabVIEW code is always a struggle for me.  When I did my work in text based languages there was a comment on every line about what was going on and why I was doing what I was doing with the piece of code.  I can add text to a LabVIEW block diagram, but then I hit the "clean up diagram" button and everything gets shuffled.

[JÞB]

OK I'll bite,

Circuit Check inc. provides automated testers to a variety of electronics manufacturers (I won't advertize here) but I have a bit of experience in test system design.  

I use the best solution for each customer.  What this means is fitting cost, size, ease of automation, scalability, software incorporation, and test requirements  into one neat package- that is maintainable! 

NI support for hardware and software is easily the class of the T&M industry.  Agilent comes in a distant second (no 24/7support) and then Tectronix.  No supprises.  I frequently sell the customer on support at a premium and they'll usually pay.

Some of our customers specify the software development enviorment for internal reasons.  We ship VB.net, LabWindows/CVI and LabVIEW generated code (or integrate third party applications if so desired) but the software trade-off boil down to; cost (VB.Net is free, NI charges) driver availbility (SDK's are common for many equipments and apps.  LabVIEW drivers are all over the place).   Code development time (I burn through LabVIEW- I have two coworkers that can type VB.net faster than I can read it so it's pretty much a wash.)  Code reusability is pretty much a wash to if you develop good software.

So the answer usually does come down to what the customer can read and support.  Frankly, the need to keep fluent in the many NI versions is a deterent (I have 1 customer with LV6.1 source in a Teststand2.0 enviornment) You can imagine my reuse library is pretty extensive and there are tricks that only work forward and opportunities to improve code that are missed to maintain consistancy.  

Hardware is a different matter- NI DAQmx, DC supplies and DAUs I'll offer either Agilent or Keithley - if both meet the need I'll sell the lower cost.  I'm still up in the air on RF- but the new PXI RF from NI is looking pretty cost effective and may get me away from the Agilent equipment below 5GHz- above that Agilent all the way.

For monitor and control of indusrtial equipment its a free-for-all!  the questions are how its distributed (wi-fi, ZigBee, Ethernet, Fiber) and how you store it.  There are a LOT of solutions and the cost is calculated in purchase price, infastructure demands, projectable upgrades, and maintainence.

[JÞB]

---

Nickerbocker wrote:

My problem with my personal LabVIEW coding when compared to other languages:

1. My LabVIEW always turns into speghetti code.  I'm getting better... but the UI keeps growing and growing as my users want more and more.

2. Documentation of LabVIEW code is always a struggle for me.  When I did my work in text based languages there was a comment on every line about what was going on and why I was doing what I was doing with the piece of code.  I can add text to a LabVIEW block diagram, but then I hit the "clean up diagram" button and everything gets shuffled.

---

Here's a tip to avoid that issue.

Start each vi by first editing the .txt document attached and pasting it into the vi documentation.  Open and lock the description next to your untitled vi and add the controls and indicators (make sure you add tips and descriptions).  Create an icon then Save the vi by name and put it in source control.  (right then other developers can grab it and plug it in to their effort as shell code. When you release the working version source control will deploy the final working code)

Remeber- if it takes more than two paragraphs to write the vi functional description you need to rethink the project structure!