Exception 06 (0x06) — Server Device Busy

The server is engaged in a long-duration program command and cannot accept the request now. It is an explicit ask to retry later — distinct from exception 05 (Acknowledge), which means the request was accepted but will take a while.

Start free Modbus → canonical

Diagnosis

When you hit this

Polling a device during a program download, firmware update, or flash write.
Poll rate above what the device can service, so its request queue never drains.
Several masters polling one slave, which is common after someone adds a second SCADA client.

Resolution

How to fix it

Slow the poll rate
Increase the interval until 06 stops. Most controllers are comfortable well below the rate people first configure.
Count your masters
Two clients polling one serial slave produce 06 and timeouts that neither client can explain from its own logs.
Back off, do not retry immediately
06 explicitly means later. An immediate retry usually earns another 06.

Normalization

What Forge does about it

This is a transport failure, so there is nothing for Forge to normalize: the reading never arrives. What Forge does is refuse to let the gap look like good data. The read-time dropout check flags a field that fell to zero and recovered as a communication glitch rather than a real measurement, and the stuck-sensor check fires when a value repeats for 20 consecutive readings — which is what a cached or last-known value looks like after a link drops. Forge does not retry or reconnect for you; that is your client's or your gateway's job.