Configuration Basics |
Modbus Fields | ||
Modbus commands were originally designed for a Modicon PLC. Therefore they assume 4 different types of memory regions. Words within these memory addresses are addressed using Reference Numbers, according to the following table. Basically, the first character of a reference number gives its region:
| Memory Region | Reference Number Format |
|---|---|
| Input Discrete (boolean inputs) | 1... e.g. 120438 |
| Input Registers (16 bit words) | 3... |
| Output Coils (boolean outputs) | 0... |
| Output Registers (16 bit words) | 4... |
Modbus TCP protocol includes the original slave id field which was part of the modbus on serial line protocol. In the case of communications on ethernet, either via TCP or UDP, this field is no longer used to qualify the actual network node that will respond to a request. The reason for this is because the IP Address in the ethernet frame serves this purpose. Therefore the "slave id" field becomes available for another use. This TLM can be configured to use a slave id field of your choosing for any request.
Configuration Fields | ||
This TLM is configured using a special configuration editor which is built into TOPDOC NexGen. The configuration file is organized hierarchically with the following building blocks (elements). Sub Elements are listed with one of the following characters trailing (suffix), indicating that zero or more elements must or may be present according to the following interpretation:
- ? Question Mark => Optional (zero or one)
- * Asterisk => Zero or more
- + Plus Sign => One or more
- None (no suffix) => exactly once
| Element Name | Description | Sub Element(s) |
|---|---|---|
| ModbusTLM | Top most element, holds all other elements | TealwareDrop* TCPServer* UDPServer* |
| TealwareDrop | A TCPServer that uses hardware configuration to generate Modbus requests. | Rack+ Slave+ |
| TCPServer | A network node that is a Modbus/TCP slave/server. | Slave+ |
| UDPServer | A network node that is a Modbus/UDP slave/server. | Slave+ |
| Rack | A Tealware Rack | module+ |
| module | A Tealware Module | address CDM? |
| address | Describes the memory areas that a module references. | |
| CDM | Configuration Data Memory | |
| Slave | Provides the slave ID within a Server. |
ReadInputDiscretes+ ReadInputRegisters+ ReadMultipleRegisters+ ReadCoils+ WriteSingleRegister+ WriteMultipleRegisters+ MaskWriteRegister+ ForceMultipleCoils+ WriteCoil+ ReadWriteRegisters+ |
| ReadInputDiscretes | A Modbus request of the same name | refNum toBlock |
| ReadInputRegisters | A Modbus request of the same name | refNum toBlock+ |
| ReadMultipleRegisters | A Modbus request of the same name | refNum toBlock+ |
| ReadCoils | A Modbus request of the same name | refNum toBlock |
| WriteSingleRegister | A Modbus request of the same name | refNum fromBlock |
| WriteMultipleRegisters | A Modbus request of the same name | refNum fromBlock+ |
| MaskWriteRegister | A Modbus request of the same name. The "or mask" comes from the value of the fromBlock | refNum andMask fromBlock |
| ForceMultipleCoils | A Modbus request of the same name | refNum fromBlock |
| WriteCoil | A Modbus request of the same name | refNum fromBlock |
| ReadWriteRegisters | A Modbus request of the same name | refNum toBlock+ refNum fromBlock+ |
| refNum | A modicon reference number | |
| toBlock | Where the response data is to be written into SoftPLC | |
| fromBlock | Where the request data is read from SoftPLC | (idle or const)? |
| andMask | An integer constant, see the Modbus specification for the MaskWriteRegister request. The orMask is given by the fromBlock for this request. | |
| idle | A list of integer constants. These data will be sent on a one-shot basis to the slave when the Operating Mode calls for outputs to be idle. Otherwise, when outputs are not idle, the live data specified in the fromBlock are used. | |
| const | A list of integer constants. These data will be sent as part of the enclosing request on a continuous basis, in lieu of reading live data from the SoftPLC. |
Note
When using NexGen to edit the configuration file, its application specific editor
takes care of enforcing the rules of the configuration file.
Note
Notice that a few of the word oriented requests can take multiple
fromBlocks and/or multiple toBlocks. In the
case of read word requests, the multiple toBlocks are used to split up the
response into several SoftPLC memory locations. So you can route your discrete
input data into the INPUT datatable section and your analog data into an INTEGER
datatable section, should they need to be in the same response. Each toBlock
"consumes" some of the response data consecutively, according to its count
field. So the sum of all the count fields should not exceed the allowed limit
for the request's response.
Likewise, for word write requests, multiple fromBlocks are supported. This allows you to assemble a request using data from multiple sources within SoftPLC. Your discrete output data can come from the OUTPUT datatable section and your analog data can come from an INTEGER datatable section, and be part of the same request. Again, the sum of the count fields for the fromBlocks cannot exceed the limit for the request.
Input data that you put into the INPUT datatable section with a toBlock will automatically feature the Input Forcing cabability within the SoftPLC runtime. Output data you get from the OUTPUT datatable section using a fromBlock will automatically feature the Output Forcing capability within the SoftPLC runtime. Only those two sections support forcing, a feature which is mostly helpful for discrete I/O, and not usually analog data.
Likewise, for word write requests, multiple fromBlocks are supported. This allows you to assemble a request using data from multiple sources within SoftPLC. Your discrete output data can come from the OUTPUT datatable section and your analog data can come from an INTEGER datatable section, and be part of the same request. Again, the sum of the count fields for the fromBlocks cannot exceed the limit for the request.
Input data that you put into the INPUT datatable section with a toBlock will automatically feature the Input Forcing cabability within the SoftPLC runtime. Output data you get from the OUTPUT datatable section using a fromBlock will automatically feature the Output Forcing capability within the SoftPLC runtime. Only those two sections support forcing, a feature which is mostly helpful for discrete I/O, and not usually analog data.
Here is a sample screen from the configuration editor showing a few of the elements from the above table. Notice how they are arranged hierarchically and that each element can "contain" other elements. The rules of containment are given in the table Elements and their Allowed Sub-Elements:
The element name is at the far left of each row. To the right of the element name is a list of attributes. The following table lists the allowed attributes for each element type:
| Element | Attribute | Value | Required |
|---|---|---|---|
| ModbusTLM | debug | 0, 1, or 2, meaning "enable none, some, or all debugging print statements" | no, defaults to 0 |
| digInStart | The start address for digital inputs in word form | no, defaults to I:0 | |
| regInStart | The file to be used for register inputs | no, defaults to N17 | |
| digOutStart | The start address for digital outputs in word form | no, defaults to O:0 | |
| regOutStart | The file to be used for register outputs | no, defaults to N7 | |
| TealwareDrop | ip | The ip address or machine name of the server/slave, e.g. "192.168.12.3" or "packer12" | yes |
| connectTimeout | Milliseconds to wait for a connection attempt to complete | yes | |
| requestTimeout | Milliseconds to wait for a response to a request, for any request contained by this element. | no, defaults to 30 | |
| TCPServer | ip | The ip address or machine name of the server/slave, e.g. "192.168.12.3" or "packer12" | yes |
| connectTimeout | Milliseconds to wait for a connection attempt to complete | yes | |
| requestTimeout | Default milliseconds to wait for a response to a request, for any request contained by this element. May be overridden by a specific request's requestTimeout. | no, defaults to 30 | |
| UDPServer | ip | The ip address or machine name of the server/slave, e.g. "192.168.12.3" or "packer12" | yes |
| requestTimeout | Default milliseconds to wait for a response to a request, for any request contained by this element. May be overridden by a specific request's requestTimeout. | no, defaults to 30 | |
| attempts | Count how many times to send the request before giving up waiting for a reply. | no, defaults to 3 | |
| Rack | num | This rack's number (from 1-4) | yes, automatically assigned |
| slots | The number of slots this rack has (4, 6, or 8) | yes | |
| module | slot | Which slot in the rack this module is located at | yes, automatically assigned |
| type | The name of this module | yes | |
| address | digIn | The digital input word address this module will reference | no, will be present if the module calls for it |
| regIn | The register input word offset this module will reference | no, will be present if the module calls for it | |
| digOut | The digital output word address this module will reference | no, will be present if the module calls for it | |
| regOut | The register output word offset this module will reference | no, will be present if the module calls for it | |
| CDM | const values for CDM | no, will be present if the module uses CDM | |
| Slave | id | "0" to "255", provides the slave ID within a Server. | yes |
| <any request> | when | "run" or "start": run => when in a run mode, start => one shotted when entering a run mode | no, defaults to "run" |
| requestTimeout | Milliseconds to wait for a response to a request | no, defaults to the setting within the Server | |
| refNum | |||
| toBlock | dest | a SoftPLC word or bit address, e.g. "I12:0". If the enclosing request reads registers (not coils or discretes), then a word address is required. If instead the enclosing request reads coils or discretes, then a bit address may be supplied but its bit component must be zero. | yes |
| count | the number of 16 bit words or the number of bits, depending on the enclosing request and the fmt attribute of this toBlock. | yes | |
| fmt | format of the response data, and determines the interpretation of the count attribute. "i2" or "bit": i2 => 16 bit (2 byte) signed integers, bit => bits | yes | |
| fromBlock | source | a SoftPLC word or bit address, e.g. "O12:0". If the enclosing request writes registers (not coils or discretes), then a word address is required. If instead the enclosing request writes coils or discretes, then a bit address may be supplied and its bit component may be non-zero. | yes |
| count | the number of 16 bit words or the number of bits, depending on the enclosing request and the fmt attribute of this toBlock. | yes | |
| fmt | format of the response data, and determines the interpretation of the count attribute. "i2" or "bit": i2 => 16 bit (2 byte) signed integers, bit => bits | yes | |
| andMask |
Note
In most cases where an "integer constant" is allowed, for example in the
andMask, idle, or const elements, you may enter that value in either hex or
decimal. Hex numbers start with a leading "0x". Example: "16" or "0x0010" would
be OK.