DAQFactory versus LabView

[joergsch]

Hello Folks,

At one client we are close to the stage of having to decide whether to go the DAQFactory route or the LabView route in order to automate production. Of course, LabView is a lot more expensive than most versions of DAQFactory. However, when talking to engineers many didn't know DAQFactory and most said to go with LabView because it is more of a standard. Almost like how nearly everyone in business uses MS-Word. In Europe they didn't know DAQFactory at all and equipment makers I looked at do not provide drivers for it (but they do for LabView). The unavailability of drivers might become a concern.

So, my question: Besides cost, what would be the prime motivator for DAQFactory here? Is there something that LabView can't do, or where DAQFactory would be much easier to set up? We won't need the fancy stuff like emailing or text messaging to cell phones.

Also, about symbols (buttons etc.): I saw in Express that only the first one is available. Is that the same in the full version? If so, what do those libraries cost?

Regards, Joerg

http://www.analogconsultants.com/

[AzeoTech]

First, in all the paid versions you get all 40 some screen components. If you buy Standard or higher you also get the 3800 symbol library.

So, to answer your main question: Yes, most everyone has heard of Labview, largely because it was probably rammed down their throats in Engineering school, partially because NI has a billion dollar budget, and partially because its been around for 30 years or so. Its not quite the same as your MS Word analogy because really there are only so many ways to do word processing, and so most word processing apps are the same. LabView and DAQFactory are quite different approaches. The main difference is that LabView programming is done with a mouse, drawing lines between different screen components, where DAQFactory is a regular structured text scripting. Personally, as a structured text programmer, I find LabView difficult to understand as it is a complete different paradym then regular programming. Unless they are a LabView expert, I think most people agree. We get a lot of people that come over to DAQFactory because LabView is so difficult. With DAQFactory, anyone with any programming experience in almost any language can very quickly figure out the syntax and make quick progress in developing applications. With LabView, really only LabView experts are going to be able to help you if your application is of any complexity. Yes, there are a fair number of LabView experts, but a pittance compared to the number of regular programmers in the world. There are a few other apps that use a similar method to LabView, i.e. DASYLab, but DASYLab was actually sued and taken over by NI because of the patent infringement, so when you are actually buying an NI product (of course, the same applies to Measurement Computing and IOTech hardware, though they were simply bought by NI a year or two ago).

The other big difference between DAQFactory and LabView (and every other application that I know of) is that DAQFactory allows you to make changes on the fly without stopping your application and recompiling. So, if you decide you need a new graph halfway through your experiment you simply drop one in. With LabView, you'd have to stop the app, make the change, then restart, hoping that your equipment remained in a stable state while the computer wasn't controlling it. With DAQFactory, even on runtime installations, you can put a hardware key in and temporarily switch it to development mode to make changes on the fly. The advantage of this is not just the fact that you don't have to take the system offline, but also that it makes development faster and easier because you get immediate feedback on what you are doing. When you drop a graph on the screen and change its parameters, you see data immediately in the graph and can tweak it right there and then.

There are probably three areas where LabView is better than DAQFactory:

1) LabView has a lot more analysis tools, so if you are doing heavy duty engineering calculations, LabView has the toolkit. DAQFactory is a bit more of a HMI/SCADA app and so doesn't have the real high end toolkits, though you could simply buy a C library and call it from DAQFactory.

2) LabView supports many more hardware devices. Among DAQ devices at least (not automation devices), manufacturers basically have to make a LabView driver if they want to survive. So, National Instruments doesn't have to do any drivers, a lucky position to be in. DAQFactory isn't supported by every DAQ card manufactured but with its ability to call external DLL's and its powerful serial/ethernet tools you can expand it yourself or have us create a driver for you.

3) LabView has a lot more samples available. Of course without the samples you wouldn't get anywhere with LabView, and even with them, there is still a steep learning curve on LabView. DAQFactory really makes up for it with our stellar support. Just ask anyone who has worked with us. With NI, you'll get someone reading out of a book, with AzeoTech you'll get someone who was involved in development of the product and knows it top to bottom.

So in my personally, and obviously biased opinion:

Definitely use LabView if:

