I/O Scanning |
This TLM is primarily intended for controlling ethernet based I/O. As an I/O driver, it assumes the normal burdens of a SoftPLC I/O driver pertaining to the management of operating modes and states, described below.
Operating Modes and States | ||
The SoftPLC runtime engine is always in one of the following states, called Operating Modes.
| Mode | Description |
|---|---|
| Program or Remote Program | Logic is not being solved and the outputs are in an idle state. Normally idle state means "turned off or zeroed", but with this driver, each output is independently configurable to be other than off or zero in its idle state. For example, a valve can be configured to be at 50% open in its idle state. If you take no special steps, the idle state of an output is zero or off. |
| Run or Remote Run | Logic is being solved and the outputs are active and under the control of the logic program. They are not idle. The logic program makes its decisions based on the current state of each input, all of which are actively scanned. |
| Test or Remote Test | Logic is being solved but the outputs are idle. The logic program makes its decisions based on the current state of each input, all of which are actively scanned. |
| Faulted | Logic is not being solved and the outputs are idle. This mode is entered automatically if you have an error in your program or in one of your driver configurations. |
Each configured Modbus IP slave is always in one of the following states. Each slave's state is independent of the state of any other slave, so not all slaves are always in the same state.
| State of Slave | Description |
|---|---|
| Present and Responding | The TLM has a good connection to the slave and knows that it is responding within a timeout limit to its requests. A subset of this state is the situation where the slave responds with an exception to a request. |
| Not Present or Not Responding | The TLM is not able to get any response to its requests from this slave. This is the case when the cable is disconnected, the slave is not powered up, or the slave has failed. |
The two states shown are tracked by the TLM for each slave. The Present and Responding state is used for all 4 Operating Modes. As long as an I/O module is responding, the TLM can tell it what to do and thereby honor its obligations with respect to Operating Modes. The slaves have no actual knowledge of the SoftPLC Operating Modes per se. An output module is told to go "idle" merely by sending the corresponding process data to the module. The module does not know the data is "idle" data, only the TLM does.
Driver State Transitions | ||
The SoftPLC runtime engine notifies all TLMs of the need to change from one Operating Mode to another. A TLM that is acting as an I/O driver must honor the behavior outlined in the Operating Modes table above. To accomplish this, there are significant responsibilities that must be met at the edge of these mode transitions.
Additionally most Modbus IP I/O modules these days are intelligent and can be software configured to operate with alternative behaviors. The soft configuration normally takes place by sending regular Modbus requests, but with special memory addresses used in the requests that are reserved for configuration.
This soft configuration may be required when entering Run mode, or it may be required just after an I/O module is replaced, possibly due to an I/O module failure. The I/O module replacement might take place while the SoftPLC runtime engine is in Run mode the entire time. The I/O driver must therefore detect that the I/O module is newly present, and send the configuration commands on the edge of this transition from not present to present.
| Object | Transition | Description |
|---|---|---|
| Runtime Engine | From Run Mode to Program, Faulted, or Test | The TLM issues the output requests to the output modules with the idle data on a one shot basis. |
| Runtime Engine | From Test, Program, or Faulted to Run Mode | The TLM issues the configuration requests to all modules on a one shot basis. |
| Any Slave | From Not Present to Present | The TLM issues the configuration requests to this module on a one shot basis. |
Scan Synchronization | ||
The TLM has its own thread (scanner thread) with its own scanning operation. This scanner thread is separate from the main control program thread (main thread) which is part of the SoftPLC runtime engine. The scanner thread runs in parallel with the main thread. Naturally the two threads can have different work loads and will rarely complete their respective scan cycles in the same amount of time. The following rules are put into effect:
- If the scanner thread completes a given scan cycle before the main thread, then the scanner thread waits for the main thread to complete before starting its cycle again. (No cpu time is wasted during the wait.)
- If the main thread completes before the scanner thread, it does not wait for the scanner thread, and the two threads both run as fast as they can, with the main thread running at a faster cycle rate.
In other words, the scanner thread is not allowed to wastefully use CPU cycles obtaining fresh I/O status only to have it not used. On the other hand, if this Modbus master scanner thread is running slower than the main thread, then only the I/O on the ethernet is updated slower. Any other I/O drivers (TLMs) and the main thread are not slowed down due to a slow ethernet module.
Network Concerns | ||
The modbus scanner thread issues many of the requests all at once and then services the responses as they come back asynchronously. This gives the best modbus I/O scan times because all the slaves are handling their respective requests in parallel. However, it can lead to choppy network traffic with higher instantaneous bursts of traffic at the start of each I/O scan. For this reason and for reasons of reliability and overall consistency of performance, it is recommended, but not mandatory, that a dedicated ethernet be used for the I/O modules and this master, particularly if you have more than a handful of slave nodes.