Keep implements in automatic mode on AOG's current section demand

[gunicsba]

Summary

Section setpoints were only sent when AOG's PGN 229 demand changed. When it didn't change, an implement in automatic ran on its own state. In a field log from 2026-10-13, a Sulky Isolink spreader in automatic spread full width for 17 and 47 minutes without receiving a single setpoint. The operator reported it as "the implement doesn't respond to commands", but no commands were being sent.

How it happens: AOG turns its own section Auto button off on every field open/close (JobNew()/JobClose()). The ISOBUS SC button keeps showing green, because it reflects the TC heartbeat. So after a field change, AOG's demand stays all off, the TC never sends anything, and the spreader switches all 12 sections on when its master switch goes on. AOG draws coverage from the implement's reported sections, so the map looks normal.

Two related gaps:

• When the implement's master switch went on, it wasn't told the current setpoint.
• When AOG stopped sending PGN 229 (field closed), the last demand stayed in force, even with sections on.

Changes

• MyTCServer keeps AOG's latest demand and treats no PGN 229 for 2 s as all off. It logs both transitions.
• Client setpoints are kept current in manual mode too.
• The full setpoint (every condensed block, plus DDI 289 Setpoint Work State, forced) is sent:
  • right after section control is enabled (PGN 241);
  • right after the implement reports DDI 160 = automatic (e.g. switched on its own terminal);
  • right after any element's Actual Work State (DDI 141) goes from off to on while in automatic;
  • every 2 s while in automatic (SECTION_SETPOINT_REFRESH_MS).
• Change-driven sends work as before.

Behaviour change

With section control enabled but AOG asking for no sections (Auto off, or no field open), the implement is now told off and stops working. Before, it ran on its own state. Over-application becomes under-application, which the operator notices immediately. The section demand diagnostics PR adds a log line and an AOG message that explain why.

Notes

• Related to Switch section control on automatically when an implement connects #102 (switching to automatic on connect): with this PR, auto-on-connect is followed straight away by the current demand, instead of the implement's own state.
• Conflicts with the TC restart recovery PR in Application::update(). Keep both sides; the resolution is in test/szello-debug.

Testing

• Release build passes on Windows (MSVC).
• Not yet run on a bus. Checked against the field log: the Sulky follows setpoints within ~80 ms and stays off when the master goes on after an all-off setpoint, so these sends do take effect on that implement. A debug build is going to the same machine.

🤖 Generated with Claude Code