Anybody here used LabVIEW before?

Thread Starter

strantor

Joined Oct 3, 2010
6,782
I am looking to automate an old machine + integrate Data Aquisition and I am considering LabVIEW. I have never used it before; just heard about it from someone else.

The machine is a pull tester for cables. a 20ft section of cable is clamped at one end and tension is applied to it by a hydraulic ram on the other end. around the cable are large heaters to heat it up while stretching it.

here's what I got:
· heating is controlled in 6 zones by 6 separate Watlow 985 PID temperature controllers.
· Tension is applied hydraulically via increase & decrease pushbuttons & read out on a digital display. increase/decrease operation is very hard to control and not precise; often overshooting.
· Data Acquisition is via an Agilent 34970A DAQ unit, measuring ovality, diameter, and other parameters

Current operator process is as follows:
1. Operator will set all 6 heat zone controllers to the maximum heat specification for the cable under test (variable) & wait for all 6 temperatures to stabilize
2. operator will apply tension up to the maximum specification for the cable under test (variable)
3. operator will drop the temperature on all 6 zones to room temperature and wait for temp to stabilize
4. Operator will increase tension from 0lbs to max tension spec for the cable under test (variable, 5000lbs-10,000lbs), stopping 20 - 35 times (20-35 more variables) along the way and capture readings via the Agilent DAQ unit.
5. Operator will increase heat on all 6 zones from room temperature to 150F and redo step 4. Then increase to 225F and redo step 4, and so on for temps of 300F and 350F, maybe more.

even though the only requirements are to apply pressure, heat, and start/stop a data logger, we are dealing with possibly hundreds of variables, and a single sequence with possibly hundreds of steps that may take all day. Also, considering this machine is used by engineering, I anticipate that the way in which it is used (the variables as well as the steps) will vary greatly throughout its life, so a high degree of flexibility is need here. Technically it should be possible to automate with a PLC (the Agilent DAQ appears to accept an outside trigger to start/stop logging), but personally, I do not think that a PLC is the way to go. Using a PLC would be exceedingly complicated and would mean also needing an HMI to input all these variables and I can see myself going to reprogram it monthly or weekly; any time the engineers desire a different operation from it. a friend has suggested using a PC-based platform called LabVIEW. I have not used LabVIEW before but a brief review of it looks promising. It looks heavier on the Data Acquisition side than the process automation side, but it is has analog & digital output hardware so it is probably still up to the task. Graphical block programming, easy interface to hardware; the Engineers could modify the process themselves, as well as integrate the data acquisition into the process.

This Alicat PCD Series valve/controller combo can be controlled by potentiometer or RS232 devices (PLC), and also has a ready-made driver for LabVIEW. The Watlow 985 controllers accept no external setpoint reference, so I recommended upgrading them to Eurotherm 3208 controllers; these are same-size drop in replacements that have RS232 comms ability + ready-made LabVIEW drivers

So, I am looking for anyone with LabVIEW experience to validate me barking up this tree or send me to another one. Can LabVIEW be used to automate my machine? thanks
 

bobcart

Joined Jul 7, 2011
55
Labview can do it, once you program it for your application and have the sensors and switches, etc. you need in place. You might want to post in a lab view group. Good luck
 

someonesdad

