Hi there,

I'm trying to build a level monitoring system for a few tanks we have in here. The idea is to use laser or ultrasonic sensors. The sensors I'm studying at the moment has a RS422 output or a analog 4-20mA, 0-10v.

We will develop a custom application to monitor the tanks level and create reports but the thing is, this application has to get the sensors reading through Ethernet and the data must be XML.

So, is there any kind of gateway or something like that, that i can use as a bridge between the sensors and the local network, that will translate the readings to XML?

A PLC with this functionality would be great, since we would be able to use it (the same PLC) to other future automation needs.

But note that for this level monitoring, actualy there's no other function besides reading the levels.

Hope somebody can point me to a right direction.

Thanks in advance.

 

No offense, but why can't you use a Ethernet <-> RS422 converter (I'm assuming you don't have an RS-232 port or RS-422 port on your PC). Any version of C, C++, or C# with the right libraries can handle straight Ethernet. Are you doing a browser application?

My gut feeling is any gateway device that converts your level value to XML file will be inherently slow (Many seconds??). If this doesn't matter I suspect you are OK in using such a device. What protocol are you going to be using to get the XML data? FTP, Telnet, HTTP??

KEJR

 

Beckhoff Automation has PLC functions to write PLC variables to an XML file.

 

Ken is correct. Using VB.Net or C you can use the Ethernet socket client functions to read and write network data. .Net can then format data into XML. The follow is an example of for reading and writing data given an IP address and port number. To test your application, you can download the .Net express version from Microsoft for free.

Imports System
Imports System.Net
Imports System.Net.Sockets
Imports System.Text
Imports System.Threading
Module ModSockets
Friend SocketError As Boolean

Friend Function SocketsClientReadWrite(ByVal Server As String, _
ByVal Port As Integer, _
ByVal WriteData As Boolean, _
ByVal message As [String]) As String
'If reading, returns data string, if writing returns empty string
Try
' Create a TcpClient.
' Note, for this client to work you need to have a TcpServer
' connected to the same address as specified by the server, port
' combination.
Dim client As New TcpClient(Server, Port)

' Translate the passed message into ASCII and store it as a Byte array.
Dim data As [Byte]() = System.Text.Encoding.ASCII.GetBytes(message)

' Get a client stream for reading and writing.
' Stream stream = client.GetStream();
Dim stream As NetworkStream = client.GetStream()

' Send the message to the connected TcpServer.
If WriteData Then stream.Write(data, 0, data.Length)

' Receive the TcpServer.response.
' Buffer to store the response bytes.
data = New [Byte](16384) {}

' String to store the response ASCII representation.
Dim responseData As [String] = [String].Empty

' Read the first batch of the TcpServer response bytes.
Dim bytes As Int32 = stream.Read(data, 0, data.Length)
SocketsClientReadWrite = System.Text.Encoding.ASCII.GetString(data, 0, bytes)
'Console.WriteLine("Received: {0}", responseData)

' Close everything.
stream.Close()
client.Close()
If SocketError Then ResetErrMsg()
SocketError = False
Catch e As ArgumentNullException
SocketsClientReadWrite = ""
SetErrMsg("Ethernet sockets client error (ArgumentNullException)" & e.Message, False)
SocketError = True
Catch e As SocketException
SocketsClientReadWrite = ""
SetErrMsg("Ethernet sockets client error (SocketException)" & e.Message, False)
SocketError = True
Catch ex As Exception
SocketsClientReadWrite = ""
SetErrMsg("General ethernet sockets client exception; " & ex.Message, False)
SocketError = True
End Try
End Function

 

XML isn't a actual protocol in itself. It's a way of making custom protocols using ASCII text. Unless you know the actual format required, being able to do XML isn't going to help much.

XML is basically ASCII (or Unicode) text with "tag" names enclosed in angle brackets. Anything that can output arbitrary ASCII characters can output XML. Parsing (interpreting) it is a bit harder, but that is true for any sort of message.

 

I've read your message again, and I have a question. You said you are developing a custom application, but that the incoming data must be in XML format. Why?

If you can decide the data format, your best bet is to use Modbus/TCP. There are lots of instruments that talk Modbus/TCP directly. There are lots of inexpensive analogue to Modbus/TCP converters. There are lots of Modbus/TCP drivers for PCs (including many free ones). It's an open protocol which is as close to being the industry standard as anything else is.

If the problem is that you are using a controller that has a proprietary XML protocol, then you are pretty well stuck with whatever the vendor decides to let you do. In that case you need to contact them for more information.

 

Hey guys;

First off all, thanks a lot for all the comments.
Very helpful.

Let me clarify a few things.

First, as Ken asked, a delay off a few seconds to get the results won't be a problem for us.

This is my initial idea (from who have experience building applications but not a lot with automation):

We will build a custom ASP.NET web application and use it as HMI and to provide statistics, reports, graphs and stuff like that.

The application will be running on a Win 2008 server (inside the office) and will be available to all workstations.

