# Serial lines

> The serial line node of Modbus RTU, of the generic serial and TCP driver, of the SCPI driver and of the Omron driver: the physical tuple every device on the bus shares, its timing, its states, the unit scan, the devices filed under it, and what is locked while the line is enabled.

A **serial line** is one physical serial bus: a COM port with its baud rate and byte format, shared by every device wired to it. Lines exist under four drivers, Modbus RTU, Generic serial and TCP, SCPI instruments and Omron, between the driver and its devices, so the tree reads Modbus RTU > Line > Device > Tag. A line belongs to the driver it was created under, for good: devices of two different drivers never share a line, and one port belongs to one line whatever its driver. A Modbus RTU line also owns the transmission mode, the response timeout and the pacing every unit on it shares; on a line of the generic or of the SCPI driver each device says on its own panel how its messages end and how long it waits, and the line keeps only the port, the baud and the format (see [Generic serial and TCP](driver-generic-serial-tcp#serial-line) and [SCPI instruments](driver-scpi#serial-line)). On a line of the Omron driver each PLC answers to its own unit number and sets its own response timeout (see [Omron](driver-omron#host-link-on-a-serial-line)). The page is visible with View connector; every field and verb on it needs Configure connector.

## Creating a line {#creating-a-line}

Three gestures create one, under a driver already added: **Add line** on the Serial lines table of the driver's page, **New…** > `<Driver>` > **New serial line** in the column footer, and **Add line** on the driver's right-click menu. The new line is named "New line" (then "New line 2"), takes the first serial port Windows reports that no other line uses (or COM1, COM2 and so on when none is free), starts with 9600 baud and 8E1 (and, on a Modbus RTU line, a 1000 ms response timeout and a 0 ms transaction interval), and is created **disabled** so you can set the physical tuple before the port opens. The feed says so: "Added disabled line 'New line'. Configure its physical settings, then enable it." The line is not opened: it appears marked in the Serial lines table of the driver's page, where the screen goes from New… or the right-click, and **Open** on its row edits it. A line of the Omron driver starts on 7E2 instead, the factory setting of a Host Link port.

## The header {#the-header}

The name, the health dot, the state word and the physical tuple on one line ("COM3 · 9600 · 8E1 · 1000 ms", and "COM3 · 9600 · 7E1 · ASCII · 1000 ms" on an ASCII line; "COM3 · 9600 · 8E1" on a line of the generic or of the SCPI driver, which has no timeout) and, when the port failed, the diagnostic text in red under it. The state words are Off, Idle, Connecting…, Online and Port failure; what each means is on [Enabling and health](connector-health#serial-line-states). Under it, the devices on the line that have an error of their own are named ("1 device with an error: Meter"); while the port itself has failed, its devices point to the line and none of them is named.

## The command bar {#the-command-bar}

| Command | What it does | Greyed when (situation) | Not drawn when (role) |
| --- | --- | --- | --- |
| **Enable** | Lets the devices acquire the bus and locks the physical tuple. | The line is already enabled, its tuple is invalid, a scan is running, or the station refuses mutations. | Without Configure connector. |
| **Disable** | Closes the bus for every device on it without touching their own Enabled switches, and unlocks the tuple. | The line is off, a scan is running, or the station refuses mutations. | Without Configure connector. |
| **Delete line** (danger ink, on the right) | Asks first. An empty line: "Delete 'Line'? This line has no devices. This cannot be undone." A line with devices: "This also deletes its 3 devices and all of their tags." After the delete the line's driver is selected. | A scan is running, or the station refuses mutations. | Without Configure connector. |

Right-clicking the line adds **Add device** before the same Enable, Disable and Delete.

## The Physical line card {#the-physical-line-card}

"One physical serial bus: the port settings every unit addressed on this line shares." On a line of the generic or of the SCPI driver: "One physical serial bus: the port settings its instruments share, one request at a time." That line shows only the name, the port, the baud and the format; the rows marked Modbus RTU only below are not drawn on it. A line of the Omron driver reads "One physical serial bus: the port settings its PLCs share, each answering to its unit number, one request at a time." and shows the same.

| Field | What it is | Values / default | Effect |
| --- | --- | --- | --- |
| **Name** | The friendly name of the bus, shown in the tree and in every device's "Serial line" field. | Required; "New line" at creation. | Editable while the line is enabled. Blank is refused: "Line name is required." The name never enters an address: a Modbus RTU device is addressed `Connector.ModbusRtu.<Device>.<Tag>` with no line segment. |
| **Serial port** | The Windows COM port: physical, virtual or redirected. A text field with a picker of the ports Windows currently reports; choosing one fills the field. **Refresh** re-reads the operating system's list without replacing what you typed. With nothing detected the picker shows one disabled entry, "No ports detected", and the field says "No serial ports detected. Type one manually." | Required; the first free detected port at creation. | Locked while the line is enabled. One port belongs to one line, case-insensitively, even while both are disabled: a second line on the same port is refused when saved. |
| **Baud** | The bus speed. | Greater than zero; 9600. | Locked while enabled. With the format it fixes the automatic inter-frame silence. |
| **Transmission mode** | Modbus RTU only. How every unit on the bus frames its messages: RTU, binary frames with a CRC, or ASCII, text from a colon to a line break with an LRC. | RTU, ASCII; RTU. | Locked while enabled. On an ASCII line the **Serial format** also offers 7N2, 7E1, 7E2 and 7O1, and the **Automatic** silence reads 0 ms, because an ASCII frame ends at its line break; a note under the interval says so. An RTU line refuses the 7-bit formats: an ASCII line with a 7-bit format switched back to RTU shows its format empty, and the line is not saved until an 8-bit one is picked. |
| **Serial format** | Data bits, parity and stop bits. | 8N1, 8N2, 8E1, 8E2, 8O1, 8O2, and on an ASCII line or a line of the generic, of the SCPI or of the Omron driver 7N2, 7E1, 7E2, 7O1; 8E1. | Locked while enabled. |
| **Response timeout (ms)** | Modbus RTU only. How long one unit may take to answer before the request fails. | 100 to 60000; 1000. | Locked while enabled. Longer timeouts accommodate slow equipment but make missing units and discovery slower to identify, as the card says. |
| **Minimum transaction interval (ms)** | Modbus RTU only. A line-wide silence enforced from the end of one attempted transaction to the start of the next, for every unit, read and write, including timeouts and failures. | 0 to 1000; 0. | Editable while enabled; a change takes effect without cycling the port. Zero keeps the protocol minimum. Two readouts follow: **Automatic**, the Modbus RTU floor (3.5 characters at the configured baud and format up to 19200 baud, 1.75 ms above it) and **Effective**, the greater of the floor and your value, never their sum. The note says what it is for: higher values reduce throughput for every unit on the line, and it is a compatibility aid, not a repair for wiring, termination, grounding or noise. |

Three lines close the card: the line's health summary ("Online · 2/2 devices online", "Idle · no enabled devices", "Online · 1 online · 1 with issues"), which fields are editable right now ("Physical settings are editable while the line is disabled." or "Disable the line to change its physical settings. Name and transaction interval remain editable online."; on a line of the generic or of the SCPI driver, which has no interval, "Disable the line to change its physical settings. Its name remains editable online."), and, on a Modbus RTU line, the timeout advice.

An out-of-range value is not saved and the reason lands in the feed: "Serial port is required.", "Baud rate must be greater than zero.", "Response timeout must be between 100 and 60000 ms.", "Minimum transaction interval must be between 0 and 1000 ms." The box keeps what was typed; the tuple in the header, the driver's **Physical tuple** column and each unit's **Serial line · fixed** keep showing the line as it is stored, which is the line the bus runs with. A line whose tuple is invalid cannot be enabled. A save the station refuses rolls the card back to the stored values.

## The Discover units card {#the-discover-units-card}

Drawn only for Configure connector, and only on a Modbus RTU line: "Sequential read-only probe on this configured physical line." **Unit ID start** and **Unit ID end** (1 to 247, ascending; 1 to 32 by default) bound a probe of every unit in the range over this line's saved tuple; **Discover** starts it and turns into **Cancel**. The line under the fields estimates the worst case ("32 probes · up to ~32.1 s, including 4.011 ms silence before each probe.") or names what is wrong with the range ("The unit-id range must be ascending."). A line that is enabled with at least one enabled device is in use, and the card says so: "This line is in use. Disable it before discovery; Ganter Lab will not interrupt or re-enable the bus automatically." A pending edit on the card is saved before the scan opens the port. The results grid, **Discovered units** (Unit ID, Device, Result, Add device or Open), and the scan itself are on [Discovery](connector-discovery#modbus-rtu).

## The Devices card {#the-devices-card}

"Unit IDs must be unique on this line. Physical settings are inherited and cannot be changed here." **Add device** creates a device on this line under the first free unit id from 1 to 247 marked in this table and scrolled into view ("Added device 'New device' on 'Line 1'."); it is refused with "Line 'X' already contains every valid Unit ID." when none is free, and greyed during a scan. The table lists **Device**, **Unit ID**, **Tags**, **Health** and the actions Open, Enable, Disable and Delete (the last three for Configure connector, all greyed during a scan). The device's own page shows the line and its tuple as read-only text; see [Devices](connector-devices#the-connection-card). A device with an error of its own carries the tree's red marker after its name.

On a line of the generic or of the SCPI driver the card reads "Every device on this line shares its port settings. Each one says on its own panel how its messages end and how long it waits for an answer." **Add device** creates a device of that driver on the line, with no unit id, and the table has no **Unit ID** column: any number of instruments share the line, told apart by what their requests say.

On a line of the Omron driver the card reads "Every PLC on this line shares its port settings and answers to its own unit number. Each one says on its own panel how long it waits for an answer." **Add device** creates a PLC on the line under the first unit number free from 0 to 31, a copy of a device takes the next one free, and the table has the **Unit ID** column: up to 32 PLCs share the line, each answering to its Host Link unit number.

## What a line does not do {#what-a-line-does-not-do}

A line takes no folders: its devices are filed by the line and by nothing else, and the Move to menu is not offered on them. A device cannot be moved to another line; Copy device keeps the copy on the same line, under the next free unit id on a Modbus RTU line. The tuple cannot vary per device, and the port is never opened without a device: an enabled line with no enabled device reads Idle and holds no session, which is also what makes it safe to scan.