Modbus Slave | Connections

Once the I/O interface has been configured as desired, the user will have to connect points in the model to points in the driver by using the designated HYPERSIM sensors. The driver's connectable points depend on the number of analog and digital inputs and outputs that the slave has.

The connection points are classified in the following categories:

Coils

Connection point	Direction	Description
User-defined name	From driver to model	Data value

Discrete Inputs

Connection point	Direction	Description
User-defined name	From model to driver	Data value

Holding Registers

Connection point	Direction	Description
User-defined name	From driver to model	Data value

Input Registers

Connection point	Direction	Description
User-defined name	From model to driver	Data value

Under each category, the configured operations will show-up with the names that have been given by the user. Take note that if a slave output is configured to be controlled From Both, there will be two connection points instantiated. One will be From Master and the other one will be From Model . The data point From Master is always directly mapped to the real slave outputs (holding register or coil) and this output will be overwritten by the From Model data point at a time interval determined by the Cycle output rate (ms).

In TCP mode, an additional "Connected" connection point is available and can be used in the model to indicate if the Modbus slave is connected to a Modbus master or not. It represents the number of Modbus masters currently connected to the Modbus slave. This value will be the same for all slaves sharing an IP address and TCP port combination.

If Advanced fault injection options have been enabled in TCP mode, for each Modbus slave the user may also have access to the following connection points:

Feature	Connection point	Description
Enable slave failure	Slave failure	Enable or disable connections to the TCP Modbus slave during the simulation. It should be connected to an Output.
Enable slave delay	Slave delay enable	Enable or disable the response delay mechanics of the TCP Modbus slave during the simulation. It should be connected to an Output.
	Slave delay (ms)	Modify the response delay (in milliseconds) to apply during the simulation. The range of possible delays can go from 50ms to 30 000ms. It should be connected to an Output. NOTE: the delay values are rounded to the nearest power of 5 for values under 500ms and rounded to the nearest power of 10 for values beyond 500ms. This is because we can't guarantee better precision in those ranges.
	Number of delayed replies	(Optional) Set the amount of requests for which the response delay should apply. Setting this value to 0 will apply the delay perpetually. It should be connected to an Output. If the user wishes to restart the countdown of delayed replies, disabling and then re-enabling the slave delay with the Slave delay enable connection point will reset the counter. This counter can be seen using the Remaining delayed replies connection point.
	Remaining delayed replies	(Optional) Display the amount of delayed replies left before the delayed is stopped internally. It should be connected to an Input. NOTE: Any requests made after the last delayed request will have to wait for the last reply to be sent out. To contextualize; if the last delayed request was at T=1s with a delay of 4s, and then two other requests arrive at T=2s and T=3s, we will have the three replies sent out one after the other at T=5s.
	Slave delay active	(Optional) Display the internal state of the delay mechanics. This is mostly useful when using the Number of delayed replies feature, since it gives another visual indicator that the response delays have been disabled internally at the end of the countdown of delayed replies. It should be connected to an Input. To reactivate the delay mechanics internally; disable and then re-enable the slave delay using the Slave delay enable connection point.

NOTE: As the name suggests, these fault injection features add faults and may break the inner workings Modbus protocol. It is expected that these may break setups or cause odd behaviors.

In RTU mode, an additional "Bus Activity" connection point is available and can be used in the model to indicate if the Modbus slave is receiving requests from a Modbus master.