The application itself wont talk directly to the sensors, it will read the values from a MS-SQL database. The reason is if o the future we change something on the hardware (sensors, communication, etc), we don't have to touch the application.

A Windows Service would be reading the sensor values at pre defined intervals and recording the values on the database, on a human readable way, like (each value correspond a one field on the table):

Tank 1 - 09-16-09 12:30 AM - 5 meters

WHY I ASKED FOR XML?
As you can see, I'm kind of new to this type of solution and i though that if i get a gateway/bridge to provide me XML over HTTP, it would make my life easier, since it's pretty easy to parse XML with VB.NET/C#.

So, my job would be parse the XML and record the values to the database.

Bu the idea of use Ethernet to connect the sensors and read the values using .NET is just amazing, however, I'm seeing a few advantages:

1- Each adapter cost aprox $200 (a total of an extra $1600 to the project - 8 tanks, 8 sensors - the cost of a Good PLC)
2- If I'm not mistaken, we will need one Ethernet cable from each sensor to the network switcher.

As for the Griffin's idea of an Modbus/TCP solution, how would be the wring for that? Also, do i still need a converter from serial to Ethernet on each sensor?

Once again, thanks a lot for the comments.

 

So, what the problem really is that you have some sensors in the field and you want to bring the data back to a custom application on a PC.

For a Modbus/TCP solution, here is an example:

Part: Advantech ADAM-6017-BE
Analogue inputs: 8
Type: mV, V, or mA
Digital outputs: 2
Price: $315

That is just an example. There is lots of other hardware on the market. There are also lots of instruments which have Modbus/TCP built right into them. This is the closest thing there is in the industry to a standard protocol.

As to how the wiring would work, that depends a lot on the physical layout of whatever it is you are monitoring.

If the tanks (if that is what you area measuring are not very big and are close together, you can run the analogue wiring to a single point. When I say "close together", I means distance in terms of wiring run.

If the distance is further, then you would want one I/O module per location so that you are not trying to run analogue signals a long way. In either case you would need to run an Ethernet cable to each I/O module to a switch, and then back to the PC (possibly via existing network infrastructure if that is appropriate). If the distances are long enough, then wireless might also be an appropriate solution.

You are balking at $200 for I/O hardware, but I'll point out that junction boxes, conduit. wiring, and electrician man hours aren't exactly cheap either. If you are not familiar with this, you had better get someone who is familiar with designing instrument wiring installations to advise you on this. If there are any explosive or flammable liquids or vapours involved, you are going to need someone with experience in designing for that area.

The I/O modules are Modbus/TCP servers (field devices are always servers). Back at your server, you would run a program that acts as a client to poll each of the field I/O modules. There are lots of solutions for the Modbus/TCP protocol, so you have lots of choice in this area. I will get back to this point later.

As to the software you are using, I noticed that you are balking at spending money on good hardware, but have no problems laying out even more money on what is some pretty expensive software. MS Windows 2008 Server, MS SQL Server, IIS, ASP Dotnet - if you are licensing that correctly for this sort of application, then that stuff isn't cheap. You can get stuff that is a lot better than that for a lot less money (down to no cost at all). That is something to keep in mind when you are looking at your budget as a whole.

As for Modbus/TCP, I have a free/open source software project at:

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

The web page for the project is:

http://mblogic.sourceforge.net/

One of the packages there is called "MBLogic" (the project as a whole is also called MBLogic). MBLogic is a complete soft logic control system. From your perspective what is of interest about it is the communications systems. It has the ability to run multiple Modbus/TCP clients in parallel. It also has several server protocols which other programs can read from and write to.

You could configure it to have it open a separate Modbus/TCP connection to each of the field I/O modules and have them poll the data. The data would then go into a common "data table" (array of memory).

You then have several possibilities to connect that to your own application. Since you mention that you happen to be fond of XML, I will point out that MBLogic has an XML web service protocol that is meant for these types of applications (integrating with other programs). It uses similar concepts to Modbus, but is a REST type web service with the data formatted in XML.

There is a description of this protocol on the web site listed above. Look under MBLogic - Communications - MB-REST Web Service Protocol for the protocol itself, and MBLogic - Communications - Modbus/TCP Basics for information on how Modbus/TCP works. The same documentation ships with MBLogic itself, and is available via a built in web interface.

There is also another JSON based protocol, but the documentation for that isn't finished yet. Let me know if you are interested in it.

The system also has a built in web based monitoring system, so you can monitor the state of the communications via the web interface. I have just made a new release and the SourceForge web site is not yet up to date, so check the documentation which ships with the system for any changes.

There is also a built in web based HMI with live graphics, but I don't know whether that would fit in with whatever you are doing.

MBLogic is free, and comes with complete source code. It runs on both MS Windows and Linux.

To sum this up:

1) Analogue from the sensors to one or more Modbus/TCP field I/O devices (converters). Or, use instruments with built in Modbus/TCP.

