Lynn's Industrial Protocols over IP

Friday, March 14, 2008

PCCC Protected Typed Logical Write with Mask

Someone asked about the "DF1 Supplement for SLC500" from 1995 which was online at ab.com for a short period, then was pulled - probably because it is a very poor quality optical scan. However, I had it ... then lost it ... then found it stashed away on one of my ftp sites.

So here is the original AB PDF (which I downloaded from ab.com last year) Grab it here while it survives.

The masked write is on page 11 and the first data-word is the mask and all data following has the SAME mask applied. So [0x0001,0x0000] would clear the LSBit and so on. It doesn't offer mask-data pairs - just one mask and N words. Thus this command is mainly for use with 1 word element writes ... unless you have three or four consecutive N-file words you wish having the same mask applied.

Labels:

Wednesday, April 25, 2007

Rockwell and Modbus Data Traffic

Summary: I compare the data costs for four common off-the-shelf PLC protocols to a remote cellular site. As a rule of thumb, even if you have an Ethernet-based PLC your lowest data costs for SCADA-style periodic polling are obtained using serial protocols via the PLC's serial port. Their modern "Ethernet protocols" are very wasteful of cellular bandwidth.

PLC Protocol Example:
A simple but realistic SCADA scenario is to poll every 15 minutes and read 10 words of data and write 2 words of data. This commonly requires 1 Read command and 1 Write command (I'll ignore the rarely supported Modbus command that reads & writes within a single command.)

While there exists special SCADA protocols and special products that optimize remote traffic, I am not looking at those protocols at the moment. Instead, since cellular and satellite access to remote IP and Ethernet products has enabled people to use off-the-shelf PLC technology, I am looking at the more traditional PLC protocols. These are things which affect users when they apply an Ethernet design to an IP-based wide-area-network system.

I compare these 4 PLC protocols:
  • AB/DF1 Radio Modem (RM) encapsulated in UDP/IP. DF1 RM is basically DF1 Full-Duplex with no ACK/NAK and is supported by the SLC5 and MicroLogix line.
  • Modbus/RTU encapsulated in UDP/IP. Modbus/TCP within UDP/IP is roughly the same size.
  • AB/CSPv4 in TCP/IP as supported by SLC5/05 and PLC5E MSG blocks.
  • AB/Ethernet/IP as moved by ControlLogix Explicit MSG blocks to PCCC-based remote PLC. Note that Ethernet/IP "I/O Messaging" does NOT work through NAT'd wide-area-networks since the protocol embeds IP information within the data packets and is thus is "broken" by NAT.
The bytes per 15 minutes includes the IP headers, any PLC protocol overhead, and the actual data moved for each update (always 20 + 4 bytes). The MB per month is just defined by 30 days of such polling, or 2880 updates at once per 15 minutes. The 2 serial protocol have been encapsulated into UDP/IP and I assume the remote IP end-point can handle connecting this to the PLC's serial port.

ProtocolTransportPer 15 MinMB per monthRelative Cost
Ethernet/IPTCP/IP1202 bytes3.46 MB100%
AB/CSPv4TCP/IP960 bytes2.76 MB80%
Modbus/RTUUDP/IP166 bytes0.48 MB14%
DF1 Radio ModemUDP/IP194 bytes0.56 MB16%

The two Rockwell "Ethernet" protocols cost a lot more to use in part because they force use of TCP/IP, and therefore suffer the repeated cost of TCP socket opening and closing, plus extra TCP acknowledgment overhead. They also suffer because they both involve connection registration and service functions that needlessly repeat every time the connection is reestablished. While the actual data packets of these protocols are roughly twice the size of the serial encapsulated protocols, the real burden they suffer is all the extra TCP/IP packets exchanged that do NOT directly involve field data update.

Both the serial Modbus/RTU and DF1 Radio Modem benefit that they move no IP packets that don't relate to the field data update - no TCP/IP open or close or acknowledgement; no protocol "service function" overhead. Each moves just 1 read request and 1 read response, plus 1 write request and 1 write response.

Discussion of Other PLC Protocols:

Most other PLC Ethernet protocols will either approach the costs of the AB/CSPv4 - or they won't work at all due to use of direct "Ether-Types" and lack of IP compatibility. Most serial protocols with roughly either match the 2 show here or be twice the cost if protocol ACKs are used by the protocol.

Modbus/ASCII will almost double the cost of Modbus/RTU since each data packet is roughly twice the size. But this wouldn't increase the IP overhead any.

Using DF1 Full-Duplex instead of Radio Modem would effectively double the cost over DF1 RM since DF1 Full-Duplex moves the protocol ACK/NAK, which doubles the IP header overhead also. Using DF1 Half-Duplex would triple or even quadruple the costs since HD not only moves protocol DF1 ACK/NAKs, but the ENQ/EOT polling overhead.

Most other protocols I am aware of - such as Omron Hostlink, GE-Fanuc SNPX, and Siemens PPI - would cost roughly 2 to 3 times more than Modbus/RTU or DF1 RM since they include protocol ACK, while a few even encode many parts of the message as ASCII or BCD form instead of as binary.

Labels: , , ,

Monday, April 16, 2007

DF1 Open Source for Visual Basic 2005

Archie has started a SourceForge project for his AB DF1 code running under VB 2005. He has checked in a full first set of files (unlike many SourceForge projects which get created but NEVER have files :-\ )

http://sourceforge.net/projects/abdf1/

I haven't looked over his code yet, plus all I have is VB 2003 .NET.

Hopefully Microsoft has STOPPED the old VB issue that each new rev of VB is neither 100% forward nor backward compatible ... one always need to "tweak" a few lines to make the port work. I've used VB 1.0, 3.0, 4.0, 5.0, 6.0 and now VB 2003 and none of these have liked old code being pulled forward.

Labels:

Wednesday, January 03, 2007

Rockwell Bridging - Ethernet to DF1

Question: We have a MicroLogix 1500 with only 1 serial port. What Digi product can we use to enable Ethernet access from RSLinx or a HMI display?

The Digi One IAP allows bridging AB protocols:
- Ethernet/IP Master (such as ControlLogix) can query DF1 PLC
- CSPv4 Master (such as RSLinx, PLC5E or SLC5/05) can query DF1 PLC
- DF1 encapsulated in TCP/Ip (such as OPC server) can query serial DF1 PLC
- Modbus Master (TCP, RTU, or ASCII) can query DF1 PLC as-if a Modbus slave.

All of these can function concurrently, as the serial port is moving pure DF1.

The Digi One IAP cannot support DH485 because (like ProfiBus) the token rotation is too fast to be encapsulated over Ethernet successfully.

The general Rockwell Bridging is discussed in this PDF file:
http://ftp1.digi.com/support/documentation/90000636_a_doiap_ra_bridge.pdf

Quick comparison of Digi One IAP to the 1761-NET-ENI:
ProductDigi One IAP1761-NET-ENI
Ethernet/IP to DF1 FullDuplexYESYES
CSPv4 (PLC5E protocol) to DF1 FullDuplexYESno
Modbus to DF1 FullDuplexYESno
DF1 encapsulated in TCP/IP or UDP/IPYESno
DF1 by port redirectionYESYES
Supports DF1 Radio ModemYES (next release "H")no
Maximum active Masters/Peers644
Configuration by WebYESno
Configuration by Telnet or SSHYESno


Basically, the Digi One IAP does everything the 1761-NET-ENI does (plus much more) except:
  • The Digi One IAP does NOT handle CIP encapsulated within DF1, which is required only for RSLinx to CompactLogix RS-232 port
  • The Digi One IAP does NOT have emails triggered by PLC MSG blocks
  • RSLinx won't talk Ethernet/IP through the Digi One IAP - it will talk "Ethernet Driver" fine. This is *NOT* related to existance of an EDS file. RSLinx talks via the 1761-NET-ENI because it is hard-coded to treat the ENI special. There is no EDS file information which RSLinx examines to function with the ENI.

Labels: , , ,