Communications between a PLC and XML device?


Thread Starter

Walt Flannigan

It's an oddball application, seems like my specialty. Has anyone done this, or found a device that will help do it, without going super custom? I'm not stuck on a PLC, I'm looking to interface any kind of controller.
What is an "XML device"? I've heard of XML as a data format, but I haven't heard of a hardware device called "XML". If this is the model name of some vendors' hardware, then I think you need to state the brand name so that people will know what you are talking about.
Opto 22's PACs will do it. They're able to parse XML coming into their Ethernet ports.

I gather the Crossbow device streams XML, so you need a device that'll capture the XML, parse the data you need, and then perform some other tasks, perhaps even control related. The SNAP PACs will do exactly that.

Standalone controller:

Rack-mounted controller (if you need on-rack I/O):

The software to do it (free download):

Number to call to talk with a pre-sales engineer about your application (also free):
800-321-6786 (OPTO) or 951-695-3000

After-sales product support should you need it (yep, free):
800-835-6786 (OPTO) or 951-695-3080

Good luck with your project. Sounds like a cool app.

From what I can see, the "gateway" is actually a server running a web application. It's a diskless computer with an ARM CPU running Debian Linux with a couple of proprietary server applications. The servers monitor the sensor network (via radio) and provide an HMI via a web interface. The only reference to "XML" that I was able to see is that their sensors use XML files to define the sensor characteristics for the server.

I didn't see any information about a protocol to let you talk to the server. I don't know if you can even screen-scrape the web interface, as they seem to use a lot of Flash.

Unless you know of something that I've missed, I think you will need to contact the manufacturer to ask if they have a protocol that will let you talk to their server program.

Walt Flannigan

I'm working with Crossbow right now on a solution. They'll help me at least, as long as I come up with a suitable controller. I like the Opto 22 solution...Thanks to all!
In reply to Benson: You said: "you need a device that'll capture the XML, parse the data you need, and then perform some other tasks, perhaps even control related. The SNAP PACs will do exactly that."

I had a look at the links you provided, and I downloaded the manuals. I couldn't find any mention at all of XML, let alone any XML parsers. The string handling functions don't even do regular expressions, so it's not as if you could do a regex search to avoid parsing either.

How is your suggestion supposed to work? If there is a way of doing it, it wasn't obvious. He could of course write a complete XML parser from scratch using low level string functions, but I don't think that is what he had in mind.
XML isn't a protocol or even a format that is defined in detail. It's just a way of marking up text. XML is "document" oriented. That is, you generally need the whole message to parse it correctly.

For example:


The above is some very simple XML. If the format is consistent, then you can extract the data you want using string functions in a PLC. I will give you an example using the Koyo (Automation Direct) "Click" (other PLCs can do the same thing, but I have the docs handy for this model). The Koyo Click can do string searches for entire strings (not just single characters), which makes this easy. I will leave the angle brackets out of the XML tag names in the following example as it seems to confuse the mail interface, but just assume they are there.

First, you have to get the string into the PLC. If you clear the buffer, then you could search for "/sensor1" to see when you have the entire message in.

Next, you search for "pressure" and "/pressure" and get their location indexes. The data will be located in between those two.

Finally, you repeat the search with "temperature" and "/temperature".

The above assumes the XML message is very simple and predictable. XML tag names are just markers for each data item. The leading marker can be any string, but must be enclosed with angle brackets. The closing marker is the same as the leading marker, but has a forward slash "/" character in it.

Where you run into problems is when they use huge XML documents with deeply nested structures with the same tag names used repeatedly in different contexts. If that is then case then you probably need a PC program using an XML parsing library to extract the data.

So, in the end the question comes down to what the data actually looks like.
Greetings MGriffin- First off, my apologies for a long post (exactly what I was trying to prevent in my first response).

If you weren't able to find a single trace of XML in the docs, that unfortunately means Opto did a great job eradicating the term. If you've followed this board for as long as I think you have, you'll know why that was done.

