Multi-cast Modbus/TCP

L

Thread Starter

Lynn Linse

Just a new idea to kick around - Modbus/TCP doesn't include multi-cast support, but does anyone see value in the LinuxPLC supporting this?

It would allow each LinuxPLC to "multi-cast" a block of data (publish/produce it) to a group IP, and the other LinuxPLCs would accept these as desired (consume them). It creates a virtual global data table which is updated effectively a few times each second.

Any interest in this?

Best Regards

Lynn August Linse, Senior Product Application Engineer
15353 Barranca Parkway, Lantronix Inc, Irvine CA 92618
[email protected] www.lantronix.com
Tel: (949)450-7272 Fax: (949)453-7132



_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D

Davis Ray Sickmon, Jr

Hmm - actually, I could see a good reason for doing something like this for use by the MMI's too. Instead of replying to individual requests, it multi-casts all of the requested data (with the exception of anything that's 'secure' data) from all of the MMI's, and they take what they need. Unless someone sees a flaw, that would reduce the bandwidth requirements (which has been a concern on more than one occasion for me) and the number of requests that the LinuxPLC has to respond to (IE - only doing one multi-cast for 9 MMI stations instead of 9 replies.)

Just a thought.

Davis Ray Sickmon, Jr
http://www.midnightryder.com


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
L
You are right. The only "real" catch is:

1) not all routing schemes properly support (or DESIRE) multi-cast. For example your HMI may well be on a different subnet so require the bridge/router to forward the multicast messages.

2) not all environments support multi-cast (does Windoz or most HMI?).
However, I cannot think of ANY environment BETTER suited to "Modbus/MCIP" experiments than Linux.

I'm thinking about this now because I have to do some work with GE-Fanuc which uses Multicast for the EGD (Ethernet Global Data). Their controllers,
remote I/O, and HMI use this to move data.

Two ideas:

1) In Modbus/MCIP we could just do "broadcast" (Unit Id 0) Modbus function 16 writes to a group IP. Each Modbus/MCIP node would create a single table to collect any of these writes into with no reply. The implementer would be responsible for coordinating the write addresses from various nodes.

2) In Modbus/MCIP we could do standard Modbus function 16 writes and use the Unit Id as the "table Id". This would simplify the handling of "stale" data, as each table would need some form of time-out to notify the local node if the source stops sending new data. Besides the support for various group IP, each node could accept or ignore data based on table_id/unit_id received. Again, the implementer would be responsible for coordinating the table assignment between the various nodes.

Or we could include a system sync'd timestamp so each node can judge the age/quality even if the data is stale. Maybe we could reserve the first word (or 10 words) of each table for things like age in msec, source IP etc.

Has anyone looked at using NTP to sync the LinuxPLC clock to a NTP server? I'd assume this is a fairly standard Linux utility.

I prefer the 2nd method.


Regards

Lynn August Linse, Senior Product Application Engineer
15353 Barranca Parkway, Lantronix Inc, Irvine CA 92618
[email protected] www.lantronix.com
Tel: (949)450-7272 Fax: (949)453-7132


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D

Davis Ray Sickmon, Jr

> You are right. The only "real" catch is:
>
> 1) not all routing schemes properly support (or DESIRE) multi-cast. For
> example your HMI may well be on a different subnet so require the
> bridge/router to forward the multicast messages.

Aye - but that can also may have to be faced in some larger LinuxPLC control networks.

> 2) not all environments support multi-cast (does Windoz or most HMI?).
> However, I cannot think of ANY environment BETTER suited to "Modbus/MCIP"
> experiments than Linux.

Windows supports Multicast. As for the MMI's themselves, well, that's a matter of drivers. The MMI's themselves (the ones I work with anyway)
don't concern themselves with communication with the PLC, but instead, a communiation with a driver. The driver has to worry about talking to the PLC. If the LinuxPLC supports Multi-Cast, then pretty much garanteed that the MMI's drivers will support Multi-cast. (Ok, well, I can only really speak for Jaguar MMI on this one.)

<SNIP>

Davis Ray Sickmon, Jr
http://www.midnightryder.com



_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
L
> From: Davis Ray Sickmon, Jr [mailto:[email protected]]
>
> > You are right. The only "real" catch is:
> >
> > 1) not all routing schemes properly support (or DESIRE) multi-cast. For
> > example your HMI may well be on a different subnet so require the
> > bridge/router to forward the multicast messages.
>
> Aye - but that can also may have to be faced in some larger LinuxPLC
> control networks.

A router which supports multi-cast (per RFC1112) will also support the IGMP (Internet Group Management Protocol). This means it broadcasts periodically a "Who wants any multicast traffic?" message, and the LinuxPLC/HMI would need to reply with the group IP they desire. That way the router only forwards multicast traffic of interest to someone.

It sounds like if a WAN or the "wide-wide-world" was in between the LinuxPLC and an HMI, the user would need to run & config a multi-cast enabled router at EACH end and somehow the pair would tunnel/hide the nature of the multicast on the path between them. Info on Linux multicast (MBONE) & the mrouted which supports multi-cast are at:

http://www.teksouth.com/linux/multicast/applications.html

regards
- Lynn

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
I think if there is a "wide-wide-world" between the two, you shouldn't be using multicast.

You just load a different driver in the HMI and a different reverse-driver in the linuxPLC, which use a connection-oriented protocol.

Presumably the multicast would be intended for local situations, where you have /n/ screens around the place, showing different views of the data, and you don't want the overhead(*) of sending the data separately to each.

(*) both network-traffic and configuration-effort

Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top