<_whitenotifier-9>
[scopehal] azonenberg bace8c4 - LeCroyFWPOscilloscope: added support for only using some channels. Added automatic configuration of FastWavePort math blocks
<azonenberg>
ok i think that's about it for the initial fastwaveport stuff
<azonenberg>
it works, it's ~twice as fast as scpi, but you have to stay within the limitations
<josuah>
> FastWavePort is a processing function for LeCroy oscilloscopes that enables you to insert your own custom processing algorithm, written in the C/C++ language, into the oscilloscopes processing stream. FastWavePort maximizes data throughput from the acquisition system to your processing. -- https://teledynelecroy.com/options/productdetails.aspx?modelid=1032&categoryid=12&groupid=144
<josuah>
So this means FastWavePort also comes with a protocol for exchanging data in the style of SCPI?
<monochroma>
unless you see something different, it sounds like it's just an API interface, and you have to deal with data transport
<josuah>
a protocol specialized to upload compiled software?
<monochroma>
the lecroy scopes UI are just windows PCs
<electronic_eel>
from what azonenberg described it is some api for windows that runs on the scope.
<josuah>
monochroma: oh :)
<josuah>
electronic_eel: thank you, that makes it more clear
<monochroma>
so you just compile a program to interface with the MAUI software stack running on it, and do your own networking
<d1b2>
<Darius> "just" 😂
lain has quit [Ping timeout: 246 seconds]
lain has joined #scopehal
<azonenberg>
Yes. FastWavePort is just a local windows shared memory API
<azonenberg>
josuah: glscopeclient/scopehal-fwp-bridge is a bridge that goes from that to a TCP server on port 1862
<azonenberg>
which is used by the lecroy_fwp driver, along with the VICP SCPI server on port 1861 provided by the stock firmware, in a manner similar to how our other dual socket bridges work
<azonenberg>
you use scpi for control plane and the second socket for push based data transfer
<azonenberg>
the intended use of fastwaveport is injecting custom processing into the scope software flow, much like a scopehal filter graph but far more limited
<josuah>
ok makes all more sense now, shared memory with a wire encoding: in-between a remote program and a protocol
<azonenberg>
but nothign stops you from then exporting that data over a socket or something
<azonenberg>
fastwaveport is a single data channel in and out (we ignore the out and just leave the data unchanged)
<azonenberg>
the newer fastmultiwaveport API allows you to take up to four channels and two scalars as input, and output four channels and i think eight measurement values
<azonenberg>
(but it's very poorly documented and to date i have not got it to work)
<azonenberg>
note that neither one gives you the ability to output protocol decode events or read/write digital channels
<josuah>
Thank you for the overview. Scope-HAL integrates quite the advanced features of these series
<azonenberg>
Yeah my SDA816Zi-A is the first scope i've had with fastwaveport
<josuah>
are you trying per chance to get LeCroy give-up on their own software stack? :D
<d1b2>
<david.rysk> does their fastmultiwaveport example code not work?
<azonenberg>
lol they make enough money selling software options i doubt that will happen
<azonenberg>
@david.rysk: soooo
<josuah>
Not sure there is any single particular goal like that
<azonenberg>
that's a bit of a loaded question
<azonenberg>
The tl;dr is that the example code a) appears to have bitrotted, support emailed me a zip file with three different example projects which all looked to be forks of the same code
<d1b2>
<david.rysk> lol what
<azonenberg>
the most recent one was for vs2017, the rest for vs2008
<azonenberg>
the latter did not compile under win64 without some modifications
<d1b2>
<david.rysk> hm
<azonenberg>
e.g. hard coding 0xffffffff instead of INVALID_HANDLE_VALUE
<azonenberg>
the vs2017 compiled IIRC
<d1b2>
<david.rysk> is their DLL win64?
<d1b2>
<david.rysk> oops
<azonenberg>
i dont think i had to patch it
<azonenberg>
but there was no example filter graph to actually USE it
<azonenberg>
and when i tried to run it, i was unsuccessful at getting the 'data available' event to ever fire
<azonenberg>
the same happened with my own independently written test code
<azonenberg>
i plan to follow up with support on monday
<d1b2>
<david.rysk> ah right, this uses shared memory
<d1b2>
<david.rysk> not calling into a DLL
<azonenberg>
Correct
<d1b2>
<david.rysk> I see what you mean...
<azonenberg>
They do not have any DLL interfaces
<azonenberg>
the normal interface is COM Automation
<azonenberg>
(if you wanted to use non-scpi for native localhost instrment control)
<d1b2>
<david.rysk> yeah, I'd have expected COM (which is messy but usually works)
<d1b2>
<david.rysk> but that's control not data
<azonenberg>
in fact the scopehal driver does most of its work by sending COM object read/write commands tunneled over scpi using the 'vbs' command which executes a line of vbscript
<d1b2>
<david.rysk> 🙃
<azonenberg>
ugly, but appears to be the only alternative to using DCOM which isnt available on non-windows clients
<azonenberg>
if you read the XDEV manual it mentions the existence of FMWP but does not give any details on how to set it up
<azonenberg>
when i emailed support to ask about more detailed docs they sent me those three vs projects plus a PDF marked 'preliminary' and dated march 2007
<azonenberg>
that had more details on the ring buffer descriptors and such - but it also was missing some content so i *Know* it's out of date
<azonenberg>
e.g. it did not mention the scalar input ports
<azonenberg>
which are visible in the filter graph view and the xdev documentation
<azonenberg>
so it wouldnt surprise me if some API struct or something has changed between then and now and docs never got updated
<azonenberg>
i get the impression FMWP is something a single digit number of large companies use and it's probably something that require extensive handholding from their apps engineers to get working
<josuah>
as if the developer who originally did the dev is long gone away from LeCroy, and they do their best to glue it together
<josuah>
or eventually did simply not have the time budget or interest to maintain it soo toughly
<azonenberg>
josuah: there are two names in the header file
<azonenberg>
i looked both up on linkedin
<azonenberg>
the first left lecroy quite a while ago and is now the owner of a FPV video products company
<azonenberg>
the second appears to still be a principal engineer at lecroy
<azonenberg>
he was recently congratulated on 45 years there in some blog article or something
<josuah>
wow!
<josuah>
quite some story under a simple feature, looks like you investigated plenty too
<azonenberg>
Yes lol
<azonenberg>
this is an extremely obscure feature :p
<azonenberg>
The XDEV option enables some other APIs which i think are more commonly used, such as the ability to integrate matlab processing functions into the scope processing pipeline
<azonenberg>
or - i wish i was kidding - excel formulas
<azonenberg>
and/or vba macros in excel
<monochroma>
azonenberg: do you remember what that one guy who worked at lecroy was planning on using for doing the fast interface they were working on?
<azonenberg>
that was ziggy, he was going to use the COM interface from .net and try to pull waveforms off that way
<azonenberg>
covid hit and he got laid off before he finished and as far as i know the code never got picked up by anyone else
<d1b2>
<20goto10> Ah I've just discovered the github actions builds - I'll try them tomorrow 🙂