-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rigol: Floating point exception #803
Comments
Looks like what's happening here is that the scope is doing something the driver doesn't like during acquisition (header_blocksize = 0 in RigolOscilloscope.cpp:848). The driver fails in a rather unusual way (creates a waveform with zero points, rather than the expected way of sending "no data" which is to set the waveform pointer to null) which then causes a bunch of the GUI logic to choke. Can you re-run with |
Hmm, please find attached a log generated by: ./src/ngscopeclient/ngscopeclient --debug --trace SCPISocketTransport > log 2>&1 although it ends in: which makes me wonder whether it's complete. I restarted ngscopeclient and did it again, but it failed much faster, and this time I left out the redirects, so here is where it ended on my terminal: Connecting to SCPI device at ronnie:5555 which makes me wonder if it left the scope in an odd state. |
I get the feeling there's something timing going on here;
|
Oh, I think this is as simple that it hasn't actually triggered yet - there's no data; and depending on the timing it might be in the middle of the capture. |
Manually triggering on the scope panel and then throwing ngscopeclient at it and it's working. |
Very interesting, because it's supposed to be polling the trigger status and not trying to download data until it's actually triggered. As a guess, this is a bug where it can't tell the difference between "trigger stopped because the scope just booted and has no data" and "trigger stopped because we armed the trigger and then it triggered". |
Moving to scopehal as this is a driver bug, zero point waveforms aren't well defined so it's not surprising the GUI chokes if given one. |
So it looks like there's logic in the driver (https://github.com/glscopeclient/scopehal/blob/master/scopehal/RigolOscilloscope.cpp#L705) to work around this problem. Can you poke around here a bit and figure out if the check isn't triggering or something else is going on? |
I think the problem is that (sometimes, timing) that the :TRIG:STAT? sent immediately after the *WAI hasn't yet got into the wait state; [SCPISocketTransport::SendCommand] [ronnie] Sending :SING Typed on the SCPI console: so when I got around to typing a TRIG:STAT? by hand in the SCPI console it had got to WAIT (I'd turned off the trigger input connected to the probes so it was just sitting waiting; perhaps it's blatantly ignoring your *WAI ? |
Interesting, might be a firmware race condition. How about adding a small time delay after the *WAI before sending TRIG:STAT? Does that make it work reliably? It'll hurt performance but we have hacks like this in the Siglent driver for similar reasons. (Even LeCroy has one or two annoying races but they only come into play for multi-scope setups) |
I've got back to prodding this a bit. a) I think actually in single-shot mode, as long as you had a trigger level set that actually did trigger it might have worked. c) I had a poke at the firmware, I'm not convinced the *WAI really does anything, but I may be wrong. I'm currently running with the following patches
|
Also, as a general rule we don't use the "normal" trigger mode in scopehal drivers because of the potential for race conditions (getting channel 1 from one trigger event and channel 2 from another). We normally run single trigger all the time, and "normal" trigger in ngscopeclient is simply a flag that tells the driver to automatically re-arm the trigger once AcquireData() completes. |
Yeh #817 is probably similar; well on head it doesn't get the div/0 any more, but it's not happy - still lots of blank captures in the "normal" mode. |
@penguin42 We fixed a bunch more bugs (2e74c6e, 0e26e31, and a few others) that might also have been causing your issue. Working any better w/ latest? |
at 02b300df83bcd2ed9ed34c573dbedf4e9511121f main and 9564b05 it's better but still giving me some captures where nothing is showing in ch.1: (Now with matching capture, still doing it) |
Observation: This pair of channels is a USB pair; sometimes it captures a quite section, and sometimes it captures a burst of activity. Most (all?) of the cases where I'm missing ch.1 is when there's a burst of activity rather than the background tick |
Connecting to a DS1102Z-E Rigol via LAN, clicked on the single shot button and got:
Warning: Ran out of data after 0 points
Warning: Attempted to bind an empty buffer
Floating point exception (core dumped)
#0 0x00000000008cc374 in WaveformArea::RasterizeAnalogOrDigitalWaveform(std::shared_ptr, vk::raii::CommandBuffer&, bool)
(this=0x33729f0, channel=std::shared_ptr (use count 3, weak count 0) = {...}, cmdbuf=..., clearPersistence=false)
at /discs/more/git/scopehal-apps/src/ngscopeclient/WaveformArea.cpp:1603
#0 0x00000000008cc374 in WaveformArea::RasterizeAnalogOrDigitalWaveform (this=0x33729f0, channel=..., cmdbuf=..., clearPersistence=false)
at /discs/more/git/scopehal-apps/src/ngscopeclient/WaveformArea.cpp:1603
1603 int64_t offset_samples = (offset - data->m_triggerPhase) / data->m_timescale;
(gdb) p *data
$2 = {_vptr.WaveformBase = 0x9af840 <vtable for UniformWaveform+16>, m_timescale = 0, m_startTimestamp = 16951
70282,
m_startFemtoseconds = 23995876312255, m_triggerPhase = 0, m_flags = 0 '\000', m_revision = 0}
ngscopeclient/scopehal-apps#1 0x00000000008cd42f in WaveformArea::RenderWaveformTextures(vk::raii::CommandBuffer&, std::vector<std::shared_ptr, std::allocator<std::shared_ptr > >&, bool)
(this=0x33729f0, cmdbuf=..., chans=std::vector of length 1, capacity 1 = {...}, clearPersistence=clearPersistence@entry=false)
at /discs/more/git/scopehal-apps/src/ngscopeclient/WaveformArea.cpp:1545
ngscopeclient/scopehal-apps#2 0x00000000008db504 in WaveformGroup::RenderWaveformTextures(vk::raii::CommandBuffer&, std::vector<std::shared_ptr, std::allocator<std::shared_ptr > >&, bool)
(this=, cmdbuf=..., channels=std::vector of length 1, capacity 1 = {...}, clearPersistence=clearPersistence@entry=false)
at /discs/more/git/scopehal-apps/src/ngscopeclient/WaveformGroup.cpp:164
ngscopeclient/scopehal-apps#3 0x0000000000801436 in MainWindow::RenderWaveformTextures(vk::raii::CommandBuffer&, std::vector<std::shared_ptr, std::allocator<std::shared_ptr > >&) (this=, cmdbuf=, channels=)
at /discs/more/git/scopehal-apps/src/ngscopeclient/MainWindow.cpp:434
ngscopeclient/scopehal-apps#4 0x00000000008831cc in Session::RenderWaveformTextures(vk::raii::CommandBuffer&, std::vector<std::shared_ptr, std::allocator<std::shared_ptr > >&) (this=, cmdbuf=, channels=)
at /discs/more/git/scopehal-apps/src/ngscopeclient/Session.cpp:2166
ngscopeclient/scopehal-apps#5 0x00000000008e7edc in RenderAllWaveforms(vk::raii::CommandBuffer&, Session*, std::shared_ptr)
(cmdbuf=..., session=0x3714770, queue=std::shared_ptr (use count 5, weak count 0) = {...})
at /discs/more/git/scopehal-apps/src/ngscopeclient/WaveformThread.cpp:167
ngscopeclient/scopehal-apps#6 0x00000000008e8a34 in WaveformThread(Session*, std::atomic) (session=0x3714770, shuttingDown=0x37148a0)
at /discs/more/git/scopehal-apps/src/ngscopeclient/WaveformThread.cpp:144
ngscopeclient/scopehal-apps#7 0x00007fb1950e31f3 in std::execute_native_thread_routine(void) (__p=0x3d778e0) at ../../../../../libstdc++-v3/src/c++11/thread.cc:104
ngscopeclient/scopehal-apps#8 0x00007fb194dcb897 in start_thread (arg=) at pthread_create.c:444
ngscopeclient/scopehal-apps#9 0x00007fb194e5261c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
The text was updated successfully, but these errors were encountered: