<_whitenotifier>
[scopehal] azonenberg b295532 - Started work on improving Doxygen coverage
<_whitenotifier>
[scopehal] azonenberg e7d96e3 - The doxygen rampage continues
<azonenberg>
Welp, i guess i'm on an api documentation kick now lol
<azonenberg>
gonna be a bit before i end up putting all of this on the website but if you set "BUILD_DEVDOCS=ON" in the cmake script then "make devdocs" you should get doxygen
<azonenberg>
there's a lot more content to write, i'm aiming to at least get full coverage of all the core apis in libscopehal soon
<_whitenotifier>
[scopehal-apps] azonenberg dc26783 - Updated to latest scopehal and scopehal-docs, updated developer docs intro
<Fridtjof>
hmm. I want to add support to scopehal for my RD6006P PSU. It communicates using modbus over UART, and now i'm thinking about the least painful way to implement this. The driver/transport/bridge model seems to assume I want to use a scope in quite a few places... Implementing this in a bridge server a la Picoscope seems the most viable so far to me
<Fridtjof>
(doing it directly in scopehal seems like i'd also end up having to abstract away SCPITransport as well...
<azonenberg>
Fridtjof: There is absolutely no assumption you are using a scope
<azonenberg>
we support plenty of power supplies etc
<azonenberg>
We have native uart support for linux, i dont know about other platforms
<azonenberg>
The SCPITransport class is protocol agnostic despite the name, we might rename it
<azonenberg>
The base instrument classes kinda assume you are using SCPI but is a weak assumption
<azonenberg>
there is an argument you can send to the constructor to say 'don't send *IDN?" during startup
<azonenberg>
in which case you can simply use the SCPITransport as a raw byte transport and run modbus or whatever over it
<azonenberg>
If you want to make a scpi to modbus bridge thats not a completely ridiculous option given that this would also allow network transparency of the thing
<azonenberg>
but is absolutely not required to make it work
<d1b2>
<fridtjof> Oh okay, that is very surprising yeah :D
<azonenberg>
Basically there are some apis in SCPITransport that provide convenience wrappers for sending line oriented text data with mutexing and stuff
<azonenberg>
but if you dont mind more legwork you can just call ReadRawData and SendRawData, iirc, to access the underlying file handle / socket / whatever
<d1b2>
<fridtjof> I see
<azonenberg>
You just have to manage locking yourself so different threads don't step on each other. the transport has a mutex for this purpose but you're responsible for locking so transactions are atomic
<azonenberg>
i.e. lock, send command, wait for reply, unlock
<azonenberg>
(otherwise you risk sending a command in the gui thread stepping on stuff the background polling thread is doing)
<d1b2>
<fridtjof> Still leaning towards the bridge approach because i'd like to skip implementing modbus with a library And i feel it's not worth adding to scopehal unless there'll be more instruments that would need it
<d1b2>
<fridtjof> also yeah network transparency is probably nice
<azonenberg>
(From a general perspective, if you find an instrument that doesn't fit our object model well i'd love to hear about it and figure out how we can make it work)
<azonenberg>
Idea (not necessarily the best)
<azonenberg>
Generic modbus to scpi network bridge
<azonenberg>
then implement the device specific driver stuff in scopehal
<azonenberg>
this would allow future integration with other modbus peripherals
<azonenberg>
using the same bridge
<azonenberg>
Maybe make the bridge generic enough it can work with modbus over IP as well as rs232/rs485 etc
<d1b2>
<fridtjof> So just pipe modbus register r/w through scpi?
<azonenberg>
Yep
<azonenberg>
just a simple 1:1 protocol translation
<d1b2>
<fridtjof> hmm
<azonenberg>
implement *IDN? to identify the bridge and then MODBUS? 0x4141
<azonenberg>
MODBUS 0x4141 = 0xdeadbeef
<azonenberg>
or something like that
<azonenberg>
again not saying its the best optoin but it came ot mind
<d1b2>
<fridtjof> is there anything standard i can rely on with modbus to identify stuff? From my first glance it seemed to be just bare registers but i might not have looked into this enough
<d1b2>
<fridtjof> Ah function code 0x43 supposedly
<d1b2>
<fridtjof> *43 decimal
<azonenberg>
if you can translate that to *IDN? usefully great. if not, maybe add a bridge argument to specify what is hanging off the bridge
<azonenberg>
so at least scopehal has some way to get ID information
bvernoux has joined #scopehal
<d1b2>
<fredzo_72653> LA support for Siglent SDS complete !