Legality of writing software that controls devices via LXI as an independent dev

[szszoke]

Hello!

I am wondering if anyone knows anything about the legality of writing and releasing software that controls test equipment via LXI as an individual.

I tried to look this up, but the only information I found was about the LXI logo, and the LXI trademark itself, nothing about what it takes to be able to write and distribute software that controls LXI devices.

Can I write and distribute software that controls LXI-compatible test equipment just like that or I need to buy some kind of license/become a member at the LXI Consortium?

[tautech]

Ask member lundmar here:
https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/

[szszoke]

Thank you for the suggestion! I already did that and I am waiting for his response.

[nctnico]

Another question is: why would you want to use LXI in the first place? To me it seems much more cumbersome compared to using a plain text SCPI interface over network or USB.

[szszoke]

To be honest, I assumed that I have to. It seemed that SCPI and LXI goes hand in hand.

I recently got some Siglent gear that can be remote controlled via SCPI commands but the Easy*** applications are horrible.

I am a software engineer by trade so I figured I could try creating something useful and share it with the community. I'm thinking of something that would make data logging easier, or just have a window that would display data from the instruments.

So when you mean SCPI interface over network, do you mean something like sending SCPI commands over TCP sockets for example?

[nctnico]

So when you mean SCPI interface over network, do you mean something like sending SCPI commands over TCP sockets for example?

Yes. And due to the simplicity most test equipment supports this either through USB (TMC; which is a text based interface), network, RS232 or GPIB (which is simple to convert to a network socket interface using a Prologix interface). Did you already come across this thread? https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-multimeters/msg2981004/#msg2981004
The software from this thread has morphed into a universal logging application which can talk to / log from any instrument. Perhaps you can team up with the author. And then there is Sigrok as well.

[szszoke]

Now I feel dumb. But hey, my issue is resolved!

I tried with both of my Siglent devices and indeed, I could telnet into them over port 5025 and issue SCPI commands.

Thanks!

Regarding the project you linked, I did, but I am thinking in a web-based solution, so that I can put a database behind it and save everything by default.

I also have multiple computers that I want to use to look at the logged data.

Since all of my (two) devices can be controlled over ethernet, and I will make this a priority for any new purchase, a web based solution makes the most sense to me.

[tautech]

I tried with both of my Siglent devices and indeed, I could telnet into them over port 5025 and issue SCPI commands.

Port availability is listed in manuals or programming guides.

Since you have the same DSO and PSU some tricks HendriXML has done with these may interest you.
https://www.eevblog.com/forum/testgear/battery-charging-using-a-siglent-sds1104x-and-spd3303x/
https://www.eevblog.com/forum/testgear/automated-wave-capture-for-siglent-sds1104x-e-and-sds1204x-e-dsos/

[tautech]

I am thinking in a web-based solution, so that I can put a database behind it and save everything by default.

I also have multiple computers that I want to use to look at the logged data.

Since all of my (two) devices can be controlled over ethernet, and I will make this a priority for any new purchase, a web based solution makes the most sense to me.

Have you explored the webserver capabilities of your SDS1104X-E ?
in the Instrument Control page you can expand the interface and access full mouse control of the scope and there's some additional virtual buttons one of which will save screenshots direct to your browsers download folder.
The SCPI control window permits full SCPI control of the scope.
SCPI programming manual:
https://www.siglenteu.com/download/9103/

[szszoke]

I did. I think it's good that it is there but it's not quite what I'm looking for.

I like that it has a VNC server built in, and I think it could be useful to have a data logging session where the screen is captured as well.

[szszoke]

I tried with both of my Siglent devices and indeed, I could telnet into them over port 5025 and issue SCPI commands.

Port availability is listed in manuals or programming guides.

Since you have the same DSO and PSU some tricks HendriXML has done with these may interest you.
https://www.eevblog.com/forum/testgear/battery-charging-using-a-siglent-sds1104x-and-spd3303x/
https://www.eevblog.com/forum/testgear/automated-wave-capture-for-siglent-sds1104x-e-and-sds1204x-e-dsos/

This looks really good!

Thanks for the suggestion!

[nightfire]

Could you perhaps use https://lxi-tools.github.io/ as a foundation for your work? Like, putting a web-interface on top of it?

[szszoke]

The project seems abandoned. At this point I would rather not touch it.

It is also written in C++ and I'm planning to use C# as the backend, since that is where I'm more competent.

As of right now, I'm planning to use simple TCP sockets for communication, so there is really no need to bring in any third party library.

I gave this project a bit more thought and as of right now my plan is to make it centered around scripting.

Essentially there would be a layer that abstracts away the equipment and implements I/O.

This later will be responsible for putting a common interface in front of test equipment, or devices under test and I'm initially thinking of supporting communication over TCP and over serial ports. (These are the two use-cases that are relevant for me right now)

After this comes a persistence layer, which stores everything that comes and goes from devices in a dataset with timestamps.

With some simplification, we can say that every command and response from a device is a data point.

I'm planning on having logging "sessions" that would group a collection of data points together.

Then comes the scripting layer where custom scripts can be executed.

The scripts would have exposed slots for devices.

Device I/O would go through these slots. Scripts would also be able to "yield" results.

All device I/O and yielded data would be recorded by the persistence layer.

Later some UI would be able to visualize these recorded sessions if needed.

This is the initial draft of my idea.

It's almost like having a Python script writing into a CSV file but more standardized.