Skip to content

Late-registering implement is never told to go to Auto if AOG enabled SC earlier #94

Description

@gunicsba

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions