I was volen-TOLD to complete the task of sending data collected from an automated Carbon analyzer (from a GE Water filtration system)to our SPC database as a means of storage/ analysis.

the analyzer uses modbus, which I have enabled and sending data via ethernet to a designated IP address. Now the problem of grabbing the data. Our SPC software has several different "providers" to grab data, including OPC, grid (CSV), OLEDB, ect... but none specifically with the word "modbus:, therefore I'm lost.

Can someone help enlighten me as to what I'm looking for in grabbing this data in layman's terms?

 

If your SPC software is "OPC client" capable, then OPC is a definite avenue.

OPC servers are responsible for implementing communications to field devices (with an appropriate driver) to read data from or write data to a field device. To my knowledge, all commercially available OPC servers have a Modbus driver. An OPC server would be custom configured for Modbus communications with the analyzer. Commercial OPC servers are available from Kepware, Matrikon, Iconics, among others.

In crude overview terms, the SPC's OPC client requests data from an OPC server and the OPC server gets the requested information from the field device, in your case using the Modbus protocol.

Check to see whether your SPC software is OPC client capable.

 

The terms "OPC", "OLE" represent driver interface formats. CSV is a file format (Comma Separated Value). To use an OPC interface you would purchase a Modbus OPC "driver". For various obscure reasons this is usually referred to as an "OPC server". That is a piece of software that converts Modbus (with other versions for other protocols) to the OPC format which your software can interface to directly. The OPC server would talk to your analyzer using Modbus, and your SPC database would talk to the OPC server using Microsoft COM/DCOM.

I can't recommend any brand in particular, but two popular OPC vendors are Kepware and Matrikon. They're quite expensive, but I'm not aware of any cheaper brands. The Modbus protocol is not very complicated and there are lots of free Modbus drivers available as source code, but the limitation here is what your SPC database is willing to talk to. If there are any other interface possibilities besides what you have listed I might be able to make some suggestions, but of those three OPC is your best bet. OLE is an older system that Microsoft had to let programs communicate with each other. It's long obsolete however. CSV is just a file format, so I assume it is just intended to let you import data from spreadsheets and other similar sources.


As for Modbus itself, that comes in several forms:

1) Modbus/RTU - This is normally sent over RS-232 or RS-485. It can be "tunneled" over Ethernet, but there are no official standards for doing so. Ethernet "tunneling" is sometimes done by manufacturers to cheaply add a third party Ethernet interface to an older RS-232 based instrument design.

2) Modbus/ASCII - This is similar to Modbus/RTU, but it has changes which make it less timing sensitive. I think the main application for it is radio links.

3) Modbus/TCP - This is *not* the same as Modbus/RTU tunneled over Ethernet. This is the official Ethernet version of Modbus. It is probably the most widely used industrial Ethernet protocol. This is *probably* what you have, but I can't tell for sure from the information you have provided.


Like most protocols, Modbus is "client-server" oriented. A client (sometimes called a "master") sends a request to a server (sometimes called a "slave") which returns a response. The response may be some requested data, or it may be an acknowledgment that some data from the client was received by the server.

You have to figure out what type of Modbus you have (Modbus/TCP, or Modbus/RTU tunneled over Ethernet) and whether your analyser is a client or a server.

I have some information on Modbus on my web site at:
http://mblogic.sourceforge.net/mblogichelp/communications/ModbusBasics-en.html

 

Hello,
You can write for ex. VB or perl code to get the data. Try www.modbus.pl for examples.

Regards
Andrzej

 

First off, do you know anything about programming in C or BASIC? There are scads of examples on the net that you could modify for your purpose.

If not, then you might try something along these lines:

http://www.automatedsolutions.com/

Going back to your actual question about layman's terms, Modbus is pretty simple in concept, but devilish in the details.

Simply put, you need a Modbus master and one or more Modbus slaves.

The master will initiate communications between itself and the slave(s).

Each slave has a unique address (node) and will ignore any request not addressed to it (with the exception of a broadcast message from the master).

So in practice, you would set up node addresses for each slave (and the master), and then from the master you would request the data that you were interested in from the slave (or write data from the master to the slave).

If you wanted to record data from a slave periodically, then you would repeat the request at whatever time interval you wanted.

That really is about it, the complexity lies in trying to create these "Swiss Army Knife" programs that will work on any type of device, network, platform, etc.

I imagine that for your needs that you really don't care about this, you probably want one or two specific registers read from your GE device and that's about it.

If that's the case, then that frees you up considerably, the request from your master can be more or less hardcoded into a string and sent out port 502 (Modbus TCP port).

What you do with the data that comes back is fairly simple. At the very least, you will have to determine which node/register request you are dealing with (for a system with one node and one register in the dataset this can be omitted), and you *should* run the message through a CRC check to make sure that it is valid. Based on my experience I've yet to see a bad packet come back. YMMV.

So assuming that you are reading from more than one node, and reading more than one piece of data, then you will have to scan the message to see where it came from. A simple text compare will do this, it's not like the nodes are going to re-address themselves.

Likewise the CRC check is simple (I have source code that I have written for CRC16 and LRC checksum routines for VB6 and PowerBasic. Let me know if you need them).

Keep in mind that you only have to determine the CRC for each master request once, since as long as you don't change the node or the address that you are reading the message coming from the master will never change. This is what I meant by "hardcoded".

