I am a Tecan user and plan to use pylabrobot with our Tecan EVO. I was able to install all the driver, connect to the device and initialize it through pylabrobot.
However, the initialization crashes at the LiHa initialization. The issue was that when checking for a collision, pylabrobot retrives the LiHa position with: “EVOArm._pos_cache.setdefault(self.module, await self.report_x_param(0))”. For some unexpected reason on my install that function returns a string instead of an integer. I was able to proceed with the initialization by parsing the position to an integer ("“int(EVOArm._pos_cache.setdefault(self.module, await self.report_x_param(0))”).
I know the integration between pylabrobot and the Tecan is still underdevelopped, but I haven’t seen any similar issue on the forum nor in github.
Is that something specific to my installation? Would it make sense to do a pull request for that?
Thanks for pointing out the exact parser line. In fact in my example, x was a negative value (-160 or something similar) str.isdigit() is indeed false for negatives. However, I cannot tell yet why the value received is negative, from what I understand from both PLR and Tecan the coordinates system should be strictly positive isn’t it?
The trick didn’t raise any issue during my initialization tho, so it doesn’t raised any of the Tecan error checks.
I can try to sniff a bit more of my Tecan positions to understand that better
from what I understand from both PLR and Tecan the coordinates system should be strictly positive isn’t it?
for both, actually: no!
in PLR: abstractly, the coordinate system has an arbitrary origin. It’s just a model of where things are relatively to each other. It’s only at the backend level that things get translated from PLR coordinates into machine coordinates (which do have an absolute 0).
some machines, like the EVO might have coordinate systems that run negative
what’s more: the evo actually allows people to define their own coordinate systems (which is kind of nice), and apparently these can run negative as your robot does
If you wouldn’t mind testing it, I am (read: claude is) writing backend to fix the root cause (the parser)
From my understanding of both function, calling them with param = 0 gives the current position, and with param = 5 the range of the axis (so the maximum position) right ?
Overall the fix works as we are correctly parsing this ‘-164’ and the resulting command is accepted by the Tecan. It also goes to the expected location for the initialization part. However I am still a bit concern by both the datatype and the value. I will keep my prints when testing the library but so far I haven’t seen any other occurrences of a string nor a negative.
yes
0: Report current position in 1/10 mm.
5: Report actual machine range in 1/10 mm .
There are actually many more, as of yet undocumented in PLR:
0 Report current position in 1/10 mm.
1 Report acceleration in 1/10 mm/s^2.
2 Report end speed in 1/10 mm/s.
3 Report initialization speed in 1/10 mm/s.
4 Report initialization offset in 1/10 mm.
5 Report actual machine range in 1/10 mm.
6 Report deviation in encoder increments.
7 Report displacement offset in 1/10 mm.
8 Report scale adjust factor.
9 Report slow speed in 1/10 mm/s.
10 Report scale factor.
11 Report target position in 1/10 mm.
I’ll document those
for the STAR we chose to convert everything to mm units on the Python level, just dealing with 0.1mm units on the firmware level (not user facing). I would like to make a similar change to the EVO if you’re ok with it. I think it’s better to do it sooner while the EVO backend has few users, rather than causing more pain like the STAR backend, setting up for greater future success
Oh sorry for the potential misunderstanding, your PR fixes indeed the problem. The RPX responses I have shared are print statement before your parse_response function call. The negative string (“-164”) is correctly parsed to a number (-164) with your fix.
Regarding the 0.1mm unit, let me check if I understand it correctly. Right now a value of 1273 means “127.3 mm” is that right? And you would like to change that to 127.3 in the python level? If that’s the case, I am definitely ok with it. It also aligns with how the units are shown on Freedom EvoWare as well, thus making the transition to PLR easier.
Btw, if I can be of any help with the documentation (depending on my time with my work), I’ll be happy to help
