azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing |,, | Logs:
Famine- has joined #scopehal
Famine has quit [Ping timeout: 260 seconds]
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #scopehal
<pepijndevos> azonenberg, Degi lemme know if I need to do any testing on my Rigol today.
Famine- has quit [Ping timeout: 260 seconds]
<pepijndevos> I see the PR has been merged. Should I see any changes if I've not been making any changes to coupling and attenuation?
juli964 has joined #scopehal
Famine has joined #scopehal
juli964 has quit [Quit: Nettalk6 -]
<azonenberg> pepijndevos: you should see significant performance increases
<azonenberg> since it won't be polling the scope for attenuation every frame
<azonenberg> let me update scopehal-apps with the new version of scopehal
<_whitenotifier-b> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-b> [scopehal-apps] azonenberg 5e9203b - Updated scopehal version
<azonenberg> And done. (Make sure when you pull you get submodules too)
<azonenberg> So i think i'm gonna go back to PCB work on MAXWELL tonight
<azonenberg> Have to finish the power plane layout
deltab has quit [Ping timeout: 264 seconds]
deltab has joined #scopehal
<pepijndevos> okay lemme try
<pepijndevos> I hate submodules... I always forget how to update them
<azonenberg> pepijndevos: just set "git config --global submodule.recurse true"
<azonenberg> and a pull will automatically grab everything\
<azonenberg> i have no idea why this is not the default
<pepijndevos> hey it's printing warnings about time
<azonenberg> ?
<pepijndevos> Warning: Time 4.225157
<azonenberg> no idea what that is, never seen it before. Maybe degi left some debug logging code in?
<azonenberg> The important question is, does it still work? and is it faster?
<pepijndevos> It also plain refuses to start. It worked the first time, but then I still had it set to 40M sample depth
<pepijndevos> so I set it to 10K and now it's just not responding
<pepijndevos> It appears to have sent at least on trigger command and the just hangs
<azonenberg> Clearly still some bugs :p
<azonenberg> I really need to just buy/borrow some rigol gear for development
<azonenberg> And set up some kind of CI cluster or something
<pepijndevos> ... as I run it in gdb it acually launches
<azonenberg> i really would love CI testing but the problem is it requires hardware
<azonenberg> That sounds like a race condition around some mutexing
<azonenberg> At least thats what it was every time i had it in the past
<azonenberg> Try running outside gdb, waiting for it to hang, then attach gdb and look at traces
<azonenberg> (run gdb like normal but don't do "run", launch the program as normal in a separate shell, then "attach 12345" in gdb where 12345 is the glscopeclient PID)
<_whitenotifier-b> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-b> [starshipraider] azonenberg ee30268 - Finished power plane layout on in3. Still have to finish in4 and do some via tweaks etc.
<pepijndevos> I'll post bt in "rigol is f'd" issue
<azonenberg> The big problem is that a proper CI cluster with even one model from each *family* we want to support
<azonenberg> would be well over $100K of hardware
<azonenberg> that's sitting around doing nothing but running nightly builds
<_whitenotifier-b> [scopehal-apps] pepijndevos commented on issue #146: glscopeclient hangs on Rigol MSO5000 -
<azonenberg> Hmmmm
<azonenberg> This doesn't make a ton of sense
<azonenberg> there's no deadlocking
<azonenberg> the trace you posted appears to be a legitimate block waiting on read data
<azonenberg> the question is why is that ReadRawData() not returning?
<azonenberg> Can you post your exact scope model and firmware rev in the thread?
<azonenberg> and maybe try and get wireshark captures of the hang as it happens?
<azonenberg> i'm interested in exact numbers of bytes sent in response to the query commands
<azonenberg> the +1 on RigolOscilloscope.cpp:682 smells like it might be part of the bug
<azonenberg> i think it's hanging waiting for an extra byte that isnt coming
<azonenberg> The question is why it's not doing this for degi
<pepijndevos> hmmmm okay
alexhw_ has quit [Quit: - Chat comfortably. Anywhere.]
alexhw has joined #scopehal
_whitelogger has joined #scopehal
<pepijndevos> Going to get the shark involved now...
<pepijndevos> wtf, why is my scope so broken...
<_whitenotifier-b> [scopehal-apps] pepijndevos commented on issue #146: glscopeclient hangs on Rigol MSO5000 -
<azonenberg> pepijndevos: looks like a firmware bug then
<azonenberg> at which point scopehal needs to figure out some kind of workaround to avoid crashing
<azonenberg> or hanging
<pepijndevos> a timeout would be a good start
<azonenberg> Yeah
<_whitenotifier-b> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-b> [starshipraider] azonenberg 0ae4de5 - Finished initial power plane layout
<azonenberg> That's in us
<azonenberg> so it should time out after 2 sec
<miek> i notice that the first time it runs through OK, TRIG:STAT = TD and on the failing one it's STOP. i see there's some commentary about that in the driver, but maybe the logic there is wrong? or at least wrong for mso5k? (that trigger logic comes from the original 1054z stuff)
<azonenberg> hmm
<azonenberg> i wonder if it's trying to read before the scope triggers
<azonenberg> and not correctly handling that
<miek> also, i guess the original 1054z dev you did would've had quite a bit of latency, so might not have hit that
<pepijndevos> I'm currently fascinated why it doesn't timeout
<miek> i had that problem with the agilent stuff: all the initial dev was done remotely while i was travelling, then i came home and everything broke when the latency went away :p
<pepijndevos> I wish I had a working network in my house so I could work form a comfy desk with my scope in the lab
<azonenberg> miek: yea
<azonenberg> i did initial dev on whitequark's rigol in moscow
<azonenberg> from seattle
<azonenberg> it was suuuuper laggy
<azonenberg> by that point i had already sold my ds1102d with a busted power supply to somebody who thought she could fix it
<pepijndevos> the recv call inside recvLooped is not timing out at all
<pepijndevos> how do I get a debug build with line info? Probably osme simple option to make or cmake
<azonenberg> cmake .. -DCMAKE_BUILD_TYPE=DEBUG
<azonenberg> should configure the build for debug
<azonenberg> that said, even the release build should, iirc, be configured with symbols
<azonenberg> it just is optimized
<azonenberg> DEBUG is -O0
<pepijndevos> doh... SetRxTimeout is not working and not checked for errors
<azonenberg> pepijndevos: Yes, that is a bug
<azonenberg> But it shouldn't be stopping the RX timeout from working
<azonenberg> that would break the TX?
<pepijndevos> right
<pepijndevos> on windows
<azonenberg> Let me patch that one right away
<_whitenotifier-b> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-b> [scopehal] azonenberg 90a9a0d - Updated xptools with bugfix for broken Windows SetTxTimeout()
<pepijndevos> Numerical argument out of domain??
<pepijndevos> basically the delay is too big
<pepijndevos> I fixed the timeout, but not really haha
<pepijndevos> somehow the socket ends up with timeout: 53 s 1469659264 us timeout
<pepijndevos> which uh is a lot
<pepijndevos> wtf this socket has no business at all randomyl changing its timeout
<pepijndevos> i "fixed" it by just resetting the socketopt in recvlooped
<azonenberg> look for any other code messing with the timeout?
<pepijndevos> yea... not finding much
<pepijndevos> at least I fixed my wrong usage of getsokopt
<pepijndevos> now it just returns0
<pepijndevos> hurray!
<pepijndevos> pr on the way..
<pepijndevos> doesn;t fix the underlying problem, but fixes the hang
<pepijndevos> ooof now I have to figure out how to commit this submodule mess
<_whitenotifier-b> [scopehal] pepijndevos opened pull request #182: set rx/tx timeout after connect, to avoid it being reset -
<_whitenotifier-b> [scopehal] pepijndevos edited pull request #182: set rx/tx timeout after connect, to avoid it being reset -
<pepijndevos> I'll also get a new trace from wireshark, maybe something can be found from the trigger condition or other errors
<_whitenotifier-b> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-b> [starshipraider] azonenberg b9892bb - Length matching of pod 0-9 inputs. 10/11 still have to be done, some ERC errors in meanders.
<_whitenotifier-b> [scopehal-apps] pepijndevos commented on issue #146: glscopeclient hangs on Rigol MSO5000 -
<pepijndevos> Does this look normal to someone knowing the Rigol commands?
<pepijndevos> It looks like it's just doing a normal TD, setting all the parameters and then just... not getting any data.
<pepijndevos> I sent Rigol a message, but I don;t have high hopes
<azonenberg> pepijndevos: we may just have to rewrite the driver to be tolerant of the device occasionally not working at all :p[
<azonenberg> :p
<azonenberg> Error_404: had some issues along those lines with his siglent iirc
<Degi> Oops sorry about the time warning, that's how many seconds it takes to do something related to getting samples.
<Degi> What is your scope? MSO5 or DS?
<Degi> Also um I wont recommend 40 M Samples. I think for the DS its by default 250 k hardcoded and for the MSO it reads it from the scope. I wont recommend anything above 100 k tbh, maybe 1 M is fine
<Degi> The speedup is limited, I think 250 k took like 80 ms per trace and 1 k took 60 ms
m4ssi has joined #scopehal
m4ssi has quit [Remote host closed the connection]