Understanding Child Positional Offsets w/ ResourceHolder

I am working on a module that serves as a Machine and ResourceHolder and I was wondering how to include the default offsets for the constituent child Plate. I have looked through the other variations of ResourceHolder instances (ex. PlateReaders), but I don’t see a standardized way of including default values for the size/position of a child of modules when a specific backend is invoked. (very well could be me missing a key feature of PLR).

Theoretically, when a specific backend is invoked as a resource holder, it should clue the system into the size and position of the child location instead of leaving those as a necessary user input field? Specifically for components that are of a certain size/have a dedicated structure.

Can you please help to bridge this gap in my understanding?

Thanks!

default child position for ItemizedResource is given using the child_location attribute. this will be the default location when assigning children. pylabrobot.resources.ResourceHolder.__init__ — PyLabRobot documentation

I understand that. To clarify, is there a way to automatically specify the child offset via the child_location attribute based on the model that is present?

With the convention of Frontend(backend=Backend(*args, *kwargs)), the Frontend is general with respect to the module type (PLR is designed to be universal/specific backend ambivalent) Additionally, the Frontend is the only one that is exposed to the PLR coordinates.

However what if the Backend might imply the position so that the user does not need to define measurements for their hardware components when they want to initialize the frontend position.

Essentially, is there any way to automatically pull in coordinates to the ResourceHolder (housed within the Frontend definition) by asserting that the backend is a certain type of module with known measurements and offsets for the child module?

yes, you can define a function that returns an instance of the front end. see example: pylabrobot/pylabrobot/sealing/a4s.py at 3ea817a31670e2d2693273fa275ed57058476a7a · PyLabRobot/pylabrobot · GitHub

(this is the reason we renamed all backends to explicitly say Backend, so we can have the proper name available for easy definitions. Update LiquidHandlerBackend Naming: Part 1 - Trigger Warning by BioCam · Pull Request #464 · PyLabRobot/pylabrobot · GitHub)

2 Likes

That is what I was looking for! Thank you!

1 Like

which machine are you working on?

For this specific, question, I am working on building out the MagnetModuleV2 in PLR. I will use this trick generally for future development as well.

1 Like