<d1b2>
<Makerprobe> @azonenberg I tried to build the scope client again yesterday (ubuntu 22.04.1 LTS), and I think I got a bit further than last time. However, I'm still getting errors in step 4 (build scopehal and scopehal-apps). First one is: [ 74%] Building CXX object src/ngscopeclient/CMakeFiles/ngscopeclient.dir/__/imgui/imgui.cpp.o In file included from /usr/include/signal.h:328, from /usr/local/include/catch2/catch.hpp:8030,
<d1b2>
from /home/christoph/scopehal-apps/tests/Acceleration/main.cpp:40: /usr/local/include/catch2/catch.hpp:10818:58: error: call to non-‘constexpr’ function ‘long int sysconf(int)’ 10818 | static constexpr std::size_t sigStackSize = 32768 >= MINSIGSTKSZ ? 32768 : MINSIGSTKSZ; | ^~~~~~~~~~~
<d1b2>
<Code and Solder> And the cable supplier said they can provide .S2P too if asked
<azonenberg>
makerprobe: um, interesting. And well, the easiest option is probably to install latest catch2 from source after removng the ubuntu package
<azonenberg>
assuming you dont need it for something else
<d1b2>
<Makerprobe> The yml file checks out an older version though
<azonenberg>
yeah that's probably for build reproducibility
<azonenberg>
or maybe that was latest when we wrote the script :p
<d1b2>
<Makerprobe> Please have a look at that github issue I linked above. My impression is that scopehal requires an older version
<azonenberg>
yeah i'm looking. I think the only issue we had was with 3.x
massi has quit [Remote host closed the connection]
<d1b2>
<Makerprobe> hm...do I need it for something else? good question. I'll try to find out but that's probably hard to get right
<d1b2>
<Makerprobe> well I'll just give it a try. I can still go back to the official package if that is necessary
<azonenberg>
catch2 is only needed for building unit tests
<azonenberg>
so if you set BUILD_TESTS off in the cmake scripts
<azonenberg>
you can just ignore it
<azonenberg>
if you're just using, rather than developing, the project you can forget about tests
<d1b2>
<Makerprobe> ah well, it works now so it's even good in case I decide to touch the code
<d1b2>
<Makerprobe> I'll try to connect to my scope later
<azonenberg>
makerprobe: awesome. Feel free to also try out ngscopeclient, the next-gen GUI which is going to replace glscopeclient eventually
<azonenberg>
it should feel smoother and faster but it's still missing a bunch of features, most notably the ability to load and save .scopesession files. so anything you do in ngscopeclient is lost when you quit
<d1b2>
<Makerprobe> where is ngscopeclient?
<azonenberg>
also in scopehal-apps
<azonenberg>
if you built glscopeclient you probably have an ngscopeclient binary sitting right next to it
<azonenberg>
They should mostly act similar, one big difference is that ngscopeclient supports arbitrarily many waveforms in a single plot
<d1b2>
<Makerprobe> but it was not installed by make, right?
<azonenberg>
I don't know if "make install" is set up for it or not
<azonenberg>
but it's in the build directory
<azonenberg>
ngscopeclient is not ready for prime time so we havent put a lot of time into that kind of polish yet
<azonenberg>
if it is installed at all it's likely incomplete and missing important files
<d1b2>
<Makerprobe> where exactly should the binary sit?
<azonenberg>
anyway, the user-facing impact of that change is that the context menu with all of the protocol decodes and such is now accessed via right clicking the channel box rather than the plot
<azonenberg>
(brb)
azonenberg has left #scopehal [#scopehal]
azonenberg has joined #scopehal
<d1b2>
<Makerprobe> found it
<azonenberg>
This is because right clicking on the plot provides no way to disambiguate between multiple channels that might be in said plot
<azonenberg>
so there's no way to know what you wanted to decode
<azonenberg>
the channel button removes that ambiguity
<azonenberg>
but it is a UX change vs glscopeclient
<azonenberg>
most other stuff should act about the same with small improvements like nicer looking Y axis grids
<azonenberg>
(for the subset of features that are supported)
<d1b2>
<Makerprobe> I've never used either earlier, so no change for me
<azonenberg>
ngscopeclient also adds a bunch of new capabilities like controlling power supplies and multimeters and vector signal generators that glscopeclient never had
<azonenberg>
I'm aiming for very early 2023 reaching feature parity and officially deprecating glscopeclient although we probably wont remove it from the repo for a few more months so in case of bugs in ngscopeclient people will have a fallback
<azonenberg>
and of course glscopeclient will remain in history if someone needs to resurrect it for some reason
<d1b2>
<Makerprobe> that's good - some people build a lot of custom stuff as well
<azonenberg>
but as of now it's kinda in maintenance mode and all new dev efforts are focused on the ngscopeclient side
<d1b2>
<Makerprobe> can I also pull a screenshot from a scope or is that out of scope?
<azonenberg>
Both share the same backend so libscopehal/libscopeprotocols
<azonenberg>
meaning instrument drivers, protocol decodes, math functions, etc behave identically across both
<azonenberg>
they're just new UIs
<azonenberg>
There is currently no support for grabbing the native instrument screen
<azonenberg>
most devices do provide a scpi command for that, but it's not something we've really needed since our local UI is intended to be better :p
<d1b2>
<Makerprobe> well the screenshot does come in handy to quickly document some settings for example
<azonenberg>
Feel free to file a ticket against scopehal to add an API for that. It's probably not going to be a priority
<d1b2>
<Makerprobe> I've been looking for a reliable tool since some DS1054Z python script broke for me
<azonenberg>
but if it's on the list someone will work on it. eventually...
<azonenberg>
We have limited dev resources and have to pick and choose our battles so we usually focus on things that impact a lot of users or that we need in our own daily jobs
<azonenberg>
most if not all of the core devs use glscopeclient/ngscopeclient on a daily basis at work and in some cases are doing dev on company time to support that
<d1b2>
<Makerprobe> I understand - then I'll open an issue, and maybe even pick it up myself when I feel confident to tackle that
<azonenberg>
ideally, you'd wnat to file two issues
<azonenberg>
one against scopehal for the API and driver support
<azonenberg>
and one against scopehal-apps, dependent on the scopehal issue, for creating a GUI in ngscopeclient allowing you to pull a screenshot from a connected instrument, view it, and export to an image file
<d1b2>
<Makerprobe> make sense
<azonenberg>
The reason the projects are separate is that we also want to replace the VISA / raw scpi scripting use case
<azonenberg>
scopehal is intended to be usable headless for ATE environments, in fact this potential is where a lot of our commercial resources are targeted
<azonenberg>
being able to create a pass/fail test that detects "first Ethernet frame sent by the device after this GPIO goes high has a MAC address starting with de:ad:be:ef"
<d1b2>
<Makerprobe> that was my first impression as well and it makes sense to me
<azonenberg>
or that the eye pattern of a given interface has a mask hit rate below 1e-6
<azonenberg>
etc
<azonenberg>
One planned future capability is creating a complex analysis pipeline as a ngscopeclient filter graph in the GUI
<azonenberg>
then exporting a generated C++ code block that instantiates that same pipeline
<azonenberg>
which is ready to be inserted into an ATE application
<azonenberg>
I don't know how far out it is, but it's on the wishlist
<azonenberg>
i also want to be able to synthesize waveforms using a combination of imports from files, acquiring from instruments live, and filter graph blocks
<azonenberg>
then push to an AWG or the I/Q baseband of a vector signal generator and use as a stimulus for a DUT
<d1b2>
<Makerprobe> way over my head there - I just want to see if it works at all for me first
<azonenberg>
Here's an example of what we have in mind: take a 100mbit ethernet waveform recorded at a transmitter and a Touchstone file containing a VNA measurement of a max length CAT5 cable
<azonenberg>
combine the two to generate the waveform after channel loss and dispersion
<azonenberg>
then push that to an arbitrary waveform generator that can replay that same waveform
<azonenberg>
and see if your DUT can link up with it
<d1b2>
<Makerprobe> so I've got my scope connected, some things I noticed immediately: - there's no device detection. Not a big deal, but typing/pasting the path is tedious - a typo in the path crashes ngscopeclient - no immediate forced trigger for my rigol implemented - arming in ngscopeclient and then forcing the trigger with the scope's physical button ended with a floating point exception
<azonenberg>
Ok so, one thing at a time
<d1b2>
<Makerprobe> yes, of course
<azonenberg>
Device discoveryt is a hard problem :)
<azonenberg>
especially since in any nontrivial network they're gonna be on separate subnets etc
<d1b2>
<Makerprobe> I know, that's why I'm not demanding it
<azonenberg>
typos in the path should not crash. expected behavior in case of invalid path in ngscopeclient (glscopeclient handles it less gracefully) is a little popup saying connection error
<azonenberg>
and cleanly falling back as if you had never connected
<d1b2>
<Makerprobe> I would have liked that
<azonenberg>
Yeah. So if it does not do so, it's a bug and should be reported as such on github
<azonenberg>
preferably with screenshots and a stack trace of a debug build (cmake with -DCMAKE_BUILD_TYPE=DEBUG)
<azonenberg>
glscopeclient arms the trigger in normal mode when you connect
<azonenberg>
ngscopeclient might not yet, although it will eventually
<d1b2>
<Makerprobe> Like so? ~/scopehal-apps/build$ cmake ../ -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/usr
<azonenberg>
Yes. I forget if it has to be capital or not (DEBUG)
<azonenberg>
but that's how i usually do it
<d1b2>
<Makerprobe> it was "Release" previously
<d1b2>
<Makerprobe> Camal
<d1b2>
<Makerprobe> *Camel
<azonenberg>
ah then Debug is probably OK
<azonenberg>
in any case, debug build disables some optimizations and enables gdb symbols
<azonenberg>
so you'll get cleaner stack traces
<azonenberg>
You generally don't want to mess with trigger settings on the scope when using gl/ngscopeclient, because it expects to control when triggers happen
<azonenberg>
in particular, since it has to download waveforms with many consecutive SCPI commands, a trigger in the middle of that can lead to race conditions where half your data is from one trigger and half is from another
<azonenberg>
This is why i've been advocating a push-based flow where the instrment sends waveform data to you, synchronizing in firmware
<azonenberg>
but no major vendor has implemented this yet
<azonenberg>
(this is how our socket servers for USB instruments work though)
<azonenberg>
But it should not crash
<azonenberg>
in general any crash is a bug and should be reported
<d1b2>
<Makerprobe> building debug now
<azonenberg>
and while ngscopeclient is lacking features glscopeclient has, the features it *does* have should work reliably and not crash
<d1b2>
<Makerprobe> [ 80%] Building CXX object src/glscopeclient/CMakeFiles/glscopeclient.dir/cmake_pch.hxx.gch In file included from <command-line>: /usr/include/stdc-predef.h:1: fatal error: cannot create precompiled header CMakeFiles/glscopeclient.dir/cmake_pch.hxx.gch: Permission denied 1 | /* Copyright (C) 1991-2022 Free Software Foundation, Inc. | compilation terminated.
<d1b2>
<Makerprobe> that looks odd
<azonenberg>
did you "make install" as root maybe?
<azonenberg>
might have chown'd some files
<d1b2>
<Makerprobe> yes that was with sudo
<azonenberg>
yeah try chown'ing the build directory back to yourself
<d1b2>
<Makerprobe> yup, running now
<d1b2>
<Makerprobe> not sure if, after "sudo make install", my applications were actually overwritten with the debug version
<d1b2>
<Makerprobe> can't find a core dump
<azonenberg>
yeah that depends on how your system is configured WRT if they're on by default
<azonenberg>
i usually just run under gdb
<d1b2>
<Makerprobe> had to ulimit -c unlimited now it's there, 108 MB
<d1b2>
<Makerprobe> how would I create a stack trace for you?
<azonenberg>
open in gdb and run "bt"
<azonenberg>
from the core dump state
<azonenberg>
then either upload to a pastebin (preferable) and put the link here, or dump the trace in a DM
<azonenberg>
so as to not spam the main channel with a hundred lines of text
<_whitenotifier>
[scopehal] azonenberg cfcb2d1 - SCPITMCTransport: fixed bug where m_staging_buf was left uninitialized if open(m_devicePath) fails, leading to a segfault in the destructor. Fixes #739.