Summary
The "section control enabled" (Auto) state from AOG is applied once, when AOG's 0xF1 packet arrives. A client that registers after that packet is never told to switch to Auto, and its per-client state stays false.
This is a suspected robustness gap found while reading the logs for #93. No log shows it happening. In the #93 session the Sulky registered at 09:52:56 and AOG's enable arrived at 09:53:11, so the ordering was fine. (#93 itself turned out to be a hardware fault on the machine, unrelated to this.)
What the code does
ClientState::isSectionControlEnabled defaults to false (include/task_controller.hpp:79).
MyTCServer::update_section_control_enabled() is only called from the 0xF1 handler (src/app.cpp:473-479). It iterates the clients registered at that moment and sends DDI 160 (Section Control State) to each.
- Object pool activation (
src/task_controller.cpp, around the "registered successfully" log) does not replay the last enable value to the new client.
MyTCServer::update_section_states() skips any client whose flag is false ("setpoints only in auto mode"), so a late client also never receives section setpoints.
- The only other writer is the client's own DDI 160 report (
src/task_controller.cpp:683-686), which is the machine's state, not AOG's.
Scenarios that could hit this
- AOG enables SC, then an implement is powered on or plugged in afterwards.
- An implement drops off the bus (or times out) and re-registers while AOG stays in Auto.
- The TC is restarted while AOG stays in Auto.
In each case the implement would stay in manual and get no setpoints, and the TC's 0xF0 heartbeat would report enabled = 0 for it.
Open question
Does AOG re-send 0xF1 periodically or on every heartbeat? If it does, this is self-healing and can be closed. If it only sends on a button press, the gap is real. docs/PROTOCOL.md does not say. Needs checking on the AOG side.
Suggested fix
Remember the last 0xF1 value on the server (or in Application) and apply it when a client's pool is activated with sections, i.e. call send_section_control_state() for it and set the client's flag. This should be a small change.
Test idea
Bench, no implement needed at the time of enabling: send 0xF1 = 1 from AOG (or a UDP script), then connect an implement with sections, and check that the log shows "Sending set value ... Section Control State ... Auto/on" without any further 0xF1 from AOG.
Summary
The "section control enabled" (Auto) state from AOG is applied once, when AOG's
0xF1packet arrives. A client that registers after that packet is never told to switch to Auto, and its per-client state staysfalse.This is a suspected robustness gap found while reading the logs for #93. No log shows it happening. In the #93 session the Sulky registered at 09:52:56 and AOG's enable arrived at 09:53:11, so the ordering was fine. (#93 itself turned out to be a hardware fault on the machine, unrelated to this.)
What the code does
ClientState::isSectionControlEnableddefaults tofalse(include/task_controller.hpp:79).MyTCServer::update_section_control_enabled()is only called from the0xF1handler (src/app.cpp:473-479). It iterates the clients registered at that moment and sends DDI 160 (Section Control State) to each.src/task_controller.cpp, around the "registered successfully" log) does not replay the last enable value to the new client.MyTCServer::update_section_states()skips any client whose flag isfalse("setpoints only in auto mode"), so a late client also never receives section setpoints.src/task_controller.cpp:683-686), which is the machine's state, not AOG's.Scenarios that could hit this
In each case the implement would stay in manual and get no setpoints, and the TC's
0xF0heartbeat would report enabled = 0 for it.Open question
Does AOG re-send
0xF1periodically or on every heartbeat? If it does, this is self-healing and can be closed. If it only sends on a button press, the gap is real.docs/PROTOCOL.mddoes not say. Needs checking on the AOG side.Suggested fix
Remember the last
0xF1value on the server (or inApplication) and apply it when a client's pool is activated with sections, i.e. callsend_section_control_state()for it and set the client's flag. This should be a small change.Test idea
Bench, no implement needed at the time of enabling: send
0xF1 = 1from AOG (or a UDP script), then connect an implement with sections, and check that the log shows "Sending set value ... Section Control State ... Auto/on" without any further0xF1from AOG.