Repository navigation
Log the implement geometry again once requested values arrive #133
Description
Sub-issue of #132.
Problem
The TC prints the implement geometry table once, when the pool activates. For implements that only declare the geometry as process data (DPD) rather than as fixed DDOP values (DPT), the table is empty at that point. The real values arrive about 15–35 ms later, as answers to the TC's value requests. They end up as separate Element N reports … lines, and the table is never printed again.
So the log never shows the geometry the grouping was actually based on in one place. In particular:
- Linked mode (one Function with 3 Sections): the values arrive, but the AOG mapping stays one-to-one, so no summary line follows. The only evidence the values were used is six scattered lines.
- Unlinked mode (3 Functions with one Section each): there is a mapping line, but the table above it still shows
-everywhere. - The
[Hardware Message] Implement: RDS Artemis (3 sections)line sent to AOG still says 3 sections after grouping has reduced it to 1 AOG section.
What the RDS Artemis sends at boot
Field log from 2026-11-11, branch #131 (va271aa7), --log_level=debug, unlinked mode, groupOverlappingSections: true. The client NAME is scrubbed, and the repeated per-element subscription lines are cut.
[14:01:05.031] [Info][TC Server]: New client 0xEB detected via WorkingSetMaster. Requesting version.
[14:01:05.035] [TC Server] Client <client NAME> reported TC version 3
[14:01:06.229] [Info][TC Server]:Client 235 structure label(s) did not match. Sending 0xFFs as the structure label.
[14:01:06.266] [Info][TC Server]: No object pool found for client 235 localization label. Sending FFs as the localization label.
[14:01:06.311] [Info][TC Server]: Client 235 requests object pool transfer of 953 bytes
[14:01:06.532] [Info][TC Server]: Client 235 requests activation of object pool
[14:01:06.532] [TC Server] Client <client NAME> received DDOP: 953 bytes in 1 chunk(s) [953], fnv1a64=726a3f9f306c6b23 (already saved)
[14:01:06.534] Implement geometry: 3 boom(s), 3 section(s)
[14:01:06.534] Idx Element Boom SubBoom X (mm) Y (mm) Z (mm) Width (mm)
[14:01:06.534] ---- ------- ---- ------- ------- ------- ------- ----------
[14:01:06.534] 0 6 2 - - - - -
[14:01:06.534] 1 7 3 - - - - -
[14:01:06.534] 2 8 4 - - - - -
[14:01:06.534] [TC Server] Attempting Section Control via: DDI 290 (SetpointCondensedWorkState) + DDI 289 (SetpointWorkState) for 3 sections.
[14:01:06.534] [TC Server] Sections are split over 3 elements with their own condensed DDIs:
[14:01:06.534] Element 2: sections 1-1
[14:01:06.534] Element 3: sections 2-2
[14:01:06.534] Element 4: sections 3-3
[14:01:06.534] [TC Server] Client <client NAME> registered successfully with 3 sections.
[14:01:06.534] [TC Server] Client <client NAME>: geometry gives 3 AOG section(s) for 3 implement section(s) (1->1, 2->2, 3->3)
[14:01:06.534] [Info][TC Server]: Object pool activated for client 235
… DDI 141 / 160 subscriptions on elements 0, 2, 3, 4; DDI 290 mapped to elements 2, 3, 4 …
[14:01:06.535] Requested Device Element Offset Y from element 6
[14:01:06.535] Requested Actual Working Width from element 6
[14:01:06.535] Requested Device Element Offset Y from element 7
[14:01:06.535] Requested Actual Working Width from element 7
[14:01:06.535] Requested Device Element Offset Y from element 8
[14:01:06.535] Requested Actual Working Width from element 8
[14:01:06.535] Measurement commands sent.
[14:01:06.568] [TC Server] Element 6 reports Device Element Offset Y = 0 mm
[14:01:06.568] [TC Server] Element 6 reports Actual Working Width = 6000 mm
[14:01:06.568] [TC Server] Element 7 reports Device Element Offset Y = 0 mm
[14:01:06.568] [TC Server] Element 7 reports Actual Working Width = 6000 mm
[14:01:06.568] [TC Server] Element 8 reports Device Element Offset Y = 0 mm
[14:01:06.568] [TC Server] Element 8 reports Actual Working Width = 6000 mm
[14:01:06.568] [TC Server] Client <client NAME>: geometry gives 1 AOG section(s) for 3 implement section(s) (1->1, 2->1, 3->1), applied
[14:01:06.568] [TC Server] Client <client NAME>: reporting 1 section(s) to AOG (1->1, 2->1, 3->1)
[14:01:06.949] [Hardware Message] Implement: RDS Artemis (3 sections)
In linked mode (13:55, 851-byte DDOP), the table shows one boom (element 2) with sections 6, 7 and 8, all -. Then come the answers Y = -5999 / 1 / 6001 mm, width 6000 mm each, and nothing after that.
Timing from the field logs (pool activation → last answer): linked +16 ms, unlinked +21 ms and +34 ms. The TC only requests Offset Y (DDI 135) and a width (DDI 67, else 70, else 68), so X and Z stay unknown.
What it should look like
Once the last requested value has arrived, print the table again with the filled-in values, mark which values were requested, and show the AOG section each implement section maps to:
[14:01:06.568] Implement geometry with requested values (3 of 3 sections complete):
[14:01:06.568] Idx Element Boom SubBoom X (mm) Y (mm) Z (mm) Width (mm) AOG
[14:01:06.568] ---- ------- ---- ------- ------- ------- ------- ---------- ---
[14:01:06.568] 0 6 2 - - 0* - 6000* 1
[14:01:06.568] 1 7 3 - - 0* - 6000* 1
[14:01:06.568] 2 8 4 - - 0* - 6000* 1
[14:01:06.568] * requested from the implement (not a fixed DDOP value)
[14:01:06.568] [TC Server] Client <client NAME>: reporting 1 section(s) to AOG (1->1, 2->1, 3->1)
[14:01:06.949] [Hardware Message] Implement: RDS Artemis (3 sections, 1 AOG section)
Linked mode, where the mapping stays one-to-one, so the table is the only summary:
[13:55:28.521] Implement geometry with requested values (3 of 3 sections complete):
...
[13:55:28.521] 0 6 2 - - -5999* - 6000* 1
[13:55:28.521] 1 7 2 - - 1* - 6000* 2
[13:55:28.521] 2 8 2 - - 6001* - 6000* 3
When values are still missing after a timeout (for example 2 s), print the table once with what is known and say what is missing, so a silent implement is visible too:
Implement geometry with requested values (2 of 3 sections complete; no answer from element 8 for Offset Y):
...
Grouping needs every section's Offset Y and width; keeping one AOG section per implement section.
Acceptance
- The table is reprinted once per pool activation: when all requested geometry is in, or at the timeout.
- Requested (DPD) values are marked, so they can be told apart from fixed DDOP (DPT) values.
- An
AOGcolumn shows the active mapping. WithgroupOverlappingSectionsoff, it shows the one-to-one mapping, and the existing "not applied" line still shows the proposed grouping. - Values that are never answered are named in the log.
- The hardware message to AOG names the AOG section count when it differs from the implement's.
- A later value change (for example the operator toggling linked mode without a pool re-upload, if any implement does that) reprints the table. One line per change is enough.
The table is printed in src/task_controller.cpp (Implement geometry: in activate_object_pool). The requests are made in request_measurement_commands, and the answers are handled in on_value_command (all on the #131 branch).
Activity