Converter Modbus - Documentation how the protocol works

Hello, I would like to know if there is any documentation to explain how to read TYPE(Coil,DISCRETE_INPUT, HOLDING_REGISTERINPUT_REGISTER) and Converter(Coil, TWO_BYTE_SIGNED_INTEGER,FOUR_BYTE_FLOAT_SWAPPED,FOUR_BYTE_SIGNED_INTEGER_SWAPPED,FOUR_BYTE_SIGNED_INTEGER) from slave id and offset?

For our web application we are trying to have these values without the user having to input all the parameters, we would like the user to just enter the list of offset´s and slave id´s so we could read the devices and and then convert automatically.

How the convertion works for MODBUS ?How to identify the correct convertion ?
we would like the user to just enter the list of offset´s and slave id´s so we could read the devices and and then convert automatically.

Good News! You're in good company. You and everyone else in the world would love to simplify data communications to that exent.

Bad News! No way to do it.

There is a recent thread started by Peter Humaj regarding a couple non-standard Modbus behaviors that warrants mention in this regard.

The very first link goes to the documentation for his company's Modbus client product.

Check out the link for the number of options that client/master needs to deal with the variety of Modbus implementations that he's run across.

You're asking how to simplify all the tasks that a robust Modbus client accomplishes into a list of offsets and a slave ID. It'd be nice, but it's not reality. This is the age of diversity. Celebrate the diversity of Modbus because it certainly exemplifies diversity in its implementation.

The Modbus spec defines things like slave ID node number, function codes (what you call TYPES and standardized function needed to access those registers) and the range of the register addressing in the memory areas associated with the function codes, but the Modbus spec does not define any of the data formats (what you call Converter TWO_BYTE_SIGNED_INTEGER, etc). Common useage amongst the participants in communications protocols tends to use terms like UINT for a (16 bit) unsigned integer or INT for a signed integer. But there are four IEEE754 floating point (real) formats, two of which are commonly used for Modbus, but it is rare for actual floating point format to be documented. It is frequently trial and error during implementation to determine which of the two commonly used FP formats is in use.

Another stumbling block is whether the offset value starts from zero or from one. It makes a difference! Register addressing in hexadecimal tends to be zero-based offsets. Register addressing using the leading memory area numeral (like 3 for Input registers, 3xxxx, or 4 for holding registers, 4xxxx) tend to be one-based, but no guarantees.

Scaling factors for integer units are common, but are not part of the Modbus message. Scaling factors are (hopefully) described in the documentation and the implementation requires the data to be correctly interpreted at whichever end receives the data, understanding that there is a scaling factor that needs to be applied.

Same with engineering units. The engineering units are generally documented and then interpreted by at the application level after-the-fact, the engineering units are not part of the Modbus messaging.

The implementation of Modbus comm requires determining where the data resides (exact offset), how the data is formatted, what the data represents (scaling and eng units) and then interpreting the data appropriately. It's just the way it is.

The Modbus specs are publicly posted at