EVO's MCA96

General
1

Hello everyone, I’ve just started learning PLR and have a few questions. During testing on the EVO system with PLR, I encountered two issues:

  1. Our EVO system is configured with LiHa, RoMa, and MCA, with the MCA located in the middle. When using LiHa for Aspirate and Dispense, how can I make the MCA avoid interference?

  2. I used the make.py tool in PLR to convert the Carrier.cfg file from the workstation and updated the relevant PLR configuration files, such as the generated plate and platecarrier files. However, when performing pickuptips, there is a positional deviation, and the tips cannot be picked up. What could be the reason?

1 Like
2

welcome to the forum!

  1. The MCA arm is actually not implemented in the PLR EVO backend yet. I have the firmware documentation in case you want to contribute this.
  2. The EVO backend was actually developed by a different person (coincidentally also named Wilson), who is unfortunately no longer working on this project. I remember that the EVO he used had fixed channels, and so picking up tips might not have been tested fully. I see he left a comment # TODO: check z params, so this is the most likely explanation.

In short: the EVO backend requires some work. Initially, this was the case for the Hamilton backends as well, which have now been thoroughly tested and are generating data. Are you interested in working on this?

2 Likes
3

Thank you for the detailed explanation, @rickwierenga!

Contributing to PLR sounds exciting, although my experience with EVO firmware is limited. Nonetheless, I’m eager to give it a shot and work on resolving some issues in the EVO backend. Having access to the firmware documentation would be incredibly helpful—could you kindly share it with me?

As for the pickup tips issue, I’ve noticed another notable difference in how PLR and Evoware calculate site positions. For instance, on an MP_4Pos Carrier, PLR assigns positions in reverse order compared to Evoware. Specifically, what PLR considers as MP_4Pos[0] ~ MP_4Pos[3] corresponds to MP_4Pos[3] ~ MP_4Pos[0] in Evoware. Could this discrepancy be causing the misalignment I’m observing—approximately 8mm on the x-axis and 12mm on the y-axis?

4

sounds good! i’ll dm :slight_smile:

the ordering shouldn’t really make a difference, in that case it would just pick up a different tip right?

5

Not entirely sure, but I’ve been wondering if the issue could be related to the order, which might be causing the x/y coordinate calculations for the tip spot to be off