Allen Bradely SLC 5/03 and 1761-NET-ENI module

Hi All,
One of our customer has a SLC 5/03 PLC and they bought a 1761-NET-ENI module now so the SCADA software can communicate using the ethernet to 1761-NET-ENI module. The communication from 1761-NET-ENI to SLC 5/03 will be using a RS232 cable. We have a SCADA system in QNX operating system and we do have a driver for ethernet communication using the "df1 commands embedded in the CIP". This driver worked fine for Control Logix series PLCs, PLC 5E series and Compact Logix series. Now I am trying to use the same driver for the 1761-NET-ENI module and I am getting an error code meaning "Service not supported".

So I called the Allen Bradely tech support and they told me that 1761-NET-ENI only supports the CIP not the PCCC commands. They also told me that PLC5E and SLC 5/05 series only supports the PCCC commands. But our exeprience shows that Control Logix, Compact Logix and PLC5E supports the df1 embedded in CIP.

So any ideas whether the 1761-NET-ENI supporting the PCCC commands? If so could you please send me any info/samples?

Thanks in advance.

Regards,
Raj

I think you may be out of luck

KB article which shows compatibility for series A ENI is here

KB article which shows compatibility for series B ENI is here

The NET ENI is a strange device. I have used a 1/2 dozen on them and have had no luck interfacing non AB software. I just finished setting up RS Historian on 2 slc 5/04 with NET ENIs it worked great. But if I tried other NON AB software it would not "see" the plc. Case in point I can use TELUS (Hakko Electronics) on any of my slc 5/05s or on control logix with no problem but not with the eni. BTW RSView works fine with them.

I have used NET-ENIs with non-AB software to communicate with Micrologix 1500 and SCL 5/04. The software was Automated Solutions ASABTCP active x control. The NET ENI communicates with the PLC using DF1 but I believe that it only communicates on ethernet using ABTCP. I think that you need third party software that will support ABTCP. You might try an OPC server such as Topserver from software toolbox.

I don't think that the NET-ENI supports DF1 over ethernet.

You seem to be a bit confused on the issue of CIP and PCCC.
First of all PCCC is an application layer of DF1 protocol.
DF1 has only two layers, data link and application.
Strip out all the responses (NAKs ACKs ENqs) and you are left with the PCCC. There is no such thing as DF1 embedded in CIP. CIP
protocol uses explicit or implicit messaging to communicate to
ControlLogix. It does not have anything to do with DF1.
NET-ENI supports PCCC encapsulation, it only supports CIP to send
MSGs to ControlLogix processors.
The driver that was used with NET-ENI will not work on ControlLogix.

I meant to say the driver that worked OK for ControlLogix will not work on NET-ENI .

JohnW said:

I have used NET-ENIs with non-AB software to communicate with Micrologix 1500 and SCL 5/04. The software was Automated Solutions ASABTCP active x control.

Click to expand...

I see that "Cimquest Ingear" activeX control has provisions for ethernet comms for a NET-ENI also.

Thanks your reply.

Hi Jiri Toman,
In my post I mentioned "df1 embedded in CIP" what I meant was support of Ethernet IP with embedded PCCC commands instead of EIP explicit messaging. We used this embedded PCCC commands in the Ethernet IP message for the Control Logix and Compact Logix. Do you know whether 1761-NET-ENI module supports embedded PCCC commands in the ethernet IP message? I understand the Allen Bradely added this support for the backward compatablity between different families of their processors. I am using the Allen Bradely document "Communicating with RA Products using EtherNet/IP Explicit Messaging (Rev 1.1)".

Thanks in advance.

I have 1761-NET-ENI ser A FRN 1.02. It's few years old. I sniffed it out while it was talking to 5/03 and ML 1000. It's using PCCC
encapsulation as documented in EtherNet/IP spec by ODVA.
I think that PCCC section is in chapter 2. Subsequently I wrote
a driver that communicated to 1761-NET-ENI and SLC5/03.
I don't know what AB did to this module since. Maybe they added
more capabilities.
PCCC encapsulation requires quite complex header, it's not just a matter of taking the application layer of DF1 and putting it on TCP/IP.
CSP / EIP are AB's acronyms for older AB Ethernet spec.
Lot of it is proprietary. Some of the device codes used in the PCCC encapsulation are documented in ODVA manual some you have to snif out.

Allen Bradley also has a tendency to use undocumented features
and change the spec as they seem necessary.
For example within the DF1 protocol, Embedded Responses are not defined in the DF1 manual, in fact the manual will say that you cannot send responses within the message packet but yet when SLC 5/03 came out it was (still is) defaulted to Embedded responses out of the box!
Recently ML1500 is using a two address field protected typed logical write / read while DF1 manual does not even document it.
I wrote a driver for DF1 (available for free on my web site)
which does not work with ML 1500 because I thought that
ML 1500 uses the three address fields just like ML 1000 and SLC 500.
Funny thing is that you can use three address fields to write to it but it will only read with two address fields.

Since your SCADA uses QNX operating system you are going to have a hard time trying to get a right driver off the shelf.

You may want to hook up a sniffer to see what's going on.
This will not be an easy job. You should write a short program
that would be using your existing driver. Such program should keep sending one value (integer) to the PLC. You should sniff it out and then compare it to a sniffed out data produced by RSLinx.
You will need to use the ODVA document to decypher the header.

Since you did not write the driver yourself it will be unlikely
that you could change it in a reasonable amount of time. You will need to contact the person who wrote it and give him the data.

Other than that you may need to hire someone to write a new driver.

Thanks for your help.

I got some help from Allen Bradely tech support. Now the driver is working. The trick there is no path information needed in the embedded CIP packet. For the control logix path is needed but for the SLC, PLC 5E the path info is not needed.

Agian thanks for your help.