Repo contains mapping files (which may need validation/correction) as well as scripts that re-format the mappings and check for consistency.
In particular, given a (specifically formatted) cavern mapping (stored in formatted_cavern), running
python parseXls.py <formatted_cavern_mapping>
will produce cavern mappings (formatted by Mark) in a convenient form for the software (and potentially also for checking the cabling in the cavern) in the output folder.
The cavern mapping was found to have mistakes because the PPP mapping had changed and the cavern mapping wasn't updated (or, potentially it was just copied incorrectly). Running
python check_mappings.py <mapping_with_nominal_PPP> <formatted_cavern_mapping> <check_against_compare_mappings> <check_cavern_lines_schematic> (-c <cavern_sense_table> -s <positronic_swap>)
will first check for (not easily fixable) typos in the formatted cavern mapping file (by making sure that all the nominal lines, which are trusted to be typo-free [this is likely not a fully correct assumption; but at least, the typos in the surface mapping seem isolated to the JPU/JPL iBB/P2B2 connectors, which is extraneous information for the line], can be found in the cavern mapping), outputting lines with typos to the command line. Then, once any typos in the cavern mapping are fixed (by the user), running this will check the nominal mapping vs the formatted cavern mapping (and, optionally, the mappings included in the compare file, if the third command line arg is true), check the LVR<->load mapping in the cavern mapping versus the most updated LV schematic stored in the nominal folder (if the fourth command line arg is true), and output PPP mapping mistakes to the fixme folder.
If the optional -c command is set, then NONE of the cavern (power) mapping check will be run, and no power tables will be produced. Instead, the sense lines as designated in the <cavern_sense_table> table will be checked vs Phoebe's mappings, and a sheet will be outputted listing the sense lines in the cavern. In this scenario, the normal positional arguments still have to be set, but actually the value of <mapping_with_nominal_PPP> is irrelevant (the <formatted_cavern_mapping> used should be CORRECT, as these lines will be used to derive the loads that are being sensed).
Not implemented here: output an unformatted cavern mapping with extra column indicating the correct PPP info in the unformatted_fixed_cavern folder, with generally the same structure as the formatted cavern mapping sheet. To then produce the software-usable cavern mapping, the user should take the unformatted cavern file, format it however desired, delete the old PPP info columns, store this edited file in the formatted_cavern folder, and run parseXls with it as input.
In order to fix the cables that were made incorrectly due to the mistakes in the cavern mapping, the procedure that is being followed is to first relabel PPP positronic connectors (with the primary intention being that they turn into connectors with the correct populated pins wrt the fixed cavern mapping) and then to relabel the cables on the LVR side so that the correct LVRs get routed to the intended line (currently broken because of the cavern mapping mistakes). In order to facilitate this, the user should input which positronic connectors are being swapped in formatted_cavern/swap_positronic.xlxs. Then, running check_mappings as above with the optional <positronic_swap> input will output an additional sheet move_labels.csv in the fixme folder that will indicate where to move the LVR-side labels (ie. given a label currently on a cable, the sheet will tell the shifters which label should replace it). This procedure will render the information on the cables' PPP-side labels incorrect (the line information is already incorrect already, anyway); this information could either be updated by the shifters that are fixing the cables (PPP positronic/pin info should be obvious from where the cable goes, and the line info could be updated once the LVR labels are done being swapped), just crossed out, or corrected also using the move_labels.csv file (which will indicate where to move PPP-side labels similar to how it describes where to move LVR-side labels).