Allen Bradley Pyramid Integrator


Thread Starter

Niall Watson

Dear List

Can anyone explain the following:

On an AB PI installation, with multiple (8) DH+ Link IDs -

1) Is there an individual "token" for each link ID?
2) How does a remote message (between Links) get passed?
3) Does the KA module "buffer" messages while waiting for the token?
4) How does the Ethernet module handle the DH+ routing?

Any other information on this subject would be most appreciated.

Thanks in advance

Niall Watson
PES Automation Ltd

[email protected]
Hi Niall:

I'll try to explain the areas I am familiar with. I hope it proves useful...

> On an AB PI installation, with multiple (8) DH+ Link IDs -
> 3) Does the KA module "buffer" messages while waiting for the token?

Yes, all DH+ traffic is buffered. Also, in the case of multiple "waiting" messages, there is no explicit guarentee that all messages will make it out while the token is captured by the module/channel. This buffering is necessary
so that the ladder can continue to scan without waiting for the message to transmit or for the response to the message to be received.

> 4) How does the Ethernet module handle the DH+ routing?

DH+ routing from Ethernet is handled directly from the header of the data packet. Consider the following "C" structures...

struct ethernet_header
byte mode;
byte submode;
unsigned short pccc_length;
unsigned long conn;
unsigned long status;
byte custom[16];
byte df1_stuff[255];
} enet;

struct custom_route
unsigned long request_id;
unsigned long name_id;
byte pushwheel;
byte module;
byte channel;
byte protocol;
byte flags;
byte junk[3];
} route;

When an Ethernet message is to be sent out DH+ on a PI, enet.mode is set to 1 (command), enet.submode is set to 6 (DH+ Route), enet.custom[16] is filled with the "route" structure (memcpy (&enet.custom, &route, 16)), then enet.df1_stuff[255] is filled with the DF1 command to go out onto the selected DH+ channel.

Have I confused you yet? :)

Ron Gage - Saginaw, MI
([email protected])

Michel A. Levesque, ing.

Here are some answers for you:

1. Yes, each link has individual tokens, if a common token was used you wouldn't need link ID's.

2. The message uses the local ID/address to pass to the remote ID/address, this is defined in the MSG instruction. The mechanism is the same whether you use PI KA modules or standard KA
modules (with a DH link between them) The differences are that PI KA use a "channel" rather than the DH network. The "channels" can be seen as a virtual DH.

3. The KA modules buffer the data, the same must be done by all PLCs on DH+. Keep in mind that the communications are asynchronous to the actual ladder program scan...thus buffering is a necessity.

4. It doesn't...the KA modules do routing between each other, the Ethernet module is a gateway to give access to DH+. Routing functions and gateway functions are different since a gateway must do protocol conversions on top of finding the path to the proper destination. PI KA modules do not keep routing tables in memory. The path is
explicit in the message headers (ID/address). The Ethernet module uses the message headers to find the right channel, then it sends the message to the remote ID/address. The "remote" KA buffers the message while waiting for thetoken, then the KA pitchs the data on its "local" DH+ to the right address.

Michel A. Levesque eng., mcp
Directeur Bureau Montreal
AIA Inc.
[email protected]

We have a Citect SCADA system communicating to AB PLC5's and SLC500's through two PI's via multiple DH+ Links. Each PI has the RM module and two KA cards NO 5/250 Logic processor is installed, we use the PI as just a Ethernet/DH+ gateway.

These are my observations only:

1: Each DH+ (RM or KA) channel sits on the network of that physical cable, it has time with the token like any other node (PLC) on that network. You must configure the channels on these modules to use DH+/DHII/Serial DF1 etc.

2: To send remote messages you need to setup the "Link ID" table in the RM module you use the 5/250 software to program each RM or KA DH+ channel with a Link ID.

You can then use this when programming PLC message instructions to route between DH+ networks.

3: Good Question . I would imagine they get buffered until its time with the Token comes around when it can then send them.

4: The Ethernet Module appears always as one DH+ node number higher than the RM module.

EG: If you have got CH2A of a RM at DH+ node 3, then the EI module will show as being at DH+ node 4.

How the EI module actually does the routing I dont know, but this is the general setup for our system:

Normally with the MMI system (say Citect) you have a Allen Bradley driver that is supported
over the TCP/IP interface of the EI module. So you configure your system to Know the IP of the EI interface (comms port), and then you configure the communications unit for a particular I/O device on that port. Within Citect the addressing syntax is for example "0RM:2,32" which equates to RM Module, DH+ Channel 2A, Node number on link =32.

If you want more details on things Like BOOTP for the EI module, and configuring RSLINX to communicate to PLC's through the PI EI drop me a line.
I'm no expert but I've set a couple up and they have been working reliably for me !


Neil Firmin
Technical Officer
Yallourn Energy Pty Ltd