Repository navigation
Several dispensers on one strip show up as separate AOG sections (e.g. RDS Artemis seeder with 3 hoppers) #132
Description
Summary
An implement can have several dispensers or products on the same strip of ground, for example a seeder with three hoppers, all 6 m wide. The TC gives AOG one section per implement section. AOG then has to be set up with three sections and drive them separately, while on the machine they are one section: all dispensers should go on and off together.
Seen on an RDS Artemis (software 003.07) on a seeder with three dispensers on one 6 m working width, field-tested on 2026-11-11. Related to #115 (several booms, only the last one controlled), which this machine also hit.
What the implement tells the TC
The Artemis uploads one of two layouts, depending on a "linked" setting in its menu. Neither puts the section geometry in the DDOP as fixed values: the Y offset (DDI 135) and width (DDI 67) are only declared as process data. So the TC's geometry table shows -, and the TC can't tell whether sections overlap without asking.
When the TC asks (send_request_value), the Artemis answers:
| Layout | Structure | Y offsets reported (mm) | Widths (mm) | Meaning |
|---|---|---|---|---|
| Unlinked (953 B) | 3 Functions × 1 Section, each Function with its own DDI 160/161/290 | 0, 0, 0 | 6000 each | 3 dispensers on one strip: 1 section |
| Linked (851 B) | 1 Function × 3 Sections | −5999, 1, 6001 | 6000 each | 3 sections side by side, an 18 m machine |
So the unlinked layout describes this machine accurately. Linked describes a different one, e.g. hoppers that each cover part of the width.
Log: geometry replies (build a271aa7, 13:55 session)
[13:55:28.503] Client <client NAME> received DDOP: 851 bytes ... fnv1a64=96dce4acf942f818
[13:55:28.517] Element 6 reports Device Element Offset Y = -5999 mm
[13:55:28.517] Element 6 reports Actual Working Width = 6000 mm
[13:55:28.517] Element 7 reports Device Element Offset Y = 1 mm
[13:55:28.517] Element 7 reports Actual Working Width = 6000 mm
[13:55:28.521] Element 8 reports Device Element Offset Y = 6001 mm
[13:55:28.521] Element 8 reports Actual Working Width = 6000 mm
[13:56:48.850] Client <client NAME> received DDOP: 953 bytes ... fnv1a64=6a9aa30b9c9d7908
[13:56:48.869] Element 6 reports Device Element Offset Y = 0 mm
[13:56:48.869] Element 6 reports Actual Working Width = 6000 mm
[13:56:48.873] Element 7 reports Device Element Offset Y = 0 mm
[13:56:48.873] Element 7 reports Actual Working Width = 6000 mm
[13:56:48.873] Element 8 reports Device Element Offset Y = 0 mm
[13:56:48.873] Element 8 reports Actual Working Width = 6000 mm
[13:56:48.873] Client <client NAME>: geometry gives 1 AOG section(s) for 3 implement section(s) (1->1, 2->1, 3->1), not applied: groupOverlappingSections is off
DDOP structures (both layouts)
Unlinked (953 B) Linked (851 B)
DET 1 Device "RDS Artemis" elem=0 DET 1 Device "RDS Artemis" elem=0
DET 3 Function "Seeder 1" elem=2 DET 3 Function "Seeder 1" elem=2
DET 4 Function "Seeder 2" elem=3 DET 100 Section "Seeder 1 Section 1" elem=6
DET 5 Function "Seeder 3" elem=4 DET 101 Section "Seeder 1 Section 2" elem=7
DET 100 Section "Seeder 1 Section 1" elem=6 (parent 3) DET 102 Section "Seeder 1 Section 3" elem=8
DET 101 Section "Seeder 2 Section 1" elem=7 (parent 4)
DET 102 Section "Seeder 3 Section 1" elem=8 (parent 5)
Each Function links DDI 160, 161, 290 and 141. Each Section links DDI 134 / 135 / 67 (Offset X / Offset Y / Width)
as process data only.
Proposed handling
- Add allSectionsFollowFirst: drive every implement section from AOG section 1 #130:
allSectionsFollowFirst(manual override). Every implement section follows AOG section 1, and AOG sees one section. This worked in both layouts. - Basic multi-boom support; collapse identical/overlapping sections #131:
groupOverlappingSections(automatic, default off). The TC requests each section's Y offset and width. Sections with the same offset and width (within 10 mm) share one AOG section, and the heartbeat reports the merged count. The grouping is logged even while the setting is off, so we can see how it behaves on other machines before changing the default.
Log: unlinked layout with groupOverlappingSections on (build a271aa7, 14:01 session)
[14:01:06.534] [TC Server] Sections are split over 3 elements with their own condensed DDIs:
[14:01:06.568] 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] Client <client NAME>: reporting 1 section(s) to AOG (1->1, 2->1, 3->1)
Setpoints sent (3 on/off cycles of AOG section 1):
3 element 2 with value 1 ... 3 element 2 with value 0 ...
3 element 3 with value 1 ... 3 element 3 with value 0 ...
3 element 4 with value 1 ... 3 element 4 with value 0 ...
Dispensers 2 and 3 followed AOG's single section on every cycle. Dispenser 1 has a hardware fault on that machine.
Open questions
- Default for
groupOverlappingSections: keep it off until the logged "geometry gives …" line has been seen on more implements? Some DDOPs may report every section at Y = 0 with real widths, which would merge side-by-side sections by mistake. - Implements with overlapping products and several sections each (e.g. 4+4 fertiliser rows plus 8 seed units) group by position, so each strip becomes one AOG section. Is that what we want, or should one product lead?
🤖 Generated with Claude Code
Activity
gunicsba commentedon Nov 11, 2026
The geometry isn't known when the pool activates; it arrives right after.
The Artemis declares Offset Y (DDI 135) and Working Width (DDI 67) as process data (DPD), not as fixed DDOP values (DPT). So when the pool activates, the TC's geometry table is all
-. Grouping has nothing to work with yet and maps one implement section to one AOG section. The TC then asks each section element for the two values (#131), and the Artemis answers almost at once:What this means:
test_section_layout <file>.ddopon either captured pool gives "3 AOG sections". Grouping therefore has to be worked out after the answers arrive, on every pool upload, which is what Basic multi-boom support; collapse identical/overlapping sections #131 does.There's a log gap here: the table is never printed again with the filled-in values, and in linked mode nothing sums them up at all. The hardware message also still says "RDS Artemis (3 sections)" after grouping. The boot sequence the Artemis sends, and what the log should look like, are in sub-issue #133.
gunicsba commentedon Nov 11, 2026
Artemis Pinout:
