cLLD Probing Starting Position Troubleshooting

General
1

Hi everyone,

I’ve noticed that the STAR_backend.clld_probe_z_height_using_channel() method might not correctly compute and start with its start_pos_search argument.

It appears that this argument refers to the bottom of the channel but in reality it should refer to the bottom of the tip (which is located on the channel).

Could someone please confirm this behaviour on their STAR?

This is a minimal code example for a STAR or STARlet to reproduce the behaviour:

channel_idx = 7
teaching_needle_tip_spot = "H1"
teaching_tip_rack = lh.deck.get_resource("teaching_tip_rack")
await lh.pick_up_tips(teaching_tip_rack[teaching_needle_tip_spot], use_channels=[channel_idx])
await lh.backend.prepare_for_manual_channel_operation(channel=channel_idx)

test_x_coordinate = 500
await lh.backend.move_channel_x(
    x=test_x_coordinate,
    channel=channel_idx)

test_y_coordinate = 150
await lh.backend.move_channel_y(
    y=test_y_coordinate,
    channel=channel_idx)

test_z_coordinate = 200 # <=== BOTTOM of TIP (confirmed)
await lh.backend.move_channel_z(
    z=test_z_coordinate,
    channel=channel_idx)

measured_z_clld = await lh.backend.clld_probe_z_height_using_channel(
    channel_idx=channel_idx,
    channel_speed=6.0,
    start_pos_search=200,  # <=== BOTTOM of CHANNEL (question?)
    detection_edge=5,
    post_detection_dist=2.0,
    move_channels_to_save_pos_after=True
)
measured_z_clld

If you see the channel “jump” from the z-height it was sent to in the penultimate command to the last command then the incorrect behaviour has been confirmed.

If the channel does not jump between these two commands and starts its cLLD search straight away then I have to check my machine :sweat_smile:

Note: This does not change anything about the results of the STAR_backend.clld_probe_z_height_using_channel() method → because it returns the z-height of the bottom of the tip at the moment of cLLD activation from a firmware side.

2

On my machine I have to add the total_tip_length minus the fitting_depth to achieve the correct behaviour:

test_z_coordinate = 200
await lh.backend.move_channel_z(
    z=test_z_coordinate,
    channel=channel_idx)

measured_z_clld = await lh.backend.clld_probe_z_height_using_channel(
    channel_idx=channel_idx,
    channel_speed=6.0, start_pos_search=200+lh.head[7].get_tip().total_tip_length-lh.head[7].get_tip().fitting_depth,
    detection_edge=5, post_detection_dist=2.0,
    move_channels_to_save_pos_after=True
)
measured_z_clld

I have not noticed this behaviour when I built this method and am wondering whether this behaviour is the same across different machines :slight_smile:

If so, I will quickly fix it with a small PR.

3

Found the answer:

A founding father let us know that on the arm-level (i.e. C0 module), the tip length is compensated for, but on the channel level (i.e. PX module) it is not!

My compensation approach for the tip using +total_tip_length - fitting_depth (always 8mm) is correct and I will submit a PR to fix this argument.

1 Like
4

thanks for sharing!

thanks!

1 Like