fix: assembly of quad modules / triplet modules with serial number determination
Fixing bug reported by @gemmec via email:
usually I assemble my modules using the Unicorn interface, but I know that it does not check the new module S/N, neither if parts are in my place, therefore I tried the LocalDb interface.
I am surprised as I got a S/N that is not expected.
According to the EDMS AT2-IP-EP-0026 the module name is just 20UPGM2 X 012345
X = The first classification digit is used for the FE chip version for both quads and triplets (2 for v1.1). The last 6 digits (for pre-production and production) of the serial number for quads will be the same as the PCB serial number.
Therefore when I assemble a module with flexPCB 20UPGPQ2210482 I should get 20UPGM2 2 210482 while the local PDB reports 20UPGM2 2 200482 i.e. a different 3rd classification digit than expected [ see below]
anybody has observed anything similar?
This bug was due to two separate problems.
-
fix corrupted ITkPD information for the bare module / sensor tile so localDB doesn't think it's a triplet -
added a checkbox to indicate if triplet or not (to allow entering the triplet information) -
improve the flow handling for quads vs triplets to be more explicit about what the user is doing
The flow now looks like:
If one enables the triplet box like so:
There is more explicit information about using triplet instead of quad for serial number determination even though it's still labeled as an "OUTER_QUAD_MODULE" - quite simply, this is because one was trying to inject in triplet information, or treat it as a triplet for serial number handling which breaks things quite badly anyway. This at least fixes the issue for quad module assembly, but triplet needs to be figured out more properly.