nelgau has quit [Read error: Connection reset by peer]
nelgau_ has joined #scopehal
<azonenberg>
OK so I'm starting to work on the "don't blow up users' instruments if they load a session that doesn't match their hardware setup" refactoring
<azonenberg>
Which i consider a prereq to things like serializing power supply config
<azonenberg>
basically, instead of loading a session online instantly applying all of your config without asking, it's going to parse the file, connect to the instruments, and diff the configs
<azonenberg>
and if it sees things like a power supply currently putting out 3.3V that your session says should be putting out 12V it'll pop up a confirmation dialog asking you if you really wanted to do that
<azonenberg>
with options to proceed or cancel the load for now, and eventually an option to disconnect and load offline
<azonenberg>
Thinking about the data model for this: initially i'm thinking of adding a new Instrument method PreLoadConfiguration that does a subset of the operations from LoadConfiguration but without actually applying any of the loaded config
<azonenberg>
but also returns a list of potential problems it's found
<azonenberg>
So the question is how to structure that list. My initial thought is a map from channels to a list of warning messages
<azonenberg>
(which are free-form text for now, we might look into better localization architectures later)
<azonenberg>
But this then raises the question, is there any *instrument wide* configuration (vs per-channel configuration) that might potentially cause hardware damage to instrument or DUT if changed at the wrong time?+
<d1b2>
<azonenberg> @louis8374 @246tnt @aleksorsist @whitequark @mubes @hansemro any thoughts?
<azonenberg>
(and lain and miek on the IRC side)?
nelgau_ has quit [Ping timeout: 255 seconds]
<d1b2>
<aleksorsist> 50 ohm mode for scopes comes to mind for damaging the instrument
<azonenberg>
That's normally a per channel config
<azonenberg>
I'
<azonenberg>
I'm thinking about instrument wide
<d1b2>
<aleksorsist> Oh my bad
<azonenberg>
But yes that is absolutely going to be on the list of things we're looking for. in particular going from 1M -> 50 can potentially blow the frontend if the input signal is too strong
<azonenberg>
the other way around is normally safe
<azonenberg>
anything a 50 ohm input will survive shouldn't hurt a 1M ohm
<azonenberg>
Basically the idea is, loading a scopesession with a config identical to your current config should not show pointless warnings
<d1b2>
<aleksorsist> Reference clock input versus output?
<azonenberg>
and any config that is definitely safe if the current config is safe should not warn
<azonenberg>
any config you can't prove is safe based on the current config should warn
<d1b2>
<aleksorsist> Idk if two instruments outputting refclock would contend with each other to the point of damage
<azonenberg>
so say, lowering current limit on a PSU won't warn, increasing will
<azonenberg>
Yes, that's something to think about. So far all of the stuff i've got handy has unidirectional ref ports
<azonenberg>
i.e. dedicated input and/or output ports
<azonenberg>
so no risk of contention. all you can do is set an internal mux that says use the on-board OCXO or the external input, but that physical connector is always an input
<Degi>
Maybe warning on lowering might be nice too?
<Degi>
Or changing from overcurrent protection to constant current mode, at least
<Degi>
Otherwise lowering output voltage might result in stuff like FETs overheating from too little gate drive voltage
<azonenberg>
Possibly. But what I'm trying to do is avoiding warning fatigue where users will get a popup every time they load a session and learn to ignore it
<azonenberg>
so i dont want to focus too much on edge cases or things that might slowly overhead... brownout based damage is not going to be instant
<azonenberg>
overheat*
<azonenberg>
What i want to avoid is opening a scopesession and blowing the instrument or dut before you have time to react
<Degi>
Maybe something like warning levels, like with compilers or KiCAD's DRC
<juh>
I can imagine users wanting it three ways: only seeing changes that would cause damage, seeing the entire diff, or seeing the whole configuration raw
<juh>
the nice thing is that those are derived from each other, so maybe there could be a user setting for "how verbose do you want your config push warning"?
<azonenberg>
The whole config is ascii plaintext (yaml)
<azonenberg>
if you want to see all of it, just open the file in a text editor
<juh>
oh that's cool
<azonenberg>
entire diff might be something we can add later on. Near term my focus is going to be only potentially harmful changes
<azonenberg>
Most of the configs in this repo look a bit different as they came from older software revisions (but are upward compatible and can be loaded in current ngscopeclient)
<azonenberg>
This is one that's relatively recent
<d1b2>
<whitequark> @azonenberg there are instruments with like, outputs and relays