Once you've determined which device (node) and which register you got the message from, you can add that line to a CSV formatted file and import that to excel or whatever. Or you can post that data to a web page.

 

Automated Solutions offers OPC DA servers for Modbus and other brands. Price is significantly less than the OPC suppliers that you mentioned.

http://automatedsolutions.com/products/asopc.asp

-Mark
http://automatedsolutions.com

 

Thank you all very much for your input. The biggest thing I've learned thus far is that I have a lot more to learn!

First, the equipment is using Modbus TCP/IP. It is enabled and sending data. I have also verified that I can ping the IP address from the network.

Next, the SPC company does have an OPC provider.. they are checking whether or not it will directly communicate with Modbus. Getting back with me next week (holding my breath)

In the mean time, I've downloaded a free Modbus SCADA (IntegraXor) and am attempting to "grab" the needed data and populate in a web-based Access database (I think that's what I'm doing)?? From there, I could use the SPC's grid provider, and rather than choosing columns from a .csv, pick values from the Access database.

Does this seem far-fetched? This all still has a "sci-fi" novel feel to me.

Thanks again for your help and patience!!

-Nathan

 

I tried to log in for getting more info on Modbus-basic,I am getting error 404, and 403. Griffin, do you mind to post your web page URL or anyway can you help me out to go on this web page?

Your link is copied below. Am I doing somethings wrong?

Thanks

>http://mblogic.sourceforge.net/mblogichelp/communications/ModbusBasics-en.html

 

The forum inserts a space into URLs which doesn't belong there.

Look very carefully and you'll find a space in the posted URL's.

- in the word Modbusbasics between the s and i Mark's post

- in the word Modbusbasic between the u and s in your reply

Take the space out, wherever it appears and the URL will work correctly.

 

http://mblogic.sourceforge.net/mblogichelp/communications/ModbusBasics-en.html

The link works for me. Make sure there are no space characters in it.

There is another good source of modbus basic information at www.simplymodbus.ca/FAQ.htm

 

As others have mentioned, remove the space in the URL that I gave you before using the links. Most modern forum software inserts spaces into long strings of text to allow your web browser to break the text up into separate lines. That prevents long strings from disrupting the page layout.

As for Modbus/TCP, you also need to know whether you are dealing with client or server (master or slave). Either your analyzer has to be a server and the SPC software a client, or visa versa (the analyzer a client and the SPC software a server). It's just like your web browser is a client and Control.com is a server. It is most likely that the first configuration is what you have (the analyzer is the server, and the SPC software is the client). If you are somehow stuck with both being clients or both being servers, then let us know. There are some solutions to this situation, but I won't go into them in any detail unless they become relevant to your problem.

As for using IntegraXor to attempt to download some data, I don't know enough about your SPC software to know whether it will work. However, it is quite possible that file interfaces (whether from a database or CSV file) are intended for one-time data imports. You may have to watch out for duplicate records, and there may not be a practical way of automating it. It may be informative to try it for testing purposes however.


I have some (free) software which may help you (watch out for any spaces in the URLs). This is the download page:

http://sourceforge.net/projects/mblogic/

In the main download file you will find a package called MBTools. That will contain several programs, including:

1) MBAsyncServer. This is a simple stand alone Modbus/TCP server. You could use this to test your SPC software's Modbus/TCP capabilities, where it could stand in for the analyzer (for testing purposes). Here's the documentation link:

http://mblogic.sourceforge.net/mbtools/mbasyncserver.html


2) MBProbe. This is a simple Modbus/TCP client with a web based GUI that will let you read or write arbitrary Modbus/TCP data table addresses. You can use this to test your analyzer to see what is in the various addresses. You could also use it in combination with MBAsyncServer for manual testing (e.g. write data to addresses in MBAsyncServer and see if the SPC package can read the data from it). Here's the web site documentation (the program also has it's own on-line documentation).

http://mblogic.sourceforge.net/mbtools/mbprobe.html


Neither of the above are a direct solution for creating your production system, but they can help in your preliminary testing to see if everything works.

If you wanted to write a simple program that reads Modbus/TCP data and stuffs it into a database that is certainly possible, and I have some (free) Modbus/TCP libraries to let you do that in Python. If you are interested in that idea, let me know and we can discuss it further.

A big thing you have to consider in all this is how important it is to have reliable continuity of data. That is, if the analyzer stops working, or your data collector stops collecting, how will you know, and how soon do you need to know it (so you can take corrective action)? It may not be acceptable to lose a few weeks worth of data simply because nobody noticed that something stopped working or that somebody changed some firewall rules and the data collector can't contact the analyzer anymore. Simply buying more expensive software in the hope that it will be more reliable doesn't help with this, as the problem may not be in the software (and the expensive stuff often isn't any better either). There needs to be some fairly straight forward way of telling that everything is working end to end and somebody needs to keep an eye on it with minimal effort. You will want to keep this in mind when deciding what sort of solution to put in place.

 

Thank you guys, finally I got you !!!
Happy New Year to all hard working you guys

 

Have you tried MatrikonOPC's Server for Modbus:

http://www.matrikonopc.com/opc-drivers/opc-modbus/base-driver-details.aspx

 

Another OPC alternative would be the Cyberlogic MBX OPC Server.

www.cyberlogic.com