1. Baud Rate vs. Bit Rate vs. Cycle Time

Network timing terms are often fatally conflated, leading to poorly dimensioned control architectures:

• Baud Rate: This is the purely microscopic "speed" of the copper wire, measured in symbols per second (voltage shifts). In binary RS-485 baseband systems, one symbol equals one bit, so Baud Rate = Bits Per Second (bps). 9600 baud means exactly 9,600 electrical pulses squeeze down the wire every second.
• Bit Time: The physical duration of a single bit on the wire: $Time_{bit} = 1 / \text{Baud Rate}$. At 9600 baud, one bit takes $1/9600 = 0.000104s$, or 104.17 microseconds (μs). If the physical UART clock isn't synchronized exactly to this window, data corruption occurs.
• Cycle Time: The macroscopic total time it takes for a PLC to successfully poll every single slave device on the loop and process the inputs. A high baud rate does nothing if your devices' internal microprocessors take 100ms to wake up out of a low-power state and populate their UART transmission shift registers. Cycle time is the ultimate variable that dictates PID loop stability.

2. The Anatomy of a Serial "Character" (Byte)

In baseband serial comms, you mathematically cannot just "send 8 bits". The receiver has no clock line, so the UART integrated circuits (ICs) require an asynchronous frame surrounding your payload with strict electrical flags to properly re-sync their internal quartz oscillator clocks.

Total Bits per Character = 1 (Start) + Data Bits + Parity Bits + Stop Bits

A "standard" 8-N-1 format strictly consumes 10 bits on the copper wire just to send 1 byte of application payload. When forecasting network load, converting Bytes to Bits using a x8 multiplier is a catastrophic amateur error; you must multiply by 10 (or 11 depending on parity settings). If a receiver's clock drifts by more than half a bit-width before the Stop bit arrives, a "Framing Error" destroys the byte.

3. Where Does The Time Actually Go? (The T3.5 Gap)

Industrial Cycle time is rarely dominated by raw wire speed; it is heavily bogged down by intentional "silent time" and microchip latency. A Master-Slave poll cycle is a gauntlet of 5 distinct phases:

1. Request TX Time: Raw wire time to blast the electrical waveform ($[\text{Req Bytes}] \times [\text{Char Wire Time}]$).
2. Slave Processing Delay (Latency): The internal silicon delay. After the final Stop bit arrives, the sensor's firmware must parse the CRC verification, context-switch its RTOS CPU schedule, fetch the analog memory register, and push the array back into the UART transmit buffer. This physically takes 10 to 100+ ms on older ASICs.
3. Response TX Time: Wire time for the response frame payload to reach the PLC.
4. Inter-Message Overhead (T3.5 Gap): The Modbus RTU protocol legally requires exactly 3.5 character times of brutal electrical silence on the RS-485 line before the next frame begins to act as a hardware "line break" flag.

$$T_{poll} = T_{req} + T_{prop} + T_{slave\_delay} + T_{prop} + T_{resp} + T_{overhead\_T3.5}$$

Multiply $T_{poll}$ by your slave count, and you achieve your total loop cycle time. Because the $T3.5$ gap and Slave Delay are forced on every single transaction, polling 50 slaves creates massive compounding $T_{cycle}$ times.