NI products versus other products - your experience?

[GuenterMueller]

Well prepared documentation, Jeff.
How about going one step further and creating a VI template (*.vit) with this description. No copy and paste needs to be done. And no searching for the text file must be done. As soon as the .vit exists, you just select in LabVIEW "File>>New ..." and select your template.

Regards, Guenter

[AnalogKid2DigitalMan]

Ironically, I came across this article in my printed version of Control Engineering. Controls range from PLC's NI FPGA, DCS, relays.

http://www.controleng.com/article/339856-How_to_Choose_a_Controller.php

Personally, it has been primarily LabVIEW, a perverted form of basic for SmartMotor programming, and off-the-shelf PID and motor controls for my current job.

-AK2DM

[jimmyinCT]

 I already mentioned my main issue with NI already, which is speed.

This is really what is killing it from becoming bigger. Fix it. 

Im not even going to mention other issues as they pale in comparison to this.  

Id like to answer you question from another way of thinking about it.

People use software that they are most comfortable with and try to stick with it. 

NI is competing with software giants like microsoft and even mathworks now.

Microsoft gives away their full development engineering software for college studetns on MSDN.

Here is a list of free full versions at  uconn.

http://msdn01.e-academy.com/elms/Storefront/Storefront.aspx?campus=uconnect_cmbe&np1=112

The license granted allows students to have it for home use and to use it after they graduate. 

Its the same thing, we get greats deals on PICs microcontroller that are basically given to us.

Even matlab lets us incorporate drivers into the hardware now, and no, we dont pay for that functionality either. 

 Students can buy the full matlab version at the bookstore, has all the functionality (as of last year) that the full version does, for $100 or so.

You need to get the young guys started, its really them who do most of the low level work after they graduate.

 

Well, you can see what im leading into..

Well, give labview software away to students...

Offer ways or incentives for students to get labview certified in college for college credit..

I admit i discourage people and students from using NI

Ill write more ideas later if anyone is interested, especially if kudos are still being given..

Message Edited by jimmyinCT on 10-01-2009 08:43 PM

[srm@viewpointusa.com]

jimmyinCT

I have responded to your posts before and looked at some of your code.  I thought you were a college student just learning LabVIEW as opposed to 15 year exp.

I can say that we create some VERY high performance applications in LabVIEW under Windows, RT and FPGA.  LabVIEW is rarely the bottleneck.  However, I will admit that to get to this level takes a long time and a thorough understanding of basic principals.  It is one thing to get code to function and another to function at rate.

It has been our experience to date that these criticisms of LabVIEW have more to do with the programmer than LabVIEW itself.  That said, it is too easy to get code working in LabVIEW that will NEVER be able to meet adequate rate specifications.  Yours being a case in point.

I also lay some of the blame with NI. The message from NI is always "look how easy it is".  This certainly sets up a level of expecation and when that expectation is not met, disappointment results.  I think NI should have more quality examples that show good performance on non-trivial problems to help guide the way.

Stu

[rolfk]

---

jimmyinCT wrote:

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

---

Well you said not to jump on you so I go easy on you

I have really never had anything where LabVIEW itself was inherently to slow to do the task. If you employ the right architecture and use the right algorithme then LabVIEW can and will be just about as fast as you can be when doing the same in C. LabVIEW won't optimize on machine code level yes, but that usually amounts to percents of speed gain, not factors.

The problem with slow LabVIEW programs is the fact that it is so easy to do them at all in LabVIEW, by people who can't or don't want to think about the architecture of their code and algorithmes. That is not the fault of LabVIEW but it's strength that makes it a nice tool for RAD applications. But that does by no means imply that you can NOT use proper software design and architecture methods in LabVIEW too. Yes once you do that it is not RAD anymore but hey you can't blame the tool to allow you to write bad code, if the tool allows you to write good code too. I've seen terrible C(++) code too, but there you have to really understand a lot more about programming before you are able to even do the most simple program, so usually people writing C(++) have a fairly good base in software development and are therefore much more likely to employ at least some basic software design methods before starting to hack away.

Software development can be an art in some ways and one that can be learned. But it does not come magically not even through such a great tool as LabVIEW.

If you have trouble to get decent speed out of LabVIEW, then you are either someone coming from sequenctial text programming, who has not yet grasped the dataflow concept, or you are someone who does not employ any software design methods and will have the same speed problems in every single programming language out there. There is nothing else!

Rolf Kalbermatter

Message Edited by rolfk on 10-02-2009 09:26 AM

[rolfk]

---

AnalogKid2DigitalMan wrote:

Ironically, I came across this article in my printed version of Control Engineering. Controls range from PLC's NI FPGA, DCS, relays.

http://www.controleng.com/article/339856-How_to_Choose_a_Controller.php

Personally, it has been primarily LabVIEW, a perverted form of basic for SmartMotor programming, and off-the-shelf PID and motor controls for my current job.

-AK2DM

---

Ahhh, those Smart Motors! Smart idea, technically sound, but their software!

Rolf Kalbermatter

[RPJ]

Gentlemen,

I would appreciate focusing on the question. I will give kudos to any coment that answers the question (which, however, I have to admit it's a little vague). I do not want this to become a 'critique' of NI and LabVIEW.

Let's step back for a moment and try to look at the question from this perspective (which is not really my case but I think could lead you to the answer I am looking for): let's say you want to start a company and your idea is to sell "automation" - monitoring, daq, adaptive control. You know you will have to read data / signals from various machine controls (such as Fanuc, Allen Bradley, Okuma, Siemens, Mazak etc) and from external sensors (accelerometers, thermocouples, maybe cameras) etc. and then do some data processing real-time, control the ecquipment you are monitoring etc.

Now, here is the 'problem' you are familiar with NI and LabVIEW but you also know you could save time and money and possible integrate simpler, faster solutions using simple PLCs or microcontrollers, or other type of equipment that is more modular and simple in comparison with NI. Nevertheless, using the other options, would require learning or knowledge of other programing languages or software etc.

Wel...what to do, stick with LabVIEW and NI only? If not, what else would worth investigating? What is your experience with various types of monitoring, acqusition and control electronics and software?

The first 4 or 5 answers were good and I gave kudos. However, the conversation tends to spin out of target and I would not encourage that to happen.

Thank you for taking the time to read my post/question and share your opinions.

[srm@viewpointusa.com]

Sorry RPJ for the diversion.

To give you my spin on your question.  I think understand your question and we do this kind of work all the time.

Automation is a very large topic. The decision tree for us starts with "how critical is the application". 

are there safety issues involved?

are there protection of product involved?

if it is a simple, benign application, a PC based LabView application will suffice.

if it is a critical application, critical functions should be implemented and interlocked with industrial solutions such as Siemens PLC.

Next question is what role your application?  custom instrumentation/measurement(DAQ, Vision etc)?  supervisory and control?

If you are an enabling piece of the puzzle, you should interface to the PLC as a slave in it's native environment using something like Profibus.

If you are supervisory, connecting to the PLC with OPC.

What you don't want to happen is to damage a $100k piece of equipment or product and have to explain that you had a big or hickup with your labVIEW application.

[Ben]

I have been impressed with NI's support and will often lean toward an NI solution.

Support after the sale is very important to me. I am not saying the NI support is by itself the best there ever was (that was DEC where a freight train would rool with a new mainframe if we did not get yours running fast enough).

But NI's support can "be worked" to acheive what I need.

Where NI breaks down is when we ASSUME NI will recognize the severity of an issue and let them ignore a problem.

The other place NI breaks down (dove-tailing with some rants above) is that MOST NI people don't recognize the capability of their products. I have never run across any spec say that their PXI hardware can close a deterministic loop at better than 40 KHz. I have tested the high end stuff and was able to close a loop at better than 100 KHz. If we use the "wizards" and Express VIs, yes the 40 kHz is an appropriate spec.

I think it was Rolf that said coding in LV was an art. I agree and have written that writting high performance apps is a lot like surfing because the memory management (in past years) was not under our direct control, rather it responds to subtle gestures an inuendo.

BUT, one you learn how to control the memory management, LabVIEW apps can scream!

I have an app deployed now that does nothing but monitor and log the interactions between multiple nodes (mix of PCs and other widgets) and is used as an integration tool to settle arguments about which node did what wrong when. TO do this my LV app had to run faster than all of the other nodes that were running code writtin in other languages.

The above does not addres the speed of development! I was contacted to upgrade the above cited app for a completely new set of nodes supporting a different system. I was done with my code changes after three weeks (nine person weeks of work). That was three months ago, and I have three more months to wiat before all of the other nodes (not written in LV !) will be ready to start testing.

So...

Show me a LV app that runs ten times slower than an app in C and I'll show you a diagram that lights up like a Christmas tree when doing a "show buffer allocation".*

Ben

* Yes other issue can slow down a LV app i.e. UI thread, but uncontrolled memory is the biggy.

[JÞB]

Please accept my appologies also-

In fact we're a bunch of geeks who love this kind of discussion (but I digress)

OK, so, I want to start a business what do I sell?   The ever popular answer is I sell "WHAT THE CUSTOMER WANTS."  If I don't I'm out of business. Period!

What the customer wants is usually "free", "perfect", "self-operating", and "delived last month".  In Manufacturing they also complain if the test system doesn't fix design flaws that reduce yield.  

I guess my answer then goes leans in favor of any software and hardware that differentiates on supportability.  Any hack can create "write only code" in any text based language.  (just cypher the variable names)  it takes a real genious to make Graphic language unreadable (It can be done see Breakpoint>Rube Goldberg thread)

Remember- the customer called you to do something the customer cannot do!  But, the customer still wants to understand what they are PAYING for.   In the end, if you want to stay in business, you lean towards NI(the #1 support after sale) but sell what you can.