Need help selecting hardware/protocol combo for interactive installations

D

Thread Starter

Damon Seeley

Dear Experts,

Our design firm produces interactive installations in public places. We create spaces where people can interact with lights, media and other people in new ways. Much of our work features LED lighting and sensing. You can see samples here if interested: http://electroland.net

We have several new projects and want to make an investment in an industrial-grade automation technology for collecting sensing data, and perhaps controlling various widgets using digital or analog output. We recently completed an installation using Beckhoff EtherCat fieldbus boxes for data collection, and while we like the hardware a lot some aspects of the protocol are not desirable for us.

Here is our wishlist for a combo of hardware and protocol:

* Provide various IO in wet and dry locations
* Communicate with IO points from Java, with as few layers in between as possible.
* Operate > 30Hz but likely not more than 50Hz
* Be switchable by common Ethernet hardware
* Coexist on physical media with heterogeneous devices (IP camera, laptop, etc)
* Possibly be routed/tunneled on other physical networks eg: VDSL for remote connectivity
* Possibly operate using a software-only master in Java
* Have a shallow learning curve for associates

In order to help define the problem I have diagrammed two common installation scenarios in this PDF file: http://bit.ly/hHgixj

Based on the above requirements it seems to us that a TCP/IP-based protocol is needed but we are open to other solutions. Please let me know if more details are needed. Any input is greatly appreciated.

Thanks!
 
C

curt wuollet

I think the place to start would be to assume a number of points to define throughput needed and then survey the protocols available on ethernet. Many of the industrial offerings would almost need an engine due to the way they work. That is, control directly from java might be speed bound at a given point count. It almost sounds like a job for some distributed intelligence to localize control where possible.

Regards
cww
 
I can't see your web site because it wants Flash, and I'm not installing Flash just for that. I did have a look at your PDF file with the block diagrams.

The protocol you are looking for is Modbus/TCP. It's an open protocol supported by many, many vendors. You won't find any other industrial protocol with as wide of a selection of suitable hardware. There are open source drivers for Modbus/TCP at the following URLs:
http://sourceforge.net/projects/jamod/
http://sourceforge.net/projects/modbus4j/

I can't recommend one in particular, as I don't use Java (I have an open source Python driver though if that is of any help to you).

The trade organization for Modbus is here:
http://modbus.org/

They have technical resources and links to vendors. As well as their vendor list, there are many other vendors which support Modbus but are not part of the organization. You might also want to try Advantech (ADAM 6000 series I/O) and Automation Direct (look for their Ethernet field I/O).

There are different forms of Modbus for different media. The one you want is Modbus/TCP. "Modbus/RTU" and "Modbus/ASCII" are for serial RS-232 or RS-485 networks and some people will "tunnel" the serial versions of the protocol over Ethernet. You want the actual Mdobus/TCP. As the name suggests, Modbus/TCP works over TCP/IP.

For operation in web places, put the module in a plastic (or metal if that is preferred) waterproof terminal box and use rubber glands on the incoming wires. That will give you the most flexibility in wiring sensors. That will also give you a place to put the power supply and fuses.

For the speed of the I/O, you will need to contact the respective vendors. I bench-marked the Advantech modules at less than 1 milli-second per poll (or more than 1 kHz), but some modules from other vendors will run as slow as 300 milli-seconds. You should be able to find a good selection of I/O that is fast enough as long as you are looking at factory automation I/O rather than process industry hardware (process industry hardware will generally run at slower rates, as they are dealing with flows and temperatures that inherently change slowly).

Most of the current hardware is 100 Mbit Ethernet, although there may be a few odd older bits around that are 10 Mbit. If you need IPV6 rather than IPV4, you may have to ask about this (I've never looked into that issue). Your networking person may be able to suggest a tunneling or proxy solution for that if you need it.

If you start going over WANs or VLANs, you had better check out what sort of hardware you are getting routed through. Your computer and I/O might be capable of enough throughput, but some network systems may add unacceptable lags at times of high load. You could ask a network person about that, and if they have any Quality Of Service (QOS) solutions for it.

There are certain vendors with proprietary or otherwise special protocols that will operate on Ethernet hardware and who will give you a nice sales pitch about their real time behaviour. However, those performance figures only hold true when you are operating on their hardware, with their controller and software, and their switches and routers end to end (and sometimes they even make their own chips to go in those boxes). That just isn't practical in this type of application unless you want to install your own isolated network.

Modbus/TCP on the other hand runs over standard Ethernet and goes through standard network hardware. "Industrial grade hardware" these days typically just means the form factors and power supplies are convenient for installation in machines and the product lines turn over more slowly. The actual technology is typically several years behind what you would find in the commercial or consumer market.
 
D

Damon Seeley

M Griffin, thanks for your excellent reply. This is all super-helpful. The more I read about Modbus/TCP the more I am convinced you are right. It seems to combine the right amount of functionality with learning curve. The automation direct devices seem very straightforward. I like that going this direction allows me to use units from lots of mfgs depending on install environment.
 
Top