Does anyone know of a way to get a resistance reading from a high end multimeter (Agilent 34410A or the like) out to a SCADA system so that I can put the data into a database and generate a barcode. Then send all to a printer to print out a label without too much hardware.

I am not particular on the model of multimeter as long as it is very accurate (at least 6 1/2 digit). Wonderware is better for me as that is what I am used to.

The meter has several interfaces (GPIB, LXI, etc) but I don't see any I/O drivers for wonderware for anything like this.

Thanks

 

You can use any of those. My choices would be RS232 if available, as it's cheap. Or GPIB (IEEE488) because it's fairly universal. RS232 can be done with any programming language and no hardware other than a cable. IEEE488 will require a card and will usually include a library and/or demo code. Once you have the reading you will have to ask WW how to get it in as I don't do MS, but I'm sure they have an API or some kludge.

Regards
cww

 

In reply to curt wuollet: I think getting Wonderware to talk to it is the problem he's trying to solve. This sort of application is pretty straight forward if you use a normal programming language. This is routine stuff for automatic test equipment applications.

Trying to do the job with a SCADA or HMI software though is like pounding a square peg into a round hole. I don't have a good suggestion other than to do the application the conventional way using a normal programming language.

 

I think we are talking about the same thing. It would depend on what WW exposes to the world. One would hope that if you read and convert the reading, there is a place to write it without going through creating an ODBC source or OPC client or that sort of closed source nonsense.

One probably couldn't hope for the simplicity of shared memory, but they have to have something for client/server type add ons. Whether they will tell you what is another matter. This is where an OSS app would make things a lot easier.

Regards
cww

 

In reply to M Griffin

You are correct. I need a way to get information from the meter to wonderware or someother program so that I can put this information into a database and print out a barcode. I have looked at Labview. They can talk to the meter, but I can't use labview to store in the database or print out the barcode as far as I know. I also don't know labview, but am willing to learn.

I am trying to avoid a couple of things here for the sake of simplicity. The first is to avoid writing my own code. I am not very proficient with VB and even less with C++. The next is to avoid going through a PLC, just added hardware that I don't think I need.

I am just looking for an OPC driver that will let me talk to a meter from wonderware, could be any meter with decent accuracy. Not necessarily the Agilent one mentioned.

I could probably write my own code, but it will take me a lot longer and I don't have a meter to experiment with. The meter mentioned runs about $1300 and I not willing to buy or rent on my own dime for the customer while I am writing the code and debugging while learning VB again.

Mike

 

Labview would be a very expensive way to accomplish that. What does WW have to say? They may support something that can be a hook into their system. Maybe they support a DAQ board or some other analog IO that can make resistance measurements.

With a DAQ board for example you can set an analog out for a convenient value of current and read the voltage with an analog input in a 4 wire Kelvin setup. A PLC for this application that interfaces with WW and had analog IO would probably be the easiest, unless you can find a meter that features a protocol that WW does.

If you need any logic or motion to synchronize the readings with the real world, a supported PLC begins to look good.

Regards
cww

 

Some meters have an RS-232 interface. I don't know if you can do anything with that in Wonderware, but you might want to look into it.

GPIB is the standard interface for "lab" type instrumentation. I called it "lab" instrumentation, but this sort of hardware is also intended to be used for automatic test equipment on production lines. However, I've never seen a GPIB interface for a PLC, and I've never heard of an OPC driver for GPIB. Those are limitations of PLCs and SCADA systems though, not problems with GPIB itself.

Most "industrial" hardware and software are closed systems with no ability to directly interface to anything outside of a very narrow range of hardware. In most cases this is a deliberate decision by the manufacturer either to lock you in to their own product range for your complete system, or because their design simply doesn't have the flexibility to go beyond certain limited capabilities.

As for other ways of doing this, I wouldn't recommend Labview for your application unless you are already very familiar with it. Labview is usually capable of doing this sort of application, but you have to learn all about Labview before you can do anything with it. It is definitely not cheap either. Labview has the same problems that SCADA systems do in that it does a very narrow range of things very well, but it is very difficult (or impossible) to make it do things it wasn't specifically designed for.

As far as conventional programming languages are concerned, my own preference for this type of application would be Python. Since you don't want to write a program though, this point is probably moot.

 

Yes, this is right up against one of the biggest problems with shrinkwrap closed source systems. You can only do what they allow you to do. But there must be _something_ you can use to get a number in.

You could try seeing what they do with RS232 barcode readers. That would be polled and should have some in line data editing. If you can set the meter up so it doesn't need a command to read, it should work. They would almost have to be able to deal with barcodes.

Regards
cww

 

Had no luck trying to find an OPC server for GPIB or LXI. Had no luck looking for WonderWare drivers for GPIB cards. (Bear in mind I only spent about an hour on this.)

The best I could come up with is Red Lion (www.redlion.net) This would be IN PLACE of the meter. I think (but I'm not sure) you would use their signal conditioner and their modular data acquisition product. So a system might consist of a IAMS0001, a CSMSTRV2, and a CSINI8.

Now a good question is going to be, "will it have the accuracy I need?" Unfortunately, I have no idea. I can't tell by looking at the data sheets. But you should be able to call Red Lion and ask them.

Of course, they aren't the only ones with signal conditioners, or analog-to-Ethernet.

-James Ingraham
Sage Automation, Inc.

 

You're making this too complicated. If the DMM doesn't have an RS232 port, any many do, you don't need a GPIB card for the PC or specialized code, etc. Just get a 232/GPIB converter from NI or Black Box or somebody and write the app in whatever language you like. I did almost this very thing in WinBatch once, read AC and DC voltage from a DMM and wrote to a CSV file, but Python would certainly work too. Easy peasy.

 

Most high end meters have high speed interfaces that support thousands of reading per second. Typical lab/test environment and proprietary logging solutions. Neither of Wonderware's historians would ever be able to handle data sampled at that rate. Sounds like your data needs are not really high speed but more of a polled sample. You need to find a meter with an RS232 interface and then you can use IOServer such as TalTech WinWedge or Software Toolbox Omni Server to read the serial data. Either of these will support DDE at a minimum and I think both supports OPC.

Saying Wonderware is like saying Chevrolet. It doesn't describe what product you are using. I assume stand alone Intouch. If your using the AppServer 3.0+ system, you have the full .NET 2.0 assemblies at your disposal. You could deploy an AppEngine to the PC with the meter interface and read the data with .NET. You could derive an object that read the data and wrote to the database using an system.data.oledb connection assuming your using an OLEDB compliant database. Values would be available as Galaxy tags to do anything you wanted with the information.