<d1b2>
<vipqualitypost> So exciting to be here for it!
<d1b2>
<thewearygamer> So, general question.... are all device drivers intrinsically tied to SCPITransport? I've got a logic analyzer I'm trying to add that that speaks serial but not SCPI (generic SUMP protocol instead). I'm hitting an issue where the device factories require a constructor that takes in a SCPITransport. Should I try to shoehorn a different protocol into that or something else?
<d1b2>
<azonenberg> Sooo
<d1b2>
<azonenberg> tl;dr it is currently possible to create an arbitrary instrument that doesn't use SCPITransport with the API but the GUI and file format really assume that's what you're doing
<d1b2>
<azonenberg> but nothing actually enforecs that the on-the-wire protocol is SCPI except the SCPIInstrument constructor
<d1b2>
<azonenberg> which takes an optional boolean argument to disable the *IDN? command it sends on startup
<d1b2>
<azonenberg> Longer term (i.e. after v0.1) we are probably going to refactor the API and change the names to reflect the fact that while 99% of the time the data is SCPI, it doesn't have to be
<d1b2>
<azonenberg> @thewearygamer if you dig around there's a driver for, i think, a really old HP power supply that uses a non-scpi protocol over rs232
<d1b2>
<azonenberg> that might be a good reference for how to approach it