DCS Modbus (and other digital) communications

Hey there,
Our plant has a Bailey Infi 90 system, and that's the only system I know well. To talk to a modbus device with an Infi 90 there are a couple things
you need:
1. A Processor Module, this would be a Multi-Function Processor or a Bridge Controller (15-20K CDN) 2. Software. This can be done 3 ways: Write a C Program to talk to the devices, use a DOS based program that you just "fill in the blanks" and the C Program is built automatically, or use the new Windows based GPI (General Purpose Interface) software (I believe this is the only one supported currently ).
To use the Windows based GPI software it is of course licensced. It's liceneced by points/Processor Module. The smallest (1500 points) is around 7K CDN for the license. If you have a large plant like we do, and DCS nodes, as well as Modbus devices are spread throughout the plant, it makes it tough to bring everything through 1 licensed module. So it wouldn't be hard to have a few GPI modules in a plant that are not even close to being fully utilized (1500 points is a lot)
So my question is how do other DCS manufactures do it? (Bailey can only do Modbus, and DH+ as far as I know) The only thing I know is that Fisher Delta V has special modules for Modbus, ASI, DeviceNet, ... Are these modules big $, and is there licensing on them as well?
In our plant, we have a lot of devices that can communicate Modbus, but I don't see how it can be cost effective when licensing is set up the way it is.
Thanks for any insight.
Curtis
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hi,
Another opportunity would be the use of IMPCC01 modules. We have quite a lot of these modules in use, to interface PLCs via Modbus/RTU protocol.
If you have OperateIT and your modbus devices are PLCs, OPC could be another solution.
regards: -Serge-
Curtis wrote:

blanks"
based
It's
module.
only
Are
but
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Generally Modbus devices have a RS232 or RS485 port, or even an Ethernet port.
This way you can connect one interface to do the integration between them.
See following one example a really neat solution based in one single device:
https://www.smar.com/products/MB700.asp
MB700 has:
- one RS232 port - one RS485 port - one Ethernet port
You can connect device in the RS485 port and Ethernet for example and they can communicate between them.
Flavio
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Curtis,
Do you have an Ethernet LAN available throughout the plant? An isolated automation LAN is preferable, but using the same LAN as everyone else will do. There are bridge modules available from several manufacturers that will convert between RS232 or RS485 serial Modbus and Modbus/TCP. You need one connected to your Infi 90 processor port (Modbus slave) and one for each Modbus capable device (Modbus master). If you're lucky, there will be several RS-485 capable devices close together that can share a single bridge. You may even find that some parts can be upgraded to built-in Modbus/TCP capability for less than the cost of the bridge. The bridge at the Infi 90 has a routing table that directs each Modbus address to a TCP/IP address, which is the address assigned to the remote bridges. The remote bridges then route the Modbus message to the address in the message. Your limit is only the number of Modbus addresses, 254, or whatever the Bailey software allows.
There's another option, that becomes cost-effective if you have at least four or five Modbus Plus capable devices that can be networked. Schneider/ Modicon makes an Ethernet/Modbus Plus bridge, p/n 174CEV30010. This has routing tables in both directions, again limited only by the number of Modbus addresses.
I've used both, and they work well once set up. Next time, I'd rather have real Ethernet-capable controllers in the budget.
Mike
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.