Perhaps another reason you won't find XML gateway instructions in the Opto docs is because XML is not necessarily a mainstream app. IMHO, PACs are very sophisticated industrial controllers with capabilities that reach outside of the typical PLC realm, and as such, act more like a PC. By that I mean PACs are a tool that allows a creative programmer or engineer tackle unique applications. Documenting every application possibility or use would be difficult, particularly those apps that fall outside of the so-called mainstream.

Getting to the task at hand, string handling is best done using the built-in OptoScript language in PAC Control (rather than flowchart blocks). Check out the script samples for string and file handling, including comm handles, and you'll get a better picture of how it's done in Opto world. A very basic example from the included PAC Control software samples and online documentation:

// The + operator is used to paste strings together.
// The + operator must be used in an assignment statement.
s1 = "Hello ";
s2 = "world";
s3 = "!";
s4 = s1 + s2 + s3;
s4 = s1 + "world" + s3 + "!!";

// The Chr() operator may be used to convert a numeric value into
// a one-element string.
s5 = s1 + s2 + Chr('!');
s5 = s1 + s2 + Chr(33); // use the ASCII value 33 for '!'

// The += operator may be used to appended a string or character
// to the end of a string.
s1 += s2; // Append s2 to s1
s2 += Chr('a'); // Append the letter 'a' to s2

And a bit more specific to finding chars in string elements or tables:

// This is a function command; it returns the position at which the
// character is located in the string.
// FindCharacterInString(Find, Start at Index, Of String)


// This is a function command; it returns the position at which
// the substring starts within the string.
// FindSubstringInString(Find, Start at Index, Of String)


// The following example gets a single day from the string “MONTUEWEDTHUFRI”
// GetSubstring(From String, Start at Index, num. Characters, Put Result in)


I recognize these appear rudimentary, but they are just a few examples. These types of string handling expressions were used to write all of Opto's free communication Integration Kits, including Modbus, DF1, DNP, and more.

You're also correct in that the control software does not include an XML parser for 2 reasons: one that is implied in the opening paragraph; and two, it's a bit of overkill. Normally, just a few characters are needed for these types of applications, such as a value, and a full-on DOM parser would over-task the controller with unnecessary processing. As such, writing an XML parser using low-level string functions usually isn't required, just a few operators here and there usually work.

An Opto customer in the golf course industry successfully (and quickly) performed VERY similar functionality with the Opto 22 PACs and the above commands and functions. That's what I understood Walt was looking for.

Finally, as indicated in my first post, pre-sales engineering and post-sales support are free and provided by experienced engineers. Help is a phone call away.

Best to you. -Benson

Tallak Tveide


The question itself tell me that you really don't have enough information (or have not given it to us) to make any proper decisions.

XML itself is not a format (as others have posted) and can not be mapped in a generic way to Modbus.

I cannot understand how anyone can even try to suggest equipment that will perform this task based on your minimal input.

Any PC (windows/linux/mac) will be able to perform this task in a general sense combining a xml library, a modbus library and some glue code (for example rexml and rmodbus using Ruby, all free software, or alternatives in C++, Python, c#, ...). This is probably not what you would want to do anyway. (And if someone suggest that you implement a XML parser using low level string functions... frankly I'm speechless. This would only be a last resort in my opinion)

Given that you are talking about converting XML to modbus, I would assume you are dealing not with a XML file but XML served for example from a web server using something like SOAP or XML-RPC, both based on XML. Even these protocols are at a higher abstraction level compared to Modbus, so some glue code is still required.

If you are looking for a product to convert between Modbus and some of the newer OPC standards based on SOAP, a more integrated conversion product might exist in that case.

My guess is that the whole conversion could be a wrong choice architecture wise.
In reply to Benson: When I read your first reply, I thought you had said that your controller had an XML parser. Now that I have read your original message over again, I see you didn't say that exactly, you just said it could search the string. In another reply which was published before yours, I had described how this could be done using ordinary PLC string functions provided the data was simple enough.

However, whether or not this is practical depends on how complex the XML document is. I would hesitate to recommend this method without knowing what the data actually looks like and how many alternative responses are possible.