The PADID scan scans over all PB PADIDs and checks if communication with a PB could be established. Currently, it assumes that the PB will have PADID=0. This is true for the barrel, but end-cap PBs have different unique PADIDs per type.
This MR addresses this issue.
It further accounts for a specialty of the R3 PBs on the R3 carrier-board. R3 basically consists of two barrel powerboards, so 2x AMAC, 2x HVMux, 2x LinPol, etc. Each of the AMACs on the R3 has a separate PADID. The data-lines on the R3 carrier card are shortcut for the two AMACs of one PB. That means that the data-line in powerboard slot x, where x is even, are connected to those of powerboard slot x+1.
If running the PADID scan first on the even PBs (yielding PADID=5), the PADID scan gets confused in the next step when running on the odd powerboards. This is, because it tries to assign a different AMAC-ID to PADID=5 (which it already scanned), instead of just finding PADID=6.
An easy solution is just to skip PADID=5 if running on the odd R3 powerboards, labelled
R3_0 (the even R3 PBs) and
R3_1 will always be tested together (see a future MR), all PADIDs are still tested in that way (as
R3_0 has PADID=5). This is also addressed in this MR.