Modbus Add-On
Configuration Parameters
In addition to the GW4 configuration parameters the add-on has the following specific parameters:
Modbus Reading
| Description | Key | Type | Possible Values | Default |
|---|---|---|---|---|
| Modbus address for internal | modbusInternalAddress | Number | 0..255 | 250 |
| Number of readouts to be uploaded together (saves energy) | modbusAccumulate | Number | 1-10 | 1 |
| Modbus configuration and list of commands | modbusCmdConf | String | R,9600,8N1:010300020002,010300060002,FA0400050001 | |
| LoRaWAN Payload Format Modbus | loraFormat | Number | '1', '4', '5' | 5 |
| Time to wait (in ms) before executing the commands | PowerOnDelay | Number | 0-60000 | 1000 |
Detailed Description
LoRaWAN Communication
Modbus Uplink Payload Formats
Depending on the parameter loraFormat the collected Modbus Data is transmitted in different formats:
1= Verbose format4= Compact format with timestamp5= Compact format without timestamp
Data Packet Verbose (loraFormat 1)
When loraFormat is set to 1, the Gateway will send Modbus uplinks in the verbose format on port 3. The format contains the complete response to each command. It has all additional information to know what command was sent, even if it runs into an error. The format adapts to changing Spreading Factors and tries to use the available payload capacity.
If a response is too long for the payload capacity, messages are split into parts. For split uplinks, the first one will also be sent on port 3, following parts (that need to be re-attached) will be sent on port 5. It is possible to write configurations that will never need to split a message. Just make sure that no response will be longer than the minimal available uplink size (respecting the additinal bytes of this format). The device will try to fit as many responses as possible into a single uplink, without changing the order in which they are sent. If the next response will not fit, a new uplink will be started for it. Only responses that do not fit in a single uplink will ever be split.
Structure of a message
Byte | 0 . 1 . 2 . 3 . 4 | 5 ... | ... | ... | ... |
+-------------------+------------+------------+-----+------------+
Data | timestamp | response 1 | response 2 | ... | response n |
Structure of a response part in a message
Byte | 0 | 1 .. len-3 | len-2 . len-1 | len |
+--------+-----------------+----------------+-------+
Data | length | Modbus response | start register | count |
Data Packet Compact (loraFormat 4,5)
When loraFormat is set to 4 or 5, the Gateway will send Modbus uplinks in compact format. All Modbus commands in all entries in modbusCmdConf will be processed in the order they appear. The Gateway will create an uplink format that holds all data that is read from any Modbus slaves. It will be a fixed format, where every byte from every register or coil will have its fixed position.
If a response is too long for the payload capacity, messages are split into parts. For split uplinks, the first one will also be sent on port 20, following parts (that need to be re-attached) will be sent starting on port 200 up to port 223. No message will be longer then the number of bytes set in loraPL. The bytes of the responses will simply be attached in the order they appear in the command definition. Whenever a response wont fit in the message, a new uplink definition on a new port will be startet. If a response is too long for the payload size set in loraPL then the configuration is invalid. Longer commands must be split into multiple shorter commands, so that the responses will fit. The order of responses will never be changed, even if a different order would fit into less different uplink formats. It is up to the person configuring the Industrial Gateway to find a configuration that uses this format efficiently.
It is possible to build very efficient formats with this feature. You can group data points together that you need in a single uplink. If you need help with configuring the Gateway for your installation, please contact sales@lobaro.de for an offer.
Each uplink format will have a single header byte that holds an error flag. loraFormat = 4 will include a 5 byte timestamp in each uplink. loraFormat = 5 will not. Appart from that, the formats work identically.
The payload in the compact format is influenced by the config parameters modbusCmdConf, loraFormat and loraPL.
Structure of an uplink using loraFormat = 4
Byte | 0 | 1 . 2 . 3 . 4 . 5 | 6 ... | ... | ... | ... |
+--------+-------------------+------------+------------+------------------+
Data | header | timestamp | response 1 | response 2 | ... | response n |
Structure of an uplink using loraFormat = 5
Byte | 0 | 1 ... | ... | ... | ... |
+--------+------------+------------+-----+------------+
Data | header | response 1 | response 2 | ... | response n |