Joined Jul 7, 2009
1,583
I haven't used Labview, so I can't comment on it. However, I like to use python, numpy, and wxPython for instrumentation control and graphical displays. With pyVisa (a free add-on library), you can talk to GPIB, serial, and USB instruments (I've talked to all three of them and have written a commercial tool with these programming tools). Once you can talk to the instruments, the rest is straightforward (not necessarily easy, just straightforward elementary programming).

A nice feature of the python approach is that all of the tools are free (except perhaps for the hardware for the interfaces).
 

t_n_k

Joined Mar 6, 2009
5,455
I use Labview (albeit an old version 7.1) regularly. Mainly for data acquisition tasks.

It's fairly expensive to buy plus you also need to purchase the Application Builder if you want a standalone application without needing a Labview install sitting on the target / controller PC. Although, you can have Labview installed on a few (3 max ?) PC's under the one license.

Labview has a relatively steep learning curve. The later versions are probably more powerful / flexible. I thought Version 8 was OK but I found using the Application Builder a challenge. I only used it a couple of times however.

In principle I don't see why you couldn't use Labview for your application. If you are experienced with PLC's and HMI's I would reconsider that option. Is there a Labview compatible library for the Agilent DAQ unit you want to use?
 

ErnieM

Joined Apr 24, 2011
8,377
Any programming language that can run on your PC can do this task. That includes the free downloads of Visual C++ or Visual Basic from Microsoft.

I only noticed 3 things you want to communicate with, the 34970A, the Alicats, and the 3208's. ALL of these were noted as having an RS232 control, and as you need an oodle of these you can use USB to RS232 devices to add all you need. They cost in the under $30 range and look like com ports inside your computer, and Windows has the drivers for that.

I used to be a test engineer before PC's could do it, we did it all in HP Basic. I've seen test done in Labview but it looked incredibly clunky to me.

I am just not a fan of Labview.
 

GetDeviceInfo

Joined Jun 7, 2009
2,192
I've modified a similar process for a client where they were pulling lumber to qualify glue joints. In thier process, they had an old TI PLC programmed to perform a variety of operations, but they had no HMI, so they were not comfortable that the machine was actually working. The previous tech would spend several days calibrating the equipment. My solution was to use Labview as the HMI component, and reprogram the PLC to better serve the process and interface.

Your proportioning valve requires a loadcell for feedback. These are calibrated using a known standard (load cell). Your conversion factor won't be linear, and that's where Labview made it so easy. The analog/digital conversion was done in our case via the PLC and communicated to Labview via modbus.

Although Labview does have sequential programming, I would consider the real world equipment interface, which often implies a PLC. Consider programming service routines into the PLC and select which ones to run, and provision of variables, via Labview. With this approach, you PLC is more or less a slave, bringing your costs way down. As mentioned though, Labview is not cheap.
 

Thread Starter

strantor

Joined Oct 3, 2010
6,782
It's fairly expensive to buy plus you also need to purchase the Application Builder if you want a standalone application without needing a Labview install sitting on the target / controller PC. Although, you can have Labview installed on a few (3 max ?) PC's under the one license.

Labview has a relatively steep learning curve. The later versions are probably more powerful / flexible. I thought Version 8 was OK but I found using the Application Builder a challenge. I only used it a couple of times however.

In principle I don't see why you couldn't use Labview for your application. If you are experienced with PLC's and HMI's I would reconsider that option. Is there a Labview compatible library for the Agilent DAQ unit you want to use?
Money isn't (really) a factor. I always feel weird saying that. My company buys whatever they want. How much do you think it would cost? I think they want to get rid of the Agilent DAQ and use labview for for the data acuisition. I will look and see if there is a library for it. do you think it would be beneficial to keep it?

I only noticed 3 things you want to communicate with, the 34970A, the Alicats, and the 3208's. ALL of these were noted as having an RS232 control, and as you need an oodle of these you can use USB to RS232 devices to add all you need. They cost in the under $30 range and look like com ports inside your computer, and Windows has the drivers for that.
.
I have used these (don't remember which brand/model) before and experienced all manner of wackiness with the com ports. I use 1 usb>RS232 converter and my computer adds 10+ com ports and you never know which one is the right one. have to try each one, and it's different every time you power on the computer. Do you know of one that works better?

I've modified a similar process for a client where they were pulling lumber to qualify glue joints. In thier process, they had an old TI PLC programmed to perform a variety of operations, but they had no HMI, so they were not comfortable that the machine was actually working. The previous tech would spend several days calibrating the equipment. My solution was to use Labview as the HMI component, and reprogram the PLC to better serve the process and interface.

Your proportioning valve requires a loadcell for feedback. These are calibrated using a known standard (load cell). Your conversion factor won't be linear, and that's where Labview made it so easy. The analog/digital conversion was done in our case via the PLC and communicated to Labview via modbus.

Although Labview does have sequential programming, I would consider the real world equipment interface, which often implies a PLC. Consider programming service routines into the PLC and select which ones to run, and provision of variables, via Labview. With this approach, you PLC is more or less a slave, bringing your costs way down. As mentioned though, Labview is not cheap.
That's an option I hadn't considered. PLC+LabVIEW. I will need to investigate further and see what my requirements really are and communication between PLC & LabVIEW. So far all I know is that on the LabVIEW website, it shows the labview screen with an AB PLC in the background, so I guess that infers (sp??) they work well together,

thanks for the brain food.
 

ErnieM

Joined Apr 24, 2011
8,377
Money isn't (really) a factor.
Cool! Then lets spend LOTS OF MONEY ! :D

I have used these (don't remember which brand/model) before and experienced all manner of wackiness with the com ports. I use 1 usb>RS232 converter and my computer adds 10+ com ports and you never know which one is the right one. have to try each one, and it's different every time you power on the computer. Do you know of one that works better?
AFAIK you can install them to always use specific COM port, I have a dim memory about that specific issue somewhere, but exactly where I don't know, perhaps the Microchip forums.

However, while I have never used them I have always kept B&B electronics on my radar. They do have a single USB to 16 RS-232 converter and lots of other really sound industrial grade controllers. Give them a look-see.
 

GetDeviceInfo

Joined Jun 7, 2009
2,192
That's an option I hadn't considered. PLC+LabVIEW. I will need to investigate further and see what my requirements really are and communication between PLC & LabVIEW. So far all I know is that on the LabVIEW website, it shows the labview screen with an AB PLC in the background, so I guess that infers (sp??) they work well together,
you'll find that Labview can attach to most protocols, including OPC servers, so RSlinx over ethernet is doable. I personally recommended an AVR micro system handling the valve/loadcell, attached to Labview via USB. They decided against the $$.
 

t06afre

Joined May 11, 2009
5,934
Labview works well I have used Labview since 1999. But your project is quite big. And it is not perhaps the best project for a beginner. The problem with Labview. Is that it is very easy for the beginner to write code in a very bad coding style. A small program may work. But for a larger program. You may end up with a something that is not very stable. Then working with Labview. You must thing more like hardware designer. And Not a software designer. The key is to think dataflow.
It is also a problem that the Labview sales person. Is very focussed and closing a deal. Like a dodgy used car sales person. So you may end up with something you do not need. I will recommend that download Labview and use the 30 days trail period. To see if it is the correct thing for you and your project.
 

Thread Starter

strantor

Joined Oct 3, 2010
6,782
Well the project got taken away from me. When I filled my supervisor in on all of this, he determined that he couldn't spare me from my other duties for the length of time it would take for me to learn all this and finish the project. he is going to have someone else come in and do it. darn, I was looking forward to it.
 

hspalm

Joined Feb 17, 2010
201
That's too bad, really. It sounded like a very interesting project.

For my final year project I had the opportunity to use PLCs and SCADA software from OMRON, and was about to recommend this to you. What you end up with is an easy way to make a nice GUI (or sort of PC-based HMI) with seamless integration to PLCs, but also with the somewhat powerful option to include VBScripts, EASY rs232 communication, and even database connections (SQL). Plus, it's cheap, at least compared to competitors PLC systems and SCADA software (can cost you huge money).

Good luck on your next opportunity!
 

t_n_k

Joined Mar 6, 2009
5,455
It is also a problem that the Labview sales person. Is very focussed and closing a deal. Like a dodgy used car sales person. So you may end up with something you do not need.
Perhaps you should be more careful about comments you make regarding the motivations of a particular company and its employees. This is a public forum. Frankly I have found the NI representatives (in Australia) I have dealt with genuinely helpful and willing to go the extra mile to support my technical requirements / issues.
 

GetDeviceInfo

Joined Jun 7, 2009
2,192
yes, it is too bad that a decision was made, as there are certainly other options.

the thing with Labview is that it is just software and provides no physical porting. Implementing a PLC gives your realworld ports, and a platform for reprogrammable logic. In rereading your OP, it would sound like the function of 'recipes' via an HMI might better serve your needs. As you use AB products in your plant, it would make sense to utilize those resources. You may have access to the studio versions of RSview or FactoryTalkview which gives you the ability to develop HMIs. By connecting to your PLC via RSlinx, your HMI could store 'recipes' for recall at runtime. These recipes could be constructed via HMIs on a dedicated terminal, or even networked PCs. In a simpler form, the 'recipes' could be constructed in a spreadsheet template saved to xml, which could be read by the HMI.
 

Thread Starter

strantor

Joined Oct 3, 2010
6,782
yes, it is too bad that a decision was made, as there are certainly other options.

the thing with Labview is that it is just software and provides no physical porting. Implementing a PLC gives your realworld ports, and a platform for reprogrammable logic. In rereading your OP, it would sound like the function of 'recipes' via an HMI might better serve your needs. As you use AB products in your plant, it would make sense to utilize those resources. You may have access to the studio versions of RSview or FactoryTalkview which gives you the ability to develop HMIs. By connecting to your PLC via RSlinx, your HMI could store 'recipes' for recall at runtime. These recipes could be constructed via HMIs on a dedicated terminal, or even networked PCs. In a simpler form, the 'recipes' could be constructed in a spreadsheet template saved to xml, which could be read by the HMI.
According to NI's website, they do have a hardware side of LabVIEW;
NI Hardware

With more than 50 million I/O channels sold in the last 10 years, National Instruments is a global market leader in PC-based data acquisition, with a complete family of data acquisition products for desktop, portable, industrial, and embedded applications. You can use NI-DAQmx driver software to integrate more than 200 data acquisition devices in LabVIEW on a variety of major buses and form factors, including USB, PCI, PCI Express, PXI, PXI Express, wireless, and Ethernet.

In addition to data acquisition hardware, NI also offers other specialty test, measurement, and control hardware. Modular instruments synchronize measurements, signal generation, radio frequency (RF), and switching components for automated test systems. NI programmable automation controllers combine the ruggedness of a PLC and the performance of a PC for industrial measurement and control applications. Vision devices also offer unique capabilities not found in many traditional sensors, such as verifying component positioning, counting physical elements, and reading bar codes. Each hardware type includes its own driver software for easy integration into LabVIEW. Examples include:

  • Digital Multimeters
  • High-Speed Digitizers (Oscilloscopes)
  • RF Signal Analyzers
  • RF Signal Generators
  • Signal Generators
  • High-Speed Digital I/O
  • Switches
  • Programmable Power Supplies
  • Reconfigurable FPGA I/O
  • Motion Controllers
  • Vision Systems
The drivers for all of these products were designed with LabVIEW in mind and feature convenient access to all of the available functionality of the hardware. The driver installs directly into LabVIEW and adds new functions to the Functions Palette so you waste no time locating and including support for your hardware. NI device drivers generally implement advanced features such as device name aliases and hardware simulation so you can develop software without tying yourself to a particular device. As long as your device supports the same functionality, the driver can adapt to the new device, even if the underlying technology changed dramatically, such as when moving from a PCI-based data acquisition device to a wireless device.
I would jump at the chance to program a HMI and PLC for them, but the thing is that they need it to be very versitile. I could make recipies for things like max tension, max heat, and tension/heat step to stop and take readings. The problem is that next month, the engineers may totally change the process they want to run. Next month they could want to stress it 3 times, then heat it to max, then stress it 3 more times, then the process is over. I would have to completely reprogram it. It's probably possible, but I don't think I could achieve the level of flexibility they want with PLC/recipies. This is the kind of stuff that some guy in a machine engineering company gets paid to do and has a deadline in the order of months. I am a maintenance tech and I have gearbox oil to change and parts inventories due. The opportunity for programming PLCs (what I got hired to do, ironically) comes along seldom and when it does come up, It's usually only "add this function" or "change the way this works". I get all excited when the chance comes along. I hate that this got taken away from me.

What I was hoping to accomplish with LabVIEW is that the engineers could modify the process themselves with the (seemingly) easiy graphical interface.

IMO this machine is a good candidate to stay as it has been since 1965 when it was made (operator controlled)

Oh well, since it's out of my hands I'll just wait and see what they come up with.
 
Top