Merge pull request #4931 from FlowFuse/modbus-degrading

Blog: Diagnosing Modbus Degradation: From CRC Errors to TCP Timeouts

Author: PabloFilomeno83

src/blog/2026/04/diagnosing-modbus-degradation.md

@@ -24,7 +24,7 @@ Except "working" and "working correctly" are different things in Modbus polling,
 
 The mistakes aren't exotic. They're the same ones across almost every installation: polling everything at the same rate, ignoring timeouts, stacking too many registers into single requests, or hammering slow devices with back-to-back queries they were never designed to handle. None of these are obvious from the outside because Modbus doesn't complain. It just silently drops a frame or lets the device go quiet — and your polling stack fills in the gap by returning the last successfully read value, making the problem invisible until someone notices the data has stopped changing.
 
-This article isn't about the basics of how Modbus works. If you need that, start [here](/blog/2026/01/why-modbus-still-exist/). This is about the specific configuration decisions that separate a polling setup that stays stable for years from one that causes problems at the worst possible time. Part 1 covers the three mistakes made at commissioning. Part 2 covers what happens after the system is running.
+This article isn't about the basics of how Modbus works. If you need that, start [here](/blog/2026/01/why-modbus-still-exist/). This is about the specific configuration decisions that separate a polling setup that stays stable for years from one that causes problems at the worst possible time. It covers the three mistakes made at commissioning. The next article covers what happens after the system is running.
 
 ## The Myth of the Universal Scan Rate
 
@@ -139,4 +139,4 @@ The three problems this article covers, scan rate uniformity, timeout miscalcula
 
 The fix for all three is the same kind of work: deliberate, once, documented. Tier your scan rates to match how fast your data actually changes. Calculate your timeouts from the physics of your network rather than accepting defaults. Read the register map before you batch. None of this takes long. None of it requires downtime. It just requires treating these as decisions rather than defaults.
 
-If you've made these changes and your installation is still misbehaving, the problem is in the operational layer: how your polling architecture handles the network and devices once they're running. That's what Part 2 covers: serial versus TCP failure modes, unresponsive device handling, live diagnostics, and how to fix what you find without taking production down.
+If you've made these changes and your installation is still misbehaving, the problem is in the operational layer: how your polling architecture handles the network and devices once they're running. The next article covers that: serial versus TCP failure modes, unresponsive device handling, live diagnostics, and how to fix what you find without taking production down.