Hi,

where I can find sources about Modbus Role Auto?, recently I finded this role (Auto, Master, Slave) on Micro800 PLC by Rockwell.

What brands has this modbus role?

 

> role (Auto, Master, Slave)

Without a specific context (where the statement comes from and how it used in the document) it's impossible to say what auto is, and even then, it probably would not be clear.

It sounds to me like a cut and paste error in a marketing document. The statement was probably supposed to be Master, Slave and the word 'auto' was not removed because proof reading is a lost art.

I am unaware of anything that is automatic about Modbus, other than its execution once coded and run. Configuration, programming, mapping are all manual tasks.

A summary overview of Modbus RTU for the 830/850 is on page 67 (pdf) (53 paper) in the document here:
http://literature.rockwellautomation.com/idc/groups/literature/documents/um/2080-um002_-en-e.pdf

But maybe there's some magic in the 800's. Anyone else?

 

Having worked with Modbus/RTU for 25 years - including a lot of remote cellular access, I'll speculate that Auto means the serial port normally waits in 'slave mode', but that the PLC can still on occasion act as master and send requests. This is not standard (per modbus.org), but has become common in small remote RTU as well as cellular devices. Given the AB micro line was designed to compete with small RTU products, AB likely added this mode to be competitive.

This works fine if the serial link is 'full-duplex'. For example, the Digi Connect WAN products have an 'rbx' mode (aka: report-by-exception), which allows you to create a Modbus bridge in the WAN gateway, which understands that the attached serial device is a 'slave' with address #1. So if the WAN receives a Modbus/RTU message starting with 0x01, then it 'routes' this internally to a thread acting as remote Master to the device, but if the Modbus starts with anything else, then it is passed to a thread treating the link as a serial Master. This design was actually based on how an AB/FD1 'mux/demux' works in software.

Note the KEY detail here - you require a peer device which agrees to also act 'auto' in a single point-to-point link ... and I'll repeat, this is NOT part of the Modbus standard. Merely an ad-hoc thing which many vendors of small remote devices (like waste-water controllers) started adding as it was very useful. It allows the SCADA to poll normally, maybe once an hour, but also allows the local device to push 'report-by-exception' as a short-term Modbus master doing a Modbus write to (for example) a remote 'Modbus/RTU OPC server'.