I am having trouble connecting to a SLC 5/03 when using the AB Ethernet SLC device in ignition. I am using an ethernet to serial terminal server to communicate to the SLC’s serial DF1 port. I have no troubles communicating to the SLC via RSLinx but when I try to use ignition, it’s a no go.
Any words of wisdom?..
Your ethernet to serial terminal server does not do protocol conversion and your PLC is probably configured for DF1, which is not supported by the OPC-UA driver.
I am doing protocol conversion with a Digi IAP. I am converting AB Ethernet (Port 2222) to Serial DF1. Works fine using FactoryTalk View SE and RSLogix500 coming in via ethernet.
OK, you didn’t mention the protocol converter so I was assuming you were using a generic Ethernet to serial terminal server with a virtual com port.
Have you tried configuring the IAP for Ethernet/IP (port 44818), this is what the 1761-NET-ENI uses and is probably better supported than AB Ethernet (port 2222, CSP) protocol.
I would need to know what port the Ignition AB driver is looking to connect to. I’m not at the office today but i believe i tried 44818 as well. Does the connection path need to be configured? I also thought about using the UDP/TCP driver and configuring my servers incoming port to TCP and doing the protocol conversion from there.
The TCP/UDP driver apparently doesn’t work like I thought it would. I was able to connect and received a Message “Good Data” but that’s as far as I got. Not sure how to add tags to this driver…
Still not sure about the Connection Path and AB Port numbers ignition is directing to.
The TCP/UDP driver is probably not what you’re looking for. It’s for connecting to relatively simple devices like barcode scanners that have a simple delimited-style message that gets sent back after connecting.
With that being said, I’m back to using the AB SLC driver. Any clarification on the connection path I should use? I’m communicating to a SLC503’s Serial Port via a Digi IAP that is doing the protocol conversion from Ethernet to Serial. I’ve used this setup with other HMI systems and didn’t have any trouble.
This is no help but I am trying exactly the same thing with a Moxa EIP 3270. RSLinx will see the CPU using the Ethernet driver but not Ethernet/IP. I was hoping this device would replace the 1761-NET-ENI. Hopefully your solution if you find one will help me this end.
There has been a lot of chatter about connecting to processors through an Ethernet to serial conversion unit. So, I thought I would provide some information on the topic.
The OPC-UA SLC driver supports multiple protocols and the protocol is determined in the following way:
If the connection path is blank (empty), it will first try CSP protocol on port 2222. If an error is received it will then try EIP protocol on port 44818 (this is the protocol used for the NET-ENI interface). The driver will keep trying each protocol until a successful connection is made.
If the connection path is used, the driver will use only EIP protocol on port 44818 and is intended for connection through a DHRIO module residing in a ControlLogix gateway.
Serial DF1 protocol is not supported, so a straight Ethernet to serial converter will not work with the OPC-UA SLC driver. The device must support Serial DF1 protocol for the serial connection to the processor and either CSP or EIP on the OPC-UA side. Although, CSP is typically only used for a processor directly connected through Ethernet.
We have customers that are using Moxa and it works fine to communicate to both the SLC and MicroLogix processors. I am finding out the model number of the Moxa unit and will post in this forum.
Usually, it is a matter of configuring the unit for the correct protocols, station numbers, etc.
I heard back from a customer that is using the Moxa with our OPC-UA SLC and MicroLogix drivers. He is using the Moxa 3270 which is a Ethernet/IP to DF1 gateway.
Another update: the issue preventing connection through a Moxa EIP 3x70 protocol converter has been resolved. This affects the SLC and MicroLogix drivers in OPC-UA.
The next beta or release will contain the fix.
Thank you,
Tom