Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(hardware): give options for sensor data output during probe #14673

Merged
merged 14 commits into from
Mar 25, 2024

Conversation

caila-marashaj
Copy link
Contributor

@caila-marashaj caila-marashaj commented Mar 15, 2024

Overview

These are some small changes that help accommodate liquid-level detection testing in the hardware layer.
EXEC-337

Changelog

  • add AddSensorLinearMoveRequest, SendAccumulatedPressureDataRequest CAN messages
  • add sensor_report Move Condition to allow us to request that the firmware accumulate data in the necessary manner for hardware testing.
  • modify tool_sensors.py to allow its users to choose between reporting sensor data to the CAN bus only, writing sensor data to a csv file, or not reporting data at all during a pass.

Review requests

The CAN messages mentioned above will probably be temporary additions to edge, but I think merging them and potentially later on removing them may be the best way to go about this. Let me know if not.

@caila-marashaj caila-marashaj force-pushed the add-tool-sensors-option-for-lld branch from f4ca186 to 5c1c040 Compare March 15, 2024 19:49
@caila-marashaj caila-marashaj changed the title givet tool sensors output options refactor(hardware): give options for sensor data output during probe Mar 15, 2024
@caila-marashaj caila-marashaj requested a review from a team March 15, 2024 20:31
Copy link

codecov bot commented Mar 15, 2024

Codecov Report

Attention: Patch coverage is 64.17910% with 24 lines in your changes are missing coverage. Please review.

Project coverage is 67.17%. Comparing base (2857419) to head (500f2d0).
Report is 4 commits behind head on edge.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             edge   #14673      +/-   ##
==========================================
- Coverage   67.19%   67.17%   -0.03%     
==========================================
  Files        2495     2495              
  Lines       71563    71612      +49     
  Branches     9076     9076              
==========================================
+ Hits        48088    48105      +17     
- Misses      21330    21362      +32     
  Partials     2145     2145              
Flag Coverage Δ
g-code-testing 92.43% <ø> (ø)
hardware 55.43% <64.17%> (-0.11%) ⬇️
hardware-testing ∅ <ø> (∅)

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

Files Coverage Δ
api/src/opentrons/config/defaults_ot3.py 100.00% <ø> (ø)
api/src/opentrons/config/types.py 100.00% <ø> (ø)
...entrons/hardware_control/backends/ot3controller.py 68.48% <ø> (ø)
...pentrons/hardware_control/backends/ot3simulator.py 86.11% <ø> (-0.13%) ⬇️
api/src/opentrons/hardware_control/ot3api.py 79.55% <ø> (ø)
.../opentrons_hardware/firmware_bindings/constants.py 99.26% <100.00%> (+<0.01%) ⬆️
.../firmware_bindings/messages/message_definitions.py 97.57% <100.00%> (+0.04%) ⬆️
...ns_hardware/firmware_bindings/messages/messages.py 91.66% <ø> (ø)
...ns_hardware/firmware_bindings/messages/payloads.py 95.95% <100.00%> (+0.07%) ⬆️
...ware/opentrons_hardware/hardware_control/motion.py 82.75% <100.00%> (+0.20%) ⬆️
... and 2 more

... and 1 file with indirect coverage changes

Copy link
Member

@sfoster1 sfoster1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple small things to change like removing prints and making a function invocation kwargs. I think I would have done the split of the CSV stuff slightly differently but I think this way will work and I'm interested to see how it turns out.



@dataclass
class SendAccumulatedPressureDataRequest(BaseMessage):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what response message does this use?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this prompts all of the ReadFromSensorResponse messages to be dumped from the array the firmware accumulates during liquid probe

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It sends the same ReadFromSensorResponse as we did before

return move_group


async def run_pass_output_to_csv(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We still need a way to gate the behavior here to see if we want to use the stream can messages to csv behavior we had before, or the new buffer-on-pipette then write we need.
the way we run the move group runner is different with the custom firmware.

the new custom firmware needs this logic

   messenger.add_listener(sensor_capturer, None)

    async with sensor_capturer:
        print("starting move group runner")
        positions = await sensor_runner.run(can_messenger=messenger)
        await messenger.send(
            node_id=tool,
            message=SendAccumulatedPressureDataRequest(
                payload=SendAccumulatedPressureDataPayload(
                    sensor_id=SensorIdField(sensor_id)
                )
            ),
        )
        await asyncio.sleep(10)
        messenger.remove_listener(sensor_capturer)
    await messenger.send(
        node_id=tool,
        message=BindSensorOutputRequest(
            payload=BindSensorOutputRequestPayload(
                sensor=SensorTypeField(SensorType.pressure),
                sensor_id=SensorIdField(sensor_id),
                binding=SensorOutputBindingField(SensorOutputBinding.none),
            )
        ),
    )

and the normal firmware needs what you have here

plunger_speed=plunger_speed,
mount_speed=mount_speed,
threshold_pascals=threshold_pascals,
output_format=OutputOptions.none,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we need to hook this up one more layer to ot3_api,
and if the Output Options chosen is the one that needs the custom firm we should assert here that
self._subsystem_manager.device_info[SubSystem.of_mount(mount)].revision.tertiary == "1"

# will be the same
duration=float64(abs(distance[movers[0]] / speed[movers[0]])),
present_nodes=pipette_nodes,
stop_condition=MoveStopCondition.sensor_report,
Copy link
Contributor

@ryanthecoder ryanthecoder Mar 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also needs to be gated on using the custom firmware or not, the normal firmware cannot process this stop condition
And we'll need to grab the changes from move_group_runner to handle this stop condition too

@ryanthecoder ryanthecoder force-pushed the add-tool-sensors-option-for-lld branch from fa01e9f to fd0aec9 Compare March 21, 2024 19:46
@caila-marashaj caila-marashaj force-pushed the add-tool-sensors-option-for-lld branch from fd0aec9 to 2864274 Compare March 25, 2024 14:39
@caila-marashaj caila-marashaj marked this pull request as ready for review March 25, 2024 17:39
@caila-marashaj caila-marashaj requested a review from a team as a code owner March 25, 2024 17:39
Copy link
Member

@sfoster1 sfoster1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, looks good to me!

@caila-marashaj caila-marashaj merged commit 36de306 into edge Mar 25, 2024
23 of 24 checks passed
@caila-marashaj caila-marashaj deleted the add-tool-sensors-option-for-lld branch March 25, 2024 20:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants