Start/end traversal height parameter names

dev discussion
1

I would like to make the following universal:

  • minimum_traverse_height (/ minimum_traverse_height_at_beginning_of_a_command / minimum_traverse_height_at_beginning_of_command)
  • z_position_at_end (/ z_position_at_end_of_a_command / z_position_at_end_of_command / z_position_at_the_command_end)

which even in the STARBackend have many names…

what are good names for the universal parameters?

1 Like
2

Fundamentally there are always 3 time zones for any command:

  1. beginning of command → minimum_traverse_height_at_start_of_command
  2. during command → minimum_traverse_height_during_command
  3. end of command → z_coordinate_at_end_of_command

#1 is needed because some commands (e.g. aspirate) might start with their pipettes left in low z-coordinate from a previous command, and without a clear declaration of where to move to at the start of the command, the pipette is at risk of crashing sideways into other physical objects on the move to where it has to go.

#2 is important when a command moves up and down (in z dimension) multiple times in different x-y locations. Without it pipette movement cannot be optimised.

Note: #1 and #2 might not be needed for all commands; e.g. z-probing has a search_start_coordinate instead, and doesn’t move in traverse.

An associated topic:
What is “position” and what is “location” in PLR, and when should we use which?

Coordinate, x-coordinate, y-coordinate, z-coordinate are well defined by code in comparison.

3

yes, we also have during command, thanks for reminding me

for naming, ideally we have a name that is similar for all of them, maybe:

  • minimum_traverse_height_start
  • minimum_traverse_height_during
  • minimum_traverse_height_end

_command is unnecessary since it’s a parameter to a command

the concept of search_start_coordinate in z probing is very different since as you mention it does not traverse so it’s speaking about a different concept. If z probing did traverse, it would need minimum_traverse_height_start. Also, I can’t find search_start_coordinate, which would also be incorrect since coordinate is 3d whereas the z axis is just 1d.

location = space and position = setting of an axis/quantity?

1 Like
4

I like this and agree it would be an excellent standard across all of PLR.

It’s what start_pos_search maybe should be called.

So you are saying that Coordinate is always 3D, what should we call each of its 1D arguments, i.e. x-something, y-something, z-something?

Can you please elaborate what you mean by this?

5

strong disagree

Coordinate is a common type in PLR but confusingly it would NOT be what this param expects.

Yes Coordinate is always 3D (in PLR)

claude explains better than me:

  • Location — where something is, often in absolute or named terms (a place in the world, a named address)
  • Position — where something is, often relative, ordered, or numeric (index in a list, coordinate in space)
6

What does that mean in PLR code examples?

Because at the moment the terms “location”, “position”, and even colloquial “coordinate” are used interchangeably in PLR, which is confusing, and should be written down with an explanation in the docs with examples once clear terminology has been identified.

What should we then call specific axis coordinates, now that it has been clearly stated that the word Coordinate must not be used this way because it always means 3D?

7

location talks about space, like resource.location and preferred_pickup_location and get_default_child_location

position is like joint position, bucket 1 position vs bucket 2 on centrifuges, PlateLockPosition on hamilton heater shaker, focal position. kind of space related (since it’s physical objects so everything at some point reduces to physical location and rotation) but in these cases not clearly talking about absolute space, more so about “relative/ordered/numeric”

What should we then call specific axis coordinates, now that it has been clearly stated that the word Coordinate must not be used this way because it always means 3D?

like location_x etc. maybe?

depends on context also. like there is a joint on the pf400 called “base” which controls the z location, but the joint value I would prefer to call a position since it’s a joint that later translates into space (when you think about other joints that do not map 1:1 to cartesian this is easy to see)