1) you have a LabView expert on staff, or you yourself is a LabView expert already.

2) you need to do a lot of really advanced data analysis that NI's toolkits cover

3) you need to use a lot of different DAQ hardware, or NI's high end stuff. When I say DAQ hardware, I'm talking mostly about internal PCI based cards or USB based devices like, but not including (because DAQFactory supports it already), the LabJack.

Definitely use DAQFactory if:

1) you have experience programming in structured text (i.e. normal programming) or access to a regular programmer and don't have time to spend months learning LabView

2) your data analysis needs are bit more normal

3) you are creating an HMI / SCADA application or really anything for industrial automation

4) you are using DAQ hardware primarily from one manufacturer (and thus we can create a driver for you easy), you are using devices that are connected through serial or Ethernet, or if you are connecting to any sort of automation device (PLC, RTU, etc).

5) taking your system offline for a change is a big issue

6) if you value good technical support

[jfiddler]

I haven't worked with LabView, but DAQFactory has been a pleasure to use. I'm an experienced programmer, but I hadn't programmed for many years before taking on this project, monitoring and controlling some biotech processes. I've found DF to be comfortable, reliable and powerful. Also, when azeotech brags about their tech support, they're telling the truth. I've asked a bunch of questions, but in this forum (look for my posts) and directly by e-mail when I don't think the question is of general interest. They're always answered promptly and thoughtfully.

My suggestion would be to grab the free demo and try it out. I think you'll be surprised how quickly you can throw something together.

[LabJack Support]

One thing I like to throw in is that LabVIEW is a full-blown programming language. You have to ignore a lot of the marketing, and realize that it is just a graphical version of the C language (with lots of handy libraries and functions). That is a good thing, in that if you have a programming background you can pick it up pretty quick, and do basically anything you want. But it is also a bad thing in that LabVIEW is marketed as more of a tool or utility that you can just run and do something. I wish their marketing would point out that it is a programming language so people know what they are getting into.

As someone that programs a little bit in lots of languages, LabVIEW is a good programming language in that the graphical (rather than text) interface generally avoids syntax errors and is easy to remember. The best thing about LabVIEW is probably the debugging capabilities, but many people don't approach it as a programming language and don't know much about the debugging features.

[joergsch]

Thanks for the detailed reply, also to jfiddler and LabjackSupport. That explains a lot and I am going to forward this to my client because they are the ones who'll call the shots on this decision.

Two more questions that also may be of interest to other readers:

a. We won't often need high-end NI cards and the like but we will use lots of standard equipment. Such as voltmeters with serial interfaces, Agilent spectrum analyzers, scopes from various manufacturers. How tricky will it be to pipe data from these into DAQFactory and possibly some settings back to the instrument? If this requires a driver to be written, what would the ballpark cost be if Azeotech would write one? For example, let's say for the old HP3585 baseband analyzer (which was one of the best HP ever built).

b. Let's say a client buys DAQFActory Base, Pro or even Developer in order to have a complete programming suite. Comes with all 3800 symbols as you said. Is it easy for a user to design new symbols in addition? Like in the way you do it for new component packages on a CAD system? In my CAD I have several choices: Design it from scratch (not very easy), take an existing one and modify it (most frequently done), import a graphics file (mostly done if you want the company logo on there).

Regards, Joerg

http://www.analogconsultants.com/

[AzeoTech]

a. We won't often need high-end NI cards and the like but we will use lots of standard equipment. Such as voltmeters with serial interfaces, Agilent spectrum analyzers, scopes from various manufacturers. How tricky will it be to pipe data from these into DAQFactory and possibly some settings back to the instrument? If this requires a driver to be written, what would the ballpark cost be if Azeotech would write one? For example, let's say for the old HP3585 baseband analyzer (which was one of the best HP ever built).

