you do not! PLR has firmware interfaces integrated for all machines that we support. That means you don’t need to have any oem software at all to control the machine. It’s all just Python code. (-> it works on Mac/raspberry pi/etc.)
wanna add this to PLR?
we have nice universal frontends (APIs) for all these machines, e.g. Shaker for shakers. It’s very easy to add devices in PLR, essentially just one simple python file implementing some atomic commands (shake, stop shaking) and we take care of the rest. It’s also a good way to get more users
Please let us know if you need any help.
Happy to go with you through the process (if the endproduct is open-source [and I have time] I am always happy to help for free, if the endproduct is proprietary one can hire me as a consultant).
In the meantime, this might be a nice starting point:
Oh, yes, I have and 100% agree! I already looked at their integration manual as well as the newer one and had made a functional Python script to control them, thanks to ChatGPT. As of now, I am writing an HSL library to integrate it into VENUS, which I want to give a special shoutout to @theonetruenerd for creating a HSL documentation page as a reference (GitHub link, if anyone wants to join and contribute ).
When I meant by being new to this, I meant being new to PyLabRobot and GitHub; therefore, I don’t know how to integrate it to PLR, but I am discussing with @rickwierenga as we speak.
@Nat we just made galago available to the public. See post here.. Galago comes with a bioshake driver (tested on the ELM3000 model) and a full GUI to control it. See our post to get started, shouldn’t take more than a couple mins if you have python and docker installed on your computer. If you don’t want to use the GUI you can still use the driver as shown below:
#On a new python 3.9 env
pip install galago-tools
#Example Python script below
from tools.bioshake.driver import BioshakeDriver
bioshake = BioshakeDriver(port="COM1") # update based on your com port.
bioshake.home()
bioshake.shake_on_with_runtime(seconds=30, speed=1000,acceleration=80) #timed shake
bioshake.disconnect()
Please let me know how this goes or if you run into issues
I do not fully get this. In its core, I see SiLA2 as a grpc-schema plus discovery tools. On the surface, it allows drivers/servers/connectors (whatever you cal them) written in different languages to be discovered and controlled via a unified interface. Working in academia, I have so far created sila servers for 30 or so devices including some of your category3 (cough Biotek cough). All it takes is some way to control them from python and to use sila_python (on pip) or sila_unitelabs-CDK (was linked above and also easy to find) to generate a server/connector skeleton where you fill in your hardware control commands. I never touched any .proto file. So far, I have not come across a SiLa2 server you would have to pay for. Mine and most I have seen are open source ;-). Sadly, only few OEM provide one.
Are you talking about SiLA1? That got depreciated in 2015 and I have heard stories of some kind of hostile takeover by a company called info-team resulting in ridiculous costs for certification and servers.
Which in this case is quite opaque about how much one of these SiLA(2) “connectors” or drivers costs, asking to “Please Enquire” when it comes to pricing (not explaining whether we are talking about licensing or one-off fees), and says “Unknown” or “Proprietary” when it comes to their licensing … obviously, that is the opposite of open-source
I would love to learn more though about how you see SiLA(2) and more about your open-source drivers.
Could you please provide us with a link to them?
Do you have some step-by-step guides on how to create one?
I am particularly interested in this:
Are you saying you already have a Python script that can control a machine, and then you build it into a SiLA2 server (i.e. a gRPC-based server)?
Where does the information about what commands the machine accepts come from?
How are these commands sent to the machine?
Thank you for your insights!
A very apt topic in a thread about “In-House Drivers Integration”
That makes sense if thats what SiLA2 is, I can see that being a useful standard design pattern. But I also dont see that information publicly available anywhere, such as how to implement a server/ connector, the set of connectors available. It seems like there is something missing in the like public communication of the project. Compare this to PLR - the front page of the project clearly explains how to install, instantiate a connection to an instrument, and send commands for multiple instruments with like three lines of code each.
Yes (its in the linked tutorials). There are implementations for other programming languages but they should work similar.
You already categorized it nicely ;-). From python-API (UFactory), over more (Hettich Rotanta) to less (Thermo-Cytomat, kbiosystems) complicated serial interfaces and nice .dll (VWorks, ThermoMoverFramework) to ancient activeX (labcyte) and 32-bit, licenced .dll (Biotek) you rather reverse engineer its a colourful mix.
I think, PyLabRobots makes it easier to interface supported devices from python (I tried it a year ago with an OT2).
How the command is sent from server to machine is not SiLA`s concern. Its only about the server-client communication (user is client, device is server).
I have servers from my current lab here https://gitlab.com/OpenLabAutomation/device-integration, some older ones are hidden here: https://gitlab.com/opensourcelab/devices. Not mine: https://gitlab.com/sila-driver-group.
I agree about the sila2-website. I had not looked on it in year, but servers there are definitely not free. Seems like equicon has ramped up implementing them.
@Stefan_M ,This is very interesting and useful information. Based on this…
…am I correct in understanding that SiLA 2 does not provide device drivers directly?
The definition of a device driver is “In the context of an operating system, a device driver is a computer program that operates or controls a particular type of device that is attached to a computer.” (Wikipedia: Device Driver).
This means a device driver has to contain 2 pieces of information:
the information about what commands the device accepts (and in doing so, what features the machine is capable of)
how to send these commands to the machine
So if I understand correctly, SiLA 2 doesn’t actually provide the device driver layer at all - it relies on an existing driver or API and simply defines a way to expose that over a network in a standardized form.
So the script (written in Python or any other language) is effectively the actual driver, and the communication with the machine could already be established by using that driver directly.
This means the question of this thread - how to build drivers - isn’t answered by SiLA, but rather shifted to “must exist before SiLA”, if I understand you correctly?
What if your lab has limited or unreliable network access - why go through the extra step of wrapping the existing driver in a SiLA layer?
I guess that’s also why SiLA calls it a “Connector” rather than a driver - they’re really two different layers. Drivers can exist without SiLA, but SiLA cannot function without drivers.
Does this mean that SiLA(2) drivers are built on a wide array of APIs, each might require a completely different setup, might inject different dependencies, and almost certainly makes your entire automation system Windows-dependent - looking specifically at the “ancient activeX” you mentioned?
This sounds like a dependency minefield and enormous technical debt to maintain…
Does SiLA 2 itself offer any concept of workcell state modelling - such as maintaining a unified view of plates, inventories, and locations that must be inferred from prior actions rather than queried from devices?
Or how does the automator manage workcell state when using SiLA?
Yes. SiLA2 is a communication standard, a protocol. Not a driver selling company.
How would that be possible? There are devices actively built with API much older than SiLA. Its more that companies provide SiLA2-compatible drivers or devices(when for example the driver is running on an internal server) and it provides means to produce sila-compatible drivers.
I guess? All my sila-drivers contain a (sometimes 2 or 3) python file(s) that you might call the actual driver.
The terminology of “connector” was introduced by the main software developer of unitelabs. On their tutorial website is a detailed explaination why this this is correct considering the definition of driver, server and connector.
Yes.
Nooo! That would be hell! What if i told you that these “ancient activeX” .dll are 32 bit? Just like the backhand of LHC2 and even the new LHC3 software by biotek? Such drivers usually have 2 parts. The 32bit-windows part which communicates to the other part via some protocol.
Not really. Every software has dependencies and there are dependency managers… and what way around this is there if a OEM provides exactly one way to automate a device?
I have a database and update it when moving labware. I guess, others do the same.
I usually use a local network anyway. I guess every automation system starts by building common way to communicate to the wild variety of device-API. SiLA is one such way. Additionally it allows for software like the sila-browser, a GUI that automatically detects sila-servers and provides a unified graphical interface to control and query devices. This has proven quite useful.
Also, SiLA2 provides (or rather SiLA2 defines and its implementations like sila_python/sila-unitelabs provide) means to encrypt the communication and enable cloud connectivity.
Great conversation, I will add that I am a big fan of SiLA2 not only because they are a standard but also because they support a variety of programming languages. Between SiLA2 and OPCUA-LADS, there is a lot of momentum pushing forward these two standards.
Part of the aforementioned is due to SiLA2 gaining a lot of ground in the academic world. Some of the best funded and most advanced automated academic labs build their device integration backbone on SiLA2. These folks will eventually make their way into industry and into positions of leadership from their materials labs. Interesting times with lots of great papers, ideas and builds being shared right now.
).
).