<_whitenotifier-5>
[scopehal] azonenberg a48ed14 - Filter: Added GetMinMaxVoltage to make a single pass over a waveform instead of separate min and max steps
<Darius>
azonenberg: BTW re: #694 I can run stuff you want from here to save some round trip time
<azonenberg>
oh oops missed that you're the same as the github user
<azonenberg>
throws me off when people dont use the same nick in both places lol
<Darius>
hah, my IRC nickname predates my github by, uh.. *mumble* years
<azonenberg>
Ok so
<Darius>
huh weird this goes through teh logging system
<azonenberg>
when the connection fails, the tek driver aborts
<azonenberg>
ok so what's happening is TektronixOscilloscope::ResynchronizeSCPI gives up on talking to the scope because the socket is down
<azonenberg>
then it calls exit(1)
<azonenberg>
and some global destructor for PipelineCacheManager is choking
<Darius>
seems a bit impolite for it to call exit
<azonenberg>
Yeah, we need to work on improving error handling in some cases
<Darius>
fair enough
<azonenberg>
Ultimately the long term vision is for, when a scope loses connectivity to the driver
<azonenberg>
the driver to seamlessly transform itself into a MockOscilloscope object and start working in offline mode
<Darius>
I hacked up the tek driver a bit in an attempt to talk to my TDS2024 but I get a segfault, I haven't looked further yet - getting close to beer o'clock
<azonenberg>
the challenge is how to notify everyone who's got a handle to the old scope object to start using the new one again
<azonenberg>
its nontrivial and we havent yet spent the time to figure out the right way to do it
<Darius>
yeah that sounds hard
<Darius>
unless you have some proxy object but then you have extra handling
<azonenberg>
(also, there's some other refactoring needed between now and then to make it slightly less painful)
<azonenberg>
Yeah
<azonenberg>
But ideally making the driver at least switch to a "nonresponsive but not crashing" state
<azonenberg>
i.e. all methods return an error value or most recent data
<azonenberg>
woudl be nice
<azonenberg>
So fundamentally what we have here is a) bug where calling exit at least in this case leads to a crash, this is low priority as we're already terminating
<azonenberg>
and b) the tek driver being less graceful with error handling than it should be
<Darius>
BTW the tek driver has a lot of stuff like: if (reply == "EDG") { ..} which seems a bit fragile, I had to change them to if (reply.find("EDG") == 0) for teh TDS2024
<azonenberg>
Are you not using short commands?
<Darius>
sounds reasonable
<azonenberg>
for replies
<Darius>
I dunno this thing is ancient
<azonenberg>
yeah idk how well it'll interop with the modern tek driver command set wise, it was written for the mso5/6
<Darius>
I don't see a command to turn them on
<Darius>
yeah
<azonenberg>
you may have to add a lot of quirks
<Darius>
yeah
<azonenberg>
(it's always a tricky question of whether to write a new driver or add quirks to an existing one if the scopes are that different)
<Darius>
yeah indeed
<azonenberg>
also in general the mso5/6 scpi stack is extremely fragile
<azonenberg>
e.g. if you query the voltage range of a channel thats not enabled, iirc it'll hang and drop the next few commands giving no indication of an error unless you query some special error log register
<Darius>
I did notice this poor scope is basically unresponsive if scopehal is talking to it, but at least it has the excuse of being old
<azonenberg>
There may be room for some optimization as far as rate limiting polls or something
<azonenberg>
or caching something
<Darius>
yeah error handling in SCPI seems pretty subpar
<azonenberg>
yes but there's a huge range in terms of how well its done
<Darius>
yeah I bet
<azonenberg>
lecroy is my favorite scpi implementation by a long shot
<azonenberg>
you can queue up arbitrarily many commands and it'll execute them in sequence
<azonenberg>
it logs errors to a buffer on the scope you can easily view in the gui (probably also remotely dumpable but i havent tried)
<azonenberg>
when it fails, it fails instantly and obviously
<azonenberg>
its generally fast
<Darius>
I guess all that extra money goes somewhere :)
<azonenberg>
i very rarely crash the firmware
<azonenberg>
yeah but like, tek is in the same price/specs class as lecroy
<azonenberg>
and their scpi stack is the worst i've ever used lol
<azonenberg>
like, siglent's is less fragile :p
<azonenberg>
siglent is slow but at least it isnt as crashy
<Darius>
yeah that is pretty annoying then
<azonenberg>
again i'm speaking specifically about the mso5/6
<azonenberg>
i cant comment on other tek products
<Darius>
well I've definitely crashed this scope before..
<azonenberg>
i mean i've crashed my lecroys too
<azonenberg>
its just extremely infrequent by comparison to a lot of other stuff
<_whitenotifier-5>
[scopehal-apps] azonenberg 58af58e - TriggerPropertiesDialog: don't attempt to dereference oldTrig if it's null after we've just checked for null. Fixes #693.