AB7072 invalid output size (DeltaV EIOC)


I have 2 AB7072 communicators that I’m connecting to a DeltaV EIOC.

Configured input/output assembly instances as 100/150 and sizes aligning with the subnetwork monitor.

1st one (RS485) has 8 bytes input and 2 bytes output and works fine.

2nd one (RS232) has 23 bytes input and 0 bytes output and does not communicate with the EIOC.
Wireshark trace shows the error: Extended Status: Invalid O->T size (0x0127)

Any idea what the issue could be?


The issue could be that you are using 0 bytes output as a generic device. Is it possible to use the EDS file (Downloads and Documentation)?

It isn’t possible to use the EDS file with the EIOC, no.

What is the issue with using 0 bytes output?

I’m not completely sure this is the problem, but I’ve seen a similar issue when setting up generic IO devices with RSLogix. I think the controller expects there to be Output when it’s configured with the Output Assembly instance.

If you want to share your .cfg file for the Anybus and the packet captures I can look into it.

AB7072packetcapture.pcapng (1.3 KB) Anybus2_RS232_FE-011.cfg (16.0 KB)

cfg & subset of packet capture attached.

I have tried connecting without specifying the output assembly instance but that didn’t help.

Usually just adding a dummy trigger byte will take care of the problem. (see attached)

On an unrelated note, I noticed that you have a collision where multiple transactions are writing to register 0x16. Maybe that is by design?


Do you know if there is a way to set the connection to the generic IO device to “read only”? If there was, that would probably be the ideal solution.

Anybus2_RS232_FE-011-with-dummy-byte.cfg (16.0 KB)

Thanks Kyle.

I’ll try out the dummy trigger byte.

I didn’t do the original configuration, but the collision doesn’t seem to be important - that byte is for some kind of transaction data, not I/O data.

It would be ideal in this case to be able to use a read-only connection, but that’s not an option as far as I know.

There could be a good reason why they have multiple transactions writing to that same byte. I just wanted to make sure it wasn’t an oversight.

It’s not perfect, but that dummy byte should work. Let me know if you run into any issues or have any other questions.

Dummy byte has solved the problem.

Thanks again for your help.

OK great - thanks for the update!