2) Ethernet from the I/O devices to your application server.

3) Have someone who is familiar with field instrumentation advise you how a practical and economical installation would be designed (including labour, wire, conduit, power, etc.). This is usually site dependent. However, as a general principle you want solutions that require as little installation work (including wiring) as possible.

4) Run some software on your application server which polls the field devices using Modbus/TCP, and makes this information available to your application.

5) MBLogic might be suitable for the above. If not, let me know what it is that it doesn't do that you need, and I might be able to come up with a different suggestion.

 

Unless your tanks are right on top of each other you will probably have a fair share of cabling one way or the other, whether it is Ethernet or 4-20mA loops. If you can find a device that takes 8 analog inputs and can talk Modbus/TCP you are all set. Doing it in one device, PLC or otherwise with Modbus allows you to reduce your communication if you are polling all sensors at once. This is because you can read information with one Modbus read request from multiple 16 bit registers. So in one fairly small TCP packet response you will get your data. Maybe EZAutomation or AutomationDirect has a pretty low cost solution. Just make sure when you are looking that the communication can support Modbus/TCP as a fair share of them support the serial version of Modbus (RS485 I believe).

The thing that is good with Modbus/TCP is that you can download the spec and also download a C#.net library for accessing the data. So when you or your colleague writes the windows service you don't have to deal with bloated driver software that is purchased. You might be able to even download or purchase such a program for reading Modbus values and writing them to your SQL database, although for a good programmer the whole things should be trivial.

KEJR

 

Hi Griffin,

Thanks a lot for all this information.

I took a quickly look at the open source project and it's definitely very interesting. I will spend more time with it on the weekend.

I have to agree when you say Windows is not a cheap solution. We can cut some costs with SQL Express or MySQL but it's still Win 2008 and will always be more expensive than Linux.

The thingy with Microsoft stuff is, we have Microsoft Certified people available (Windows Networking and .NET development - including myself) and we already have a Win 2008 server running, so, even though it looks (and is) expensive, now, it won't cost us anything.

As for the wires, we will have an electrician doing that. I'm just asking because I'm starting to like this 'automation business' and would like to know more about everything (also, to setup my lab with some low const sensor - gotta have something to play with at home for the times my wife is out)

So, when Ken says:

[...] If you can find a device that takes 8 analog inputs and can talk Modbus/TCP you are all set [...] you can read information with one Modbus read request from multiple 16 bit registers. So in one fairly small TCP packet response you will get your data [...]

I believe the Advantech ADAM-6017-BE (suggested by Griffin is one of them, right?

I assume the device (ADAM-6017-BE) will have one IP and i will send and receive requests specifying the device ID.

Do you know where can i get the C# (or VB.NET) library?

 

The Advantech ADAM-6017-BE does have 8 analogue inputs in a single module. You would read each of those analogue inputs as different registers.

I have a brief explanation of the Modbus protocol on my project web site at:

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

(Watch out for any spaces the forum may have inserted in that URL).

You might want to read this to get an understanding of Modbus. After you have read that, you will be able to understand Advantech's (or anyone else's) manual for this device. If you have any problems understanding any of that, let me know and I will be happy to answer your questions.

As for a library for C#, try NModbus (you should be able to find this with Google). I haven't tried it myself, but it seems to be the most popular one that is in C#.

 

Sorry if this sounds too commercial but we might be able to help you. We (AVIDwireless http://www.avidwireless.com) sell the AVIDdirector-M2M and our SmartSensor wireless sensors. If your sensors also have an analog output you can use our 0-5,0-10 or 4-20 ma wireless sensors to send the measurements from your tanks to just one of our AVIDdirectors, that can communicate using M2M-XML over Ethernet, WiFi, Cellular or Satellite to your backend ASP.NET system.

M2M-XML is a multi-vendor supported XML protocol for M2M/Sensor data collection and control. As you mentioned using XML makes the backend implementation much simpler than an ASCII or Binary protocol. Another contributor mentioned the cost of wiring connections which the wireless SmartSensors help to overcome. They work either at 418 MHz with a 600 ft range or 900 MHz with a several mile range. Or you could wire the sensors using analog or RS-485 into the AVIDdirector if the wiring isn't an issue.

 

In reply to Rod Montrose: You've called M2M-XML a multi-vendor protocol, but who else is supporting it, and what industries is it used in? I just did a Google search, but I wasn't able to turn up much information on it. I can find a couple of XML parsers for it, and a few old blog posts, but no information on products that use it (other than a $1000 dev kit on your web site).

I've got a copy of the spec, but I haven't found much evidence that this protocol used very much. The web site for the M2MXML group has lapsed and now belongs to a domain name squatter.

 

The simplest way to do this is to have a data logger at site. Connect all level instruments to it through 4-20 MA signals. Take data logger on LAN through thick Ethernet and connect to PC where you can view all signals by installing Intellution Fix View or wonder ware or any such software in your PC.