Hi all,
has anyone ever tried “hacking” their way around VWorks? How can I use the Bravo in a headless way?
Has anyone been in touch with Agilent support on this?
I’d like to evaluate if I can build a Python interface for it. Would this be of interest to the larger community and also pylabrobot?
Yeah we’d be very enthusiastic about this. Is the Javascript interface not flexible enough? You could probably implement an API that is responsive to Python using JS scripting. What additional behavior would you get from firmware control?
Could you provide some more background on the current interface?
I think @Stefan is referring to this “JS interface”: https://www.agilent.com/Library/usermanuals/Public/G5415-90059_R_00_JSWrapper_S_EN.pdf
You can find the documentation of the VWorks COM interface here: https://www.agilent.com/cs/library/usermanuals/public/D0008025_VWorks_API_Reference_Agilent.pdf
The COM interface is very high-level as in “LoadProtocolMethod” and “RunProtocolMethod”. My top two problems with that would be:
I mean that would be a last resort. To build out a full control connector for this sort of construct would be high maintenance… just the potential version conflicts between the JSWrapper and the VWorks version / COM interface. It would be completely dependent on the software. By-passing that would reduce complexity and the systems involved.
It’s the same as using the Com interface of Venus and then sending it HSL protocols to execute. It works, but it’s just a hacky fix and not a clean solution. So I was wondering if anyone has tried this before and if Agilent has already handed out the documentation.
I agree that writing a vworks-independent version is better/required for a PLR backend. Not sure if they have documentation or whether this has been done before. Keep us posted!
Great idea for Bravo’s.
This would be great - I’d be really interested in it. There are a lot of ways that VWorks hamstrings you (protocols needing to end w/ tips off, the JS you’ve got to write for loops), being able to send discrete commands would make many operations a lot easier to implement.
task.skip(); in the JS for the tips off task lets you leave tips on at the end of protocols, but, yeah, discrete commands would be better/more flexible.
Sorry I forgot to reply to this thread before.
Yes the Bravo can only communicate with external software via VWorks API (for example you can use the API with powershell). The API lets you load or run protocols and subscribe to events, but you must write the protocols in VWorks.
There are many JS tricks you can use for creating protocols that perform multiple functions or have some features. For example you can pass the protocol an input file that enables//disables certain processes or task.skip()s some of the tasks, or sets the head to a certain head mode. The paradigm in VWorks is “everything is a parameter”, it’s just a matter of knowing a little JS and leveraging the embedded objects (task, plate, plateDB, runset, …).
Please let me know if you need specific help on some function/task/object.
The protocols are just XML files are they not? Could you create XML files on the fly and pass them to the VWorks API? This still has the constraint of only being able to do things that are VWorks commands to begin with, but would that negate the need for requiring the full VWorks application?
Sure they are, and in principle you could also create some xml code on the fly. That would be equivalent to preparing a bunch of small protocols beforehand and call them when needed passing the required parameters as csv or json.
Yes, they are.
One approach would be to assemble the XML with Python and then run it with the API. Other workaround I can imagine is creating one cleverly designed looping protocol using lots of task.skip() and Process spawn, where you would just pass a buch of parameters to it to do what you need and skip the rest.
However, I think what the OP is after is to get rid of some pecularities of VWorks and have more direct control. There is no command that I know of, that would allow you to use the gripper for example - the Bravo handles the gripper automatically depending on where it expects the plate to be in the next step.
Some of the .dll files installed with VWorks surely do allow direct control, but there is no documentation.
For example, drivers for PAA´s Overlord have direct control over Plateloc, Centrifuge etc. becuse the methods exist for them, but for the Bravo only thing they can do is run VWorks protocols and pass variables to them.
Yeah, agreed. Some enterprising people might be able to figure it out with the DLLs.
There’s some tantalizing stuff in the Bravo.dll:
When I try to use it though, I get an error like so:
The DLL is registered, I can see it in the registry. I’m compiling for x86.
This is really interesting! Can you view the decompiled code for the HomewoodClass / HomewoodDriver? Which tool are you using for inspecting the DLL? It would be interesting what the parameters are. I’m using Telerik JustDecompile (Download Trial File, link starts the download).
I’m absolutely out of my wheelhouse here, and I don’t know what you’ve already tried. But it sounds like a mismatch in CPU architecture. See here for some possible troubleshooting
I’m absolutely out of my wheelhouse here, and I don’t know what you’ve already tried. But it sounds like a mismatch in CPU architecture. See here for some possible troubleshooting
Yes, I’m compiling my test application for 32-bit (ie x86). The dll is from VWorks (in Program Files (x86)) and registered w/ regsvr32. I also tried earlier versions of .NET.
