If anyone is interested - here is the information I have on the ControlLogix Ethernet Protocol.

The PLC port is 44818, the communications form appears to be UDP. The packets are embedded ControlNet Packets (CIP). I am currently working with the ControlNet Consortium to persuade AB to release the protocol specs at least enough to be able to write a useful driver.

Not much, I know, but it is a start.

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

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

 

Hi Lynn:

On Tue, 18 Jan 2000, Lynn Linse wrote:
> The ControlLogix uses something called "EPIC" or "The Frameworks", depending
> on who you ask.
>

I have heard it called many things. It seems to be the AB's way to help keep
the protocol obfusicated. If the name is constantly changing, how on earth can
anyone request information on it - "Oh, Epic, that is obsolete. We have no
info in that."


> It uses TCP on port 44818, and a 24-byte header in front of some
objects. > One of those objects can be a DF1/PCCC packet embedded or something
they > call virtual-DH+ - another can be a CIP - (and I assume yet another will
be > the DeviceNet PDU for ODVA's new Ethernet spec). It requires first a
> negotiation phase - RSLinx & others will first issue some ListTarget,
> ListServices, and List??? something else before you go thru a session
> connect phase. Only after this can you exchange the data.
>

This doesn't sound too much different than the PLC5 ethernet protocol. You
have to negotiate a link to the PLC (and get a link ID back from the PLC)
before you can actually do anything.

> ControlNet includes this in their spec (chapter 4 page 154+), but
> unfortunately they carefully don't explain any of the older use. Plus this
> would only apply if your ControlLogix unit was running ControlNet over
> Ethernet. If you're running the native ControlLogix hardware they'd be using
> something other than CIP within the "framework" packet.
>

Hmmmm.... from what I was told (by an AB rep), the packets are basically
embedded CIP messages, complete with routing information. Who knows...


> I doubt AB will release it, as they "like" the idea of requiring RSLinx to
> hide the confusion of their protocols ;-)

And with AB so tightly in bed with Microsoft, it is highly unlikely they will
work on "other platforms" like Linux. Hense, my work and efforts on the
Ethernet driver.

>
> Do you actually have some COntrolLogix hardware to test?
>
I had access to one, but I am no longer emplyed there. Then again, as buggy as
the platform is, I don't exactly miss it. What bugs you might ask? DHRIO
module is easily locked up, especially if both channels in use, MSG done bit
comes on before message is sent, COP instruction can take more than 1 scan to
finish, ControlNET I/O with flex modules is highly unreliable, the programming
terminal suffers from memory leaks and random crashes, TOF instruction does not
perform as documented, Ethernet closes all connections (sockets) during
downloads, etc, etc, etc.

> Regards
> - Lynn
>

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

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

 

In a message dated 01/18/2000 03:44:42 PM Central Standard Time,
[email protected] writes:

<<
I had access to one, but I am no longer emplyed there. Then again, as buggy as the platform is, I don't exactly miss it. What bugs you might ask? DHRIO module is easily locked up, especially if both channels in use, MSG done bit
comes on before message is sent, COP instruction can take more than 1 scan to finish, ControlNET I/O with flex modules is highly unreliable, the programming terminal suffers from memory leaks and random crashes, TOF instruction does not
perform as documented, Ethernet closes all connections (sockets) during >>

IIRC, the message done bit on AB PLC5 ethernet ports also comes one before the msg actually completes. with DH it actually gets an ack back from the rcving station before the done bit comes on. but in the ethernet version, the done bit comes on when the message is successfully sent w/o regard to whether the recving station recvd it.


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