they are still not exactly the same commands: aspiration volume is 13.3 ul vs 12.7 ul, slight differences in the x and y value of where the aspiration takes place but overall should give us some hint of what is going on with a 16-channel system in PLR… I haven’t found it yet, so thought I’d post it out here in the open
I think one of the clearest differences between these two commands is that you used capacitive liquid level search in VENUS (lm=1) but bottom aspiration in PLR (lm=0)?
Have you tried this exact same plate definition with channel plr_15/venus_16 via bottom aspiration in VENUS?
(plate definition differences should also be looked at, PLR’s can easily be shared as text, VENUS’ I guess could be shared as a series of pictures from the “labware editor” software that is one of the apps in the VENUS suite of Hamilton apps)
i like your analysis @CamilloMoschner. however, wasn’t @KarlCahill saying he uses the same code for 12 channels (works), 13 (timeout), 14 (error), 16 (error)? the only difference is use_channels is different
Hello again, thanks for your insightful feedback! And sorry for the long response time I was on vacation.
Interesting that the commands are not exactly the same for the volume. The “lm” is indeed 1 for the VENUS and 0 in PLR, however, this is also true for the other channels that work in PLR, therefore, I don’t think this is the core issue.
I dug a little deeper and had an observation which might cause the error with the channels 14 and 15 in PLR? The “&” is occasionally present at the end of serial commands e.g. (tm0 0 0 0 0 0 0 0 0 0 0 0 0 1 0&).
Interestingly, for some commands in VENUS the “&” is present for channel 12 and 13 but not for channel 14 and 15, for example the “tm” command. (all of these cahnnels are confirmed to work using the venus software). There are other commands in VENUS where the “&” is present for all channels. However, in PLR the “&” is not present for any commands with channel 14 and 15.
To get a clearer picture of this, I mapped out all the serial commands from each channel by VENUS or PLR as rows and each command as columns with a true / false if the “&” is present at the end of the command or not.
I tried tweaking the parameters in PLR to match what we see from the Venus serial command. Most of them seem redundant in this context but I tried aligning as much as possible, there were a few I was not able to touch, or at least I didnt figure out how to yet. Here’s the comparison of the serial commands in text format:
To me it seems there is a difference between PLR and VENUS in how long the serial commands are. For example PLR usually gives the full list for all channels (tm0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0), while venus truncates it to the amount of channels used and adds the ampersand, in this case 1 (tm&). I havent really dwelved much into serial commands before, but would it make sense to try and align this and see if it solves the issue?
the & closes a list of arguments when you want to send fewer values than the machine takes. eg in this case fewer than 16 because there is one parameter per channel.
the parameters are “one hot encoded”. the tm parameter is like a mask, having 1s and 0s, one for each channel (until you close it). a 1 means the channel is used and the parameter value in a different argument at the corresponding location should be used, 0 means don’t use. for example in simplified version:
xp2 3&tm0 1&
means don’t use the first channel (0 in PLR), so the 2 for xp is ignored. do use the second channel, so 3 is used.
i don’t understand why some values in your command have & and others do not
Thanks for the elaboration on how the commands work, makes sense. So we can ignore the additional parameters if the specified channel is not in use.
And thanks for pointing out the raw_command function! I can try to send the raw command identical to what the Hamilton generates, if that works i can try and work my way back from there to identify the “parameter out of range”
By any chance can the error code “er01/32” error 01/32 hint towards what parameter that might be out of range?
Both VENUS and PLR are configured to use the 16 channels. Everything works in VENUS, and all channels partially work in PLR. its only the aspiration that is causing issues with some of the last cahnels. all channels are able to pick up tips without any issue in PLR for example.
Ok i had some interesting revelations debugging this error.
I used to the “send_raw_command” and replaced the troublesome aspiration step with the serail command generated by hamilton. This works fine, and suprisingly the dispense step works directly with PLR subsequently.
i then tried to “break” the raw command by replacing a command at the time generated from PLR into the VENUS generated version. i found that specifically its the (at, il, in) commands that cause the out of range error. In VENUS these three parameters are written as a single argument followed by an ampersand, while in PLR it is the full list of the 16 arguments. Why this causes an issue is still a mystery to me, giving the full list of 16 aruguments work just fine for all other commands.
I then tried to see how VENUS would handle using all 16 channels at once, aspirating 10ul in a column and dispensing in the subsequent. The three commands causing the issue remained as a single argument closed with the &.
*** Ideas for fixing the bug ***
As far as i can see the at, il and in are commands for aspiration_type, ratio_liquid_rise_to_tip_deep_in and immersion_depth_2nd_section. I currently dont really need to adjust these parameters individually on the channels for my application, so my idea would be to add an exception to the “_assemble_command” function in the “base.py” to these three commands and keep the shortended version closed with ampersand? Perhaps not an ideal fix, but it might do the job for me atm.
I added this to the _assemble_command for custom handling of these three commands with the aspiration step.
Suprisingly, this also solved the timeout issue with channel 13 alltough it seemed to be a seperate isue.
if command == "AS" and k in ["at", "il", "in_"]:
# Use first value only + ampersand
v = f"{v[0]}&"
else:
# Default list handling
v = " ".join([str(e) for e in v]) + ("&" if len(v) < self.num_channels else "")
yes, in the log you shared above i see venus has only one value for these parameters. thank you for finding and flagging this.
i can see above the firmware version for all your pip channels is 2020-07-31, which should be recent.
maybe we should make PLR send only one value for these parameters (as you do above). Strangely, this has not been an issue for other people and would remove support for individually controlled ‘aspiration type’, ‘Ratio liquid rise to tip deep’ and ‘Immersion depth 2nd section’. and the firmware doc says this is supported
but in any case, real world beats any documentation.
your fix works, but ideally we should fix it at a slightly higher level so that the api reflects this constraint, is readable, and keeps HamiltonLiquidHandler._assemble_command agnostic to the command
i would update the type of aspirate_pip to make aspiration_type, ratio_liquid_rise_to_tip_deep_in, immersion_depth_2nd_section float instead of List[float]. Do you want to make a PR for this? i’m also happy to do it.
You’re very welcome, thank you for your kind support with finding the issue!
The firmware is a bit outdated, perhaps this is not an issue with newer versions?
I’m wondering how Venus handles individual control of the channels and what the commands look like for the aspiration_type, ratio_liquid_rise_to_tip_deep_in, immersion_depth_2nd_section. Ill get back to you on this thread if I get around to test it!
Happy to make a PR, we are however moving the machine this week. I can get around to test that the updated aspirate_pip function once it has been moved.
the firmware is actually quite recent, lab automation software (except PLR) moves slowly
do you mean ‘how does venus individually control these 3 parameters?’ my guess is it does not if it sends a single value instead of a list (i thought there is no & in the venus command, meaning it’s not a list parameter but a single value)
awesome! let me know if i can help with this in any way
Im not quite sure how to approach changing the aspirate_pip function as you suggested to keep it agnostic. Im happy to test it if you have sugestions for how we could change it in the STAR_backend rather thatn the base.
