Sharing instro, a related open-source instrument control library

[hoehner]

Hi InstrumentKit maintainers and users.

Posting this here because the audiences overlap and I'd rather you hear about it from us than stumble on it.

We (Nominal) open-sourced instro, a Python library for instrument control. Like InstrumentKit it provides Python classes over SCPI instruments. The main difference is that instro is organized around typed category contracts (one InstroPSU API for every supply, one InstroDMM API for every meter) with thin per-model drivers underneath, and it bundles the data-collection layer - a background polling daemon, publishers that stream timestamped readings to JSONL or custom sinks, and simulators for CI.

It also covers non-SCPI hardware (Modbus, EtherNet/IP, I2C, CAN, NI-DAQmx, LabJack, MCC).

If you have an instrument that InstrumentKit supports and instro doesn't, drivers are about 100 lines and we have a contrib package with a lower verification bar. Conversely, if there's anything in our driver set that would help InstrumentKit, it's Apache-2.0.

GitHub: https://github.com/nominal-io/instro
Docs: https://instro.nominal.io
Community: https://community.instro.nominal.io
Discord: https://discord.gg/nN4RzhQkr

[scasagrande]

A lot of this looks very similar to how we've written IK. Any comments there?

[hoehner]

Yeah I think there are definitely parallels in implementation here - the general usefulness of "abstract instruments" is too strong to pass up (especially as someone that has written a lot of boilerplate over the years).

I think those similarities are largely coincidental and digging in a bit, instro tries to keep the boundary between abstract instrument and vendor driver pretty decoupled where IK is doing more explicit inheritance. Truth be told, I'm jealous when I look in IK at a device driver for a given instrument. Everything is largely in one place (where in instro it is split between the parent Instro* instrument class and the composed driver which inherits from the BaseDriver class).

That approach makes debugging behavior super quick - not having to scan through multiple files as often. On the other hand I think we build instro with the intention that SCPI/VISA instruments would very likely not be the end of the road. Most of this was built off of customer needs/requests which mostly informed the architecture/protocols/abstractions/layers/etc.

Very much open to thoughts on our approach vs the IK approach and merits of the two. Thanks for taking an interest in the first place!

[scasagrande]

Oh, I was referring to a lot of overlap in the actual grammar used. It looked eerily similar. To the point where I thought some of it was copied from IK. Given that IK was started in 2012, the nature of LLMs, and the fact that you seem to have embraced the technology, I am not surprised.

Let's cut through it and be honest here, you're here to try to advertise your Apache licensed software and business in an AGPLv3 space. I don't find this to be particularly appropriate. I do hope that you reflect on this.