Has anyone played around with this gem of an open source Python interface to Quant Studio.
This guy definitely went into beast mode for this repo.
2 Likes
That’s awesome. Have you used it on a 7 yet?
I think they changed a bit from 5 to 7 in terms of access.
1 Like
I’m the author of that package. I was just pointed to this forum by a colleague while we’ve been working on setting up an Echo, but happened to find this thread as well.
I’m happy to answer any questions about the package. In terms of compatibility, the main branch only supports a 96-well QS5 right now, but I have a branch that has also been tested, at least for EDS file compatibility, with a 384-well Viia7 and QS6Pro, thanks to some assistance. I only have access direct access to some QS5s. (I did actually talk to someone recently who has a broken QS7Flex, and so we might be able to play around with that and see about support.)
For access and automation, I’m not so sure about compatibility. My expectations are:
- The QS3, QS5, QS6/7Flex probably all work. As noted in the documentation, more recent versions of the QS3/5 and probably Flex firmware don’t have hardcoded access passwords, but instead let the user set the access password in the touchscreen interface! Unfortunately, they also use SSLv3 for connections, which is particularly annoying. These were apparently changes to comply with California law, interestingly.
- The QS6Pro, and likely QS7Pro, appear to use a largely similar interface, and likely largely similar implementation. I don’t know whether they have a way to set the password in the interface, or whether they have the same hard-coded passwords. If they only have hardcoded passwords, I suspect that the access passwords for a device can be obtained rather trivially from the device, as the interface is likely similar enough to the QS3/5 to make the same methods viable. Note that passwords on these devices are in no way secure, and generally, the devices are in no way secure. We have our machines connected directly to laptops, and not connected to our network.
I’m happy to answer any questions, and if people have access to other devices, would be happy to collaborate on getting them working. I’d also note that for devices that have hardcoded access passwords, I don’t provide those passwords in the repository, but would be happy to discuss access privately.
I’d also point out that one of the reasons I’ve developed such an extensive package is that our use of qPCR machines has nothing to do with qPCR (I’ve never actually done qPCR), and so my requirements for the working with the machines are very different. As such, qslib has limited support for qPCR, especially in the main branch; I’ll be pushing some changes to main shortly that provide some support. If you do use it for qPCR, I’d appreciate any assistance or comments you might be able to provide about how that data is parsed and formatted.
4 Likes
Can you elaborate some more on the EDS compatibility?
Being able to custom generate EDT’s and extract info from EDS files covers a significant part of the automation needs.
Extracting information from EDS files isn’t that hard. They’re essentially zip archives. EDS 1.x machines (Viia7, QS3/5, I expect QS6/7Flex) use a combination of text and XML files. EDS 2.x machines (QS6/7Pro) use a combination of text and json files, of simpler format.
qslib’s 384well branch has the compatibility improvements, and I should merge it into main, though there are some potential problems with implementing automated tests. Basically:
- EDS 1.x files should largely be supported for reading/writing/generating. Analysis and amplification data may not be in an ideal format or may have bugs; I’d welcome suggestions there. Generated protocols should work, though there might be bugs to work out. However, there isn’t support for configuring analysis options; if that’s something that needs to be pre-added, support would need to be implemented (we’re using raw fluorescence data).
- EDS 2.x files are supported for reading, but not generating at the moment. I don’t know that much about analysis, so the analysis results are currently just provided as a raw dict of the loaded json file. The temperature protocol is currently loaded via a bit of a hack (qslib supports temperature protocols with features of the machine that can’t be represented in the EDS format, and so can read/write the actual SCPI interface protocol from the log, rather than the EDS file’s protocol).
- That hack does mean that qslib doesn’t understand the json temperature protocol format at all yet. It’s actually easier than the xml format, it just hasn’t been done yet.
- EDT files are pretty much just EDS files with a different extension.
Implementing the missing EDS/EDT features would be relatively straightforward; it’s just a matter of the time involved, and having files from different machines to use as references.
If you can provide sample EDS/EDT files from an EDS 2.0 machine, with and without data, those would actually be quite helpful, especially if they are files that could be included in the repository for testing. I don’t currently have any EDS 2.0 files that I’m able to release. And of course, if you are interested in implementing the features, I’d be happy to discuss them and include them.
2 Likes
@const thanks for joining out little online community! So cool you found us.
1 Like
Also @const please don’t attempt my LIMS toy problem lol, I feel you’d crush it too hard 
1 Like
They’re essentially zip archives.
Wow no joke, thank you!
Edit: I’ll message you separately, cheers!