Venus vs STAR backend

PyLabRobot User Discussion
1

What are pros and cons of using Venus backed vs STAR backend?

1 Like
2

VENUS is similar to PyHamilton in that it sends HTTP requests to a Venus universal method to execute commands. I wouldn’t recommend currently it because it doesn’t hook into the PyLabRobot deck model in the way that allows 1:1 convertibility between Venus deck models and PLR deck models. We hope to get this fixed in the next month or so.

STAR is a pure firmware backend, it talks directly to the robot through Python libraries and doesn’t go through Venus at all. It’s very very flexible but lacks some features that Venus provides namely a feature-rich simulator and deck visualization.

3

Thanks for the reply, Stefan. I’m currently a bit scared to switch to STAR for several reasons:

  1. the line " If you use a firmware driver such as the STAR driver provided here, you do so at your own risk. Usage of a firmware driver such as STAR may invalidate your warranty" in PLR git repo.
  2. how much harder is it to make changes to STAR backend (in case I need to) compared to Venus? since Venus is sort-of documented and relatively straightforward.
  3. how likely is it that Hamilton will make changes at the low-level interface that will break compatibility with PLR, compared to more high-level Venus?

Given the points above, what are the advantages of pure firmware (apart from deck compatibility)? Is there performance benefit? Or do you expect that future PLR features will be only available with STAR because it’s more flexible?

Finally, are you planning to support both backends or eventually deprecate one of them?

4

Unfortunately we are not yet endorsed by Hamilton, so there is no way around providing this disclaimer. We have a lot of command validation, as does the robot’s internal board, and I am happy to discuss specifics if desired.

It depends what changes you want to make, but we were pretty thorough in accounting for almost all of the possible firmware commands sent to the robot. Supporting other equipment depends on having the firmware reference document (or logs) for that equipment.

Pretty low, because you would have to overwrite how the robot board itself processes commands, which only Hamilton service techs (and similarly trained professionals) can do. These would also have to be reflected in Venus in any case.

Pure firmware has a few advantages that even a PLR-compatible Venus backend won’t have. These include:

  • Linux/ MacOS compatibility (this is why STAR was created in the first place).
  • Direct access to pressure and capacitance sensor data used to construct TADM curves.
  • Direct access to other instrumentation features including iSWAP speed and acceleration

The last two are somewhat moot because you can send firmware commands to do these through Venus, so the only thing you will absolutely never be able to do in Venus is run it on Linux/ MacOS.

For now, probably the main advantage is that STAR is PLR compatible and Venus isn’t, but like I said, hopefully that will change soon.

5

Hi Stefan,

thanks for the reply. After some considerations, we’ve decided that we’ll try to use Venus backend first. Our plate reader already has a venus plugin, it would be a pain to re-implement it. I’m happy to help with venus-to-plr deck conversion. If you’re interested, we can coordinate.

Sasha

1 Like
6

Cool! Many others choose the same. Thanks for the offer, and likewise I am always happy to help if you have any questions