Repository navigation
A DDOP with two booms: the condensed setpoint goes to the second boom's element only, the first boom never moves #115
Description
Summary
With a DDOP that has two boom elements, each with its own condensed work state DDIs, the TC registers all sections as one list and sends the combined condensed setpoint to the second boom's element only. The first boom never receives a setpoint and its sections never move, while AOG's section states show all of them.
What we ran
isobus-implement-sim profile airseeder-12m: two booms of six sections each, DDI 161 (actual condensed work state) and DDI 290 (setpoint condensed work state) on each boom element, DDI 160 section control state on the device element. Against 4ede403, headless on vcan0, driven from a Python stand-in for AOG (tests/scenario_tc.py). Every one-boom profile in the same run follows its setpoints with the profile's delay; this one does not. The log shows the 12 sections registered in one list and one DDI 290 command, with the 12-section value, addressed to the second boom's element.
What would help
Either of these, and a log line saying which:
- Refuse, or warn about, a DDOP with more than one boom, since the TC declares support for one boom in its capabilities and drives sections as one list.
- Or send each boom's condensed value to its own element, split by the sections that belong to it.
A real air seeder or a sprayer with front and rear booms is the case this stands for.
Activity
gunicsba commentedon Oct 23, 2026
The sprayer with front and rear booms will be more complicated IMHO. That would require AgOpenGPS to register the booms properly as currently we assume everything is in one line.
Air seeders that puts down fertilizer and seeds might be controlled by the same command just we send it twice.
Planters that have lets say 4+4 rows of fertilizer and 8 units for seed and another 8 units from microgranulate would be much harder unless proper multiboom is supported.
Usually these implements support copying from one boom. So you can pick your favourite (lets say cornseeds) then everything else will be turned on based on that.
gunicsba commentedon Nov 11, 2026
Confirmed on a real machine: RDS Artemis seeder controller
The same bug shows up with a real implement: an RDS Artemis (software 003.07) on a seeder with three dispensers, field-tested on 2026-11-11. One difference from the simulator profile: the Artemis puts DDI 160 on each Function as well, not on the device element. So the first two seeders were never switched to automatic either.
Fix: #131 (stacked on #130). Each element that carries its own condensed DDIs gets its own setpoint (sections numbered within it) and its own DDI 160. Its DDI 161/160 reports are read per element. DDOPs with one such element keep the existing path; that holds for all 24 sample DDOPs in the fixture collection.
DDOP (unlinked layout, 953 bytes)
Three Functions, each with one Section and its own DDI 160/161/290:
Before: develop + #130 (build 9d3c6d7), session 13:36:12–13:38:00
Every command went to element 4 (Seeder 3), as a 3-section value:
An earlier session (build b9126fd, 11:33) shows the same pattern: 110 setpoints and 3 Auto/on, all to element 4.
After: #131 (build a271aa7), 13:57 session
Seeders 2 and 3 follow the setpoint. Seeder 1 stays off: its dispenser has a hardware fault on that machine.
On the earlier comment about copying from one boom: that is how this machine is used. All three dispensers work the same 6 m strip and should follow one AOG section. That part is not covered by this issue, so it is tracked separately (link below).
🤖 Generated with Claude Code