In our discussions on the new PLR version 1 it became evident that people might have very different ideas of what the term “device driver” actually means in the context of lab automation.
Interestingly, most “standards” in the field seem to avoid the term (maybe because of its interpretation baggage). I even found entire papers discussing driver modelling without defining what a driver actually is
As we finalise the architecture of PLR v1, we need to make a concrete decision about how to use this term - and we want that decision to reflect how the community actually thinks about it, not just our own assumptions.
So I would like to ask you:
Intuitively, what comes to mind when you hear the term ‘device driver’ in a lab automation context?
(I’m especially curious about how people think about the scope and boundaries of a driver, but I’ll share my own view after a few responses come in so I don’t skew the discussion early)
My definition is this: A code package that translates commands from a control application to an external target.
Code package - any packaging is fine, but the idea is that it is complete and doesn’t rely on other components. It’s essentially useless without the control application and target device, but either one could be spoofed without affecting the driver.
Translates commands - it has to have a known structure that the control application expects (interface in .NET language), and routes those methods/commands to the appropriate device commands.
Control Application - scheduler or any other application / harness.
External target - doesn’t have to be a device, in my mind you could have a driver for another software application or API. But I think it does have to be targeted: a .NET event wouldn’t be a driver.
That’s my intuitive definition, based on using lots of schedulers over the years and writing lots of control code for my own applications and devices. Features like self-describing, observable, etc are nice to have, but not part of the definition.
When I hear “device driver” I think of the piece of code that was missing, the thing you had to install or write to make a new device work. Before it, the device is unrecognized. After it, everything the device can do becomes available.
For PLR specifically, I think we may need a narrower definition to distinguish it from the backend/capability frontend concept we already have.
It is likely most users will be searching or asking chat for the “driver” for their device. A common user problem in lab automation is owning hardware but not a driver to control it.
Most hardware sellers hold your device hostage by not providing the driver for free.
It should be obvious to the user that pylabrobot exposes full control over their device for free. Our current language of “backend” makes this less obvious to novel PLR users. Our goal should be to make the language behind driver / backend obviously point toward the fact we provide permissionless instrument control for free.