It all depends on the protocol. The hardest part sometimes is actually finding documentation for the protocol, especially if the device is not made anymore. If you have documentation, most devices fall into one of two types: simple ASCII, and binary with CRC. There are more complex protocols, such as DNP, but they are much more modern. Depending on your experience and desire, you can actually use the tools provided by DAQFactory to write your own protocol drivers. Its not terribly hard and we include a nice PDF primer on this in the download. We are of course here to help, which can be answering questions to help you develop your own protocol driver, or having us take care of it for you. Prices range from about $200 to $2000 depending on the complexity of the protocol and how many different functions you need implemented. So, $200 might be for a driver to allow you to read the temperature from a PID loop controller, and set its setpoint using a straight ASCII protocol, and $2000 would be something like implementing binary PLC driver with all functionallity. Pricing also depends on how reusable we think it is. If we think that many customers will benefit from the driver, then we typically discount the costs. If there is a particular protocol you are interested in, just email documentation on the protocol and we can give you a fixed price quote. I took a brief look for HP3585 docs on the net but couldn't find them. Oh, one other thing that is quite helpful is if you actually have the desired device and it is hooked up to a computer connected to a high-speed internet connection. We have tools to allow us to remotely connect in and test.

b. Let's say a client buys DAQFActory Base, Pro or even Developer in order to have a complete programming suite. Comes with all 3800 symbols as you said. Is it easy for a user to design new symbols in addition? Like in the way you do it for new component packages on a CAD system? In my CAD I have several choices: Design it from scratch (not very easy), take an existing one and modify it (most frequently done), import a graphics file (mostly done if you want the company logo on there).

Actually, Base does not come with the symbols, but that's just a minor detail (you can see what's included with what by going to this page: http://www.azeotech.com/nfeaturegrid.php). The easiest way to add new symbols is to simply create them in your favorite drawing program (say Photoshop) and cut and paste into DAQFactory. This works on all versions, even Express. With Standard and higher, you get the symbol library, so you can also put your own custom symbols in this library. The symbols are mostly drawn using vector graphics, so a program like Illustrator works best, or there are a few shareware WMF drawing programs available. These programs, or even Photoshop or other bitmap editor can be used to modify the existing symbols, though if you use a bitmap editor, you will lose the ability to scale or rotate the image within DAQFactory, so you'll want to draw it at the desired size.

One of the most common ways people use images is to actually draw out the background (static parts) of their pages in Photoshop and then overlay dynamic components within DAQFactory. This is actually how the QuickMod program gets the rounded rectangles. You can also see it in the AshlandWater.ctl sample, where a bitmap map of Ashland is overlaid with dynamic controls. This sample also shows how to make what would be called a client side image map in HTML, allowing you to click on areas of the map and switch to different pages. A panel component is simply placed behind the image with click Action.

[joergsch]

[re-use of drivers]

That's what I thought about but I didn't assume you offered re-use of drivers you already created. Is there a list that allows users to see what's already there? In other words to find out whether a certain piece of equipment already has an Azeotech driver?

Most of it will be Hewlett-Packard/Agilent, Tektronix digital scopes, and Fluke digital meters.

If such a list existed this would allow people to look for matching equipment. Often it doesn't really matter exactly which scope model a client buys since "regular" tasks can be performed by almost any model.

Opening remote access is no problem, we are already doing that.

[symbols]

Thanks, that answers it. Creating symbols in a separate CAD or drafting programs is easy.

Regards, Joerg

http://www.analogconsultants.com/

[AzeoTech]

The ability to create protocols quickly within DAQFactory is a relatively new and powerful feature and so we haven't had much time to build up a big collection, but are certainly working on it. We'll be expanding our site a bit in the coming months and will start adding these in, but there is no master list. Many people are able to simply develop it themselves and so we never see this code. We may try and create an area where customers can share their protocol drivers.

[joergsch]

... We may try and create an area where customers can share their protocol drivers.

That is an excellent idea. This is also how it's done with the CAD software Cadsoft Eagle. It was one of the reasons why I switched to that product. Users can share libraries but, of course, one has to be careful and not assume they are all perfect. If you want to get an idea how it can be realized via a web site:

http://www.cadsoft.de/

Another nice advantage is that they use a standard newsgroup format, hosted on their own server. That is the still most efficient way of exchanging information, and probably will be for a long time to come. You just point the newsreader to their server, subscribe to all the groups you are interested in or where you understand the language, subscribe, and that's it. No passwords, nothing.

Regards, Joerg

http://www.analogconsultants.com/