feat(api): add deck conflict checks for trash bins loaded via addressable areas

[jbleon95]

Overview

Closes out RSS-421.

This PR adds the new trash bins, added in 2.16 and loaded via addressable area data, to deck conflict checking in PAPI. Previously all these checks were covered by the labware conflict checking, since the trash containers used to be labware. With the change away from that in the 7.1 release, these checks were lost and protocols that should not pass analysis were.

Now trash bins are taken into account when loading a thermocycler on the Flex (you cannot load a thermocycler when there is a trash in slot A1 and vice versa), and when loading a heater-shaker near the fixed trash on the OT-2. This also opens up potentially adding conflicts for the waste chute, but since none exist currently it is not taken into account.

Test Plan

Verified that the following protocols now fail analysis.

metadata = {
    'protocolName': 'Thermocycler conflict 1',
}

requirements = {
    "robotType": "Flex",
    "apiLevel": "2.16"
}


def run(context):
    thermocycler = context.load_module("thermocyclerModuleV2")
    trash = context.load_trash_bin('A1')

metadata = {
    'protocolName': 'Thermocycler conflict 1',
}

requirements = {
    "robotType": "Flex",
    "apiLevel": "2.16"
}


def run(context):
    trash = context.load_trash_bin('A1')
    thermocycler = context.load_module("thermocyclerModuleV2")

metadata = {
    'protocolName': 'Heater-shaker conflict OT-2',
}

requirements = {
    "robotType": "OT-2",
    "apiLevel": "2.16"
}


def run(context):
    # Both these lines should raise
    heater_shaker = context.load_module("heaterShakerModuleV1", '11')
    heater_shaker_2 = context.load_module("heaterShakerModuleV1", '9')

Changelog

• add new TrashBin class to deck conflict check

Review requests

Risk assessment

Low, this introduces no new functional behavior and re-adds checks that were previously being done in lower API levels.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (77e47c2) 68.14% compared to head (de40c31) 68.14%.
Report is 5 commits behind head on edge.

Additional details and impacted files

@@           Coverage Diff           @@
##             edge   #14325   +/-   ##
=======================================
  Coverage   68.14%   68.14%           
=======================================
  Files        2512     2512           
  Lines       71479    71479           
  Branches     9079     9079           
=======================================
  Hits        48706    48706           
  Misses      20670    20670           
  Partials     2103     2103           

Flag	Coverage Δ
g-code-testing	96.48% <ø> (ø)
notify-server	89.13% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[SyntaxColoring]

Mostly looks good, just a pedantic thing about the public TrashBin class.

[sanni-t]

LGTM! I quite like how simple this approach turned out to be. But I agree it's going to be tough to use for any other kinds of conflict checks where we need to look at the actual dimensions of the bin, so updating this approach in a follow-up sounds good to me.

[sanni-t]

Oh! We should actually remove/update this comment from this & the other check calls too. This is talking about labware & module ID duplication from setup-command-based LPC, which is no longer in use. In that way, we should be able to safely fetch the IDs from the engine directly, but I think quite a few entities in the engine-based API are now relying on these in-api labware and module storage so we can't just replace them easily without checking all usages. But it's also not in the scope for this ticket. So maybe just an updated comment explaining 'that this is outdated and we should fetch the IDs from engine now' should suffice.

[SyntaxColoring]

TY!