How drivers work
A driver is the part of YTCC that talks to field devices in one protocol, for example Modbus TCP or IEC 60870-5-104. This page explains what all drivers have in common. Each protocol has its own reference page with its parameters.
Drivers, devices and address bindings
You set up communication in three layers, all in Drivers → devices of the configuration editor (see Add drivers and devices):
| Layer | What it is | Example |
|---|---|---|
| Driver | One protocol connection set, with a Driver key and a Driver type. | plc1, Modbus TCP |
| Device | One field device that the driver talks to, with a Device key, a Name and the connection settings of the protocol. | plc1_main, Main PLC, host and port |
| Address binding | The protocol address of one signal on one device. You set it on the Value source tab of the signal. | Holding register 1 |
A driver can serve several devices. SNMP, the MQTT client and IEC 61850 allow only one device per driver; the editor then says Single-device protocol — a second device cannot be added. Server-type drivers (OPC UA server, MQTT broker) have no devices: other systems connect to them.
A signal normally has one active source. To read the same signal from two devices, for example over redundant paths, tick multi-source on the Value source tab.
Each driver runs on its own
Each driver runs as a separate process under the YTCC process manager. If a driver stops, the others and the rest of YTCC keep running.
- Restart. If a driver process ends by itself, the process manager starts it again after 1 s, then 2 s, 5 s, 10 s and from then on every 30 s. A driver that has run for more than 60 s starts again at 1 s the next time.
- Heartbeat. A running driver reports that it is alive every 2 seconds. If no report comes for 6 seconds, all of its signals change to Bad · Not connected and keep their last value on screen. A high-priority alarm comes for the driver. If a driver never reports in the first 30 seconds after the project starts, the same alarm comes.
- Processes. On the home page, the Processes tab lists the drivers of the running project and lets an administrator start, stop or restart one of them. See Manage the YTCC processes.
The driver alarm text is written in the project's Operator language, in English plc1 driver not running — heartbeat lost or … no heartbeat received.
Connection to the devices
A driver connects to each of its devices on its own. A device that does not answer does not stop the other devices of the same driver.
- Reconnecting. When the connection to a device is lost, the driver tries again with a wait that doubles after each failed attempt, without a limit on the number of attempts. Most drivers start at 100 ms and wait at most 20 seconds (0.1, 0.2, 0.4 … 12.8, 20, 20 … seconds), and one attempt to open a connection waits at most 1 second. Some drivers use their own timing: S7 50 ms to 5 s, IEC 60870-5-104 1 s to 30 s, and IEC 60870-5-101 an upper limit per device.
- Signals of a lost device. Most protocols have a device setting that marks all signals of the device as Bad · Not connected when the connection is lost (for Modbus TCP: Set invalid on disconnect, on by default).
- Communication alarm. When a device has been unreachable for 5 seconds, one high-priority alarm comes for the device, not one per signal. Shorter interruptions give no alarm. After the project starts, a device that has never been connected gets 30 seconds before the first alarm. The alarm cannot be shelved. See Read the alarm list and the alarm bar.
- On screen. Colors that depend on the device turn pink, and a dot on the handle of the control rail marks the lost communication. See Read values and states.
Changes that load while the driver runs
When you click Apply in the configuration editor, the Affected drivers part of the window says for each driver whether it will hot-reload or requires a restart.
- Almost all drivers hot-reload: they take the new configuration while they run, device by device.
- A changed or new signal address is taken over without dropping the connection.
- A changed connection setting of a device, such as its host or port, reconnects only that device.
- A new device starts on its own; a removed or inactive device stops on its own.
- If the new configuration of a device cannot be loaded, the devices that are running are not touched.
- The OPC UA server and the MQTT broker require a restart. After Apply, a strip lists the drivers that must restart, each with a Restart button. Restarting interrupts communication for a few seconds, and no commands are sent during that time.
How often values are read
For protocols that ask the device for its values (polling), the scan class sets how often a signal is read. Four scan classes come with every project and cannot be deleted:
| Scan class | Period | Typical use |
|---|---|---|
| Fast | 100 ms | Values that change quickly |
| Normal | 1 s | General use |
| Slow | 10 s | Values that change slowly |
| Background | 60 s | Counters and parameters |
You can add your own scan classes, with a period of at least 20 ms. A signal takes its scan class from the first place where one is set: the signal itself, then its signal type, then its device, then the project default. On the Value source tab, Scan class shows (type / device default) when the signal has none of its own.
For OPC UA the scan class is the sampling interval. Event-driven protocols, such as IEC 60870-5-104 and DNP3, send changes by themselves; for them the scan class is not a reading period.
Quality, time and commands
All drivers report values with the same quality codes and the same two time stamps, and all commands follow the same rules:
- Quality: what Good, Uncertain, Bad and Bad · Not connected mean.
- Time stamps and time zones: the device time and the time the value arrived in YTCC. IEC 60870-5-101, IEC 60870-5-104, DNP3 and OPC UA send the time of the value; Modbus, S7, SNMP and EtherNet/IP do not, so only the arrival time is known.
- Commands and confirmation: a command goes at once or is rejected. It is never queued and never sent later when the device comes back. A command older than 2 seconds is not carried out, and a second command to the same signal is rejected while the first one runs. YTCC waits 10 seconds for the result of a command (25 seconds for select-before-operate); a signal can have its own result wait.
Drivers that other systems connect to
The OPC UA server and the MQTT broker accept connections from other systems. They listen on all network interfaces of the server: OPC UA on port 4840 and MQTT on port 1883 by default. Limit access with the firewall of the server, and see the page of each driver for its security settings.