Support for programming DigiOne IAP with SCL 5/05

I have somethings questions.

How programming the MSG block in PLC SLC 5/05 for communicate with DigiOne IAP, is similar like with Control Logix??

The MSG Block always say me the same mistakes, TimeOut or Connection was broken, Somebody Know why??

Y hope that you can help me.

You cant try whit other Digione SP I/A this is a sucessfull converter and you dont need alot programing.


If you use the MSG block in multihop=NO, then the request goes out as older AB/Ethernet (or CSPv4) which only other PLC5E or SLC5 understand. ControlLogix will never understand.

In the DOIAP you’ll need to have “AB/Ethernet” enabled. If you leave the MSG block in LOCAL mode, then the DOIAP will see the request as aimed at slave #0 because both of the SRC and DST bytes in the AB/Ethernet header are zero. If you change the MSG block to be REMOTE, then you can enter the “Remote Station Address” which is used by the DOIAP to select which slave to forward the request to and also will be used as the DF1 DST byte (or slave address if a Modbus slave).

So you need to set up the “message route table” within the DOIAP correctly.

If you enable the multihop=YES, then the SLC5/05 uses Ethernet/IP. You force in a slave address by adding a ControlLogix-style slot entry to the multi-hop table. So to access slave #3 via the DOIAP you tell the MSG block to target the processor in slot #3.

If you give me more details about the slave on the DOIAP, I can explain more fully how the “message route table” is to be created.

Thank You lynnl for your answer!!!

The info about my slave is:

Marking System Technifor, Controller UC 112
Protocol of Communication: ASCII
19200 Kbps
8 bits
1 Stop
Software Flow Control

I did configure the DOIAP with Allen Bradley Ethernet, and MSG Block with local, Multihop=NO but I can´t communicate with the DigiOne because in the Setup Screen of MSG Block appears the message “Reply not received before user-specified timeout”

I hope you can help me

Than you

I know this thread is almost 5 years old…but I’m having the same issue. I can’t make this work no matter how many combinations of IAP config, PLC MSG instructions I’ve tried.

The Modbus RTU slave, address 1, is set at 57600, 8, Even, 1, xon/xof. From what I understand, the cable shipped with the IAP is a null modem?

The SLC is a 5/05.


XON/XOff can never be used with Modbus/RTU, which is a binary protocol.

Plus the Allen-Bradley PLC tend to have fairly aggressive surge protection, which means at 57K you probably have a high bit-error rate due to too much capacitence.

Drop the baud rate back down to 19200, and turn off the XOn/XOff (so no flow control) and you should be good to go.

The slave is a gas detection unit, and I have no access to it’s port parameters, unfortunately…so I’m stuck with those settings.

Since posting this morning, I have a successfully operating MSG. I did a 500cpu read, remote, using “1” as the remote station address, no multi-hop. The network side of the IAP is set to AB Ethernet, the serial side to modbus RTU slave. When disconnecting the serial cable, the MSG errors out, when reconnected…EN/DN cycles, no problem.

So, I think I’m reading the slaves data table, but I can only read 40001 to 40255…nothing higher. According to an algorithm I found in this technote:, if I want to read 42000 or 42001, the equivalent N address would be N29:99, N30:0, respectively. When I enter those addresses, or for that matter, any addresses other than those in the N10:0-255 range, the MSG errors. When I change back to N10:x, it starts working again.

Thoughts? (And thanks!)

EDIT: I’m using software flow control, not xon/xof as I incorrectly stated.

3/8/2011 Update: I cannot read higher than N30:2 (42002) no matter what I do, whether using Ethernet IP or A-B Ethernet. Any help is appreciated.

It’s now working…turned off the flow control on the serial port. It’s set to software on the slave, so…?

Have you tried setting the DOIAP to use serial Modbus/ASCII?

That is the only version of Modbus compatible with software flow control.

For example, polling register 4x00020 under Modbus/RTU encodes as 0x01 03 00 13 00 01 (plus CRC) yet the software-flow control-enabled receiver will see the 0x13 and stop sending any responses.


hey “if it ain’t broke - don’t fix!”. It works. I suspect that product started as Modbus/ASCII only, so inherited the software-flow control. Then when they added Modbus/RTU they failed to properly document - or that setting doesn’t even do anything anymore.

Generally software-flow control is only needed on things like printers where 5000 to 10000 bytes move in one direction. With a half-duplex protocol like Modbus, the 256-byte or less message rarely has any need to ‘pause’ mid-stream for buffering purposes. hardware (RTS/CTS) flow-control maybe, but not software.

They definitely did NOT properly document their settings…and then told me it was XON/XOFF…adding more confusion. I’m glad it’s working, and thanks for your help!