Hi Lundmar, everyone,
I'd like to make an instrument that is controlled by LXI, I'm using an Arduino Due with Ethernet-shield on the Due.
Could you give some pointers on where to begin?
By googling I found some parsers for SCPI-commands (formatted ascii-text) - but I'm not sure what goes on top of the Arduino Ethernet driver to receive LXI commands?
Previously we used Modbus/TCP on the Arduino Due (and found a ready made library for that), but I'd like to move to LXI as modbus seems quite 1980s...
thanks!
AW
A LXI compatible instrument supports one of the following protocols for communicating SCPI: RAW/TCP, VXI11/TCP, HiSlip/TCP.
You have to decide which communication protocol to go with for your server implementation and then add to that your SCPI parser.
RAW/TCP offers fast communication but is less robust. It is easy to implement as it is just a standard socket TCP server. There are countless examples available online on how to create socket TCP servers.
VXI11/TCP is robust but slow as it introduces a lot of protocol communication overhead. It is more complicated to implement as it is a protocol based on the aging RPC framework. Both VXI11 client and server stubs are defined by this file: https://github.com/lxi-tools/liblxi/blob/master/src/vxi11core.rpcl and then generated into C code using the rpcgen tool: https://linux.die.net/man/1/rpcgen . General guides on how to implement a RPC(gen) server are available, for example: https://docs.oracle.com/cd/E19683-01/816-1435/rpcgenpguide-21470/index.html . However, the specific VXI11 server stub implementation is largely undocumented AFAIK which makes it harder to implement.
A LXI compatible instrument supports one of the following protocols for communicating SCPI: RAW/TCP, VXI11/TCP, HiSlip/TCP.
You have to decide which communication protocol to go with for your server implementation and then add to that your SCPI parser.
RAW/TCP offers fast communication but is less robust. It is easy to implement as it is just a standard socket TCP server. There are countless examples available online on how to create socket TCP servers.
VXI11/TCP is robust but slow as it introduces a lot of protocol communication overhead. It is more complicated to implement as it is a protocol based on the aging RPC framework. Both VXI11 client and server stubs are defined by this file: https://github.com/lxi-tools/liblxi/blob/master/src/vxi11core.rpcl and then generated into C code using the rpcgen tool: https://linux.die.net/man/1/rpcgen . General guides on how to implement a RPC(gen) server are available, for example: https://docs.oracle.com/cd/E19683-01/816-1435/rpcgenpguide-21470/index.html . However, the specific VXI11 server stub implementation is largely undocumented AFAIK which makes it harder to implement.
Thanks for this explanation. I found this vxi-11 implementation on arduino due:
https://www.bankras.org/projects/electronics/instrument-of-things/
and that code is now here: https://github.com/bankrasrg/colortestkitmeter
I will try to get it working and see how far I get.
If it gets too complicated I guess I will just fall back to simple http control only.
AW
Though, it's a shame it is GPLv3.
?
Though, it's a shame it is GPLv3.
?
I would prefer a more permissive license. If you include GPLv3 code in your firmware you are forced to make all your firmware GPLv3.
Though, it's a shame it is GPLv3.
?
I would prefer a more permissive license. If you include GPLv3 code in your firmware you are forced to make all your firmware GPLv3.
And what's wrong with that? You use my code, I use your code. Sounds fair to me.
You'd prefer that people can take without giving back?? Doesn't sound fair to me.
I would prefer people take my code and use it in whatever way they want - if they give back fine, if not fine too. I don't really want to put any restrictions like the GPLv3 does.
I would prefer people take my code and use it in whatever way they want - if they give back fine, if not fine too. I don't really want to put any restrictions like the GPLv3 does.
Why is it a shame if somebody wants to put restrictions on the use of his software?
According to you it's a shame if people want to sell software, either open or closed source,
either for money or for giving back your code?
I would prefer people take my code and use it in whatever way they want - if they give back fine, if not fine too. I don't really want to put any restrictions like the GPLv3 does.
Why is it a shame if somebody wants to put restrictions on the use of his software?
According to you it's a shame if people want to sell software, either open or closed source,
either for money or for giving back your code?
Thats not what I said at all.
I would prefer people take my code and use it in whatever way they want - if they give back fine, if not fine too. I don't really want to put any restrictions like the GPLv3 does.
Why is it a shame if somebody wants to put restrictions on the use of his software?
According to you it's a shame if people want to sell software, either open or closed source,
either for money or for giving back your code?
Thats not what I said at all.
You said: "it's a shame it is GPLv3"
I would prefer people take my code and use it in whatever way they want - if they give back fine, if not fine too. I don't really want to put any restrictions like the GPLv3 does.
Why is it a shame if somebody wants to put restrictions on the use of his software?
According to you it's a shame if people want to sell software, either open or closed source,
either for money or for giving back your code?
Thats not what I said at all.
You said: "it's a shame it is GPLv3"
Yes, exactly. For the reasons I stated.
Karel,
Why we should be so literal?
Lets thank lundmar for his great work
And let everyone of us has its own opinion about the open source licenses
I would prefer people take my code and use it in whatever way they want - if they give back fine, if not fine too. I don't really want to put any restrictions like the GPLv3 does.
Why is it a shame if somebody wants to put restrictions on the use of his software?
According to you it's a shame if people want to sell software, either open or closed source,
either for money or for giving back your code?
Thats not what I said at all.
You said: "it's a shame it is GPLv3"
Yes, exactly. For the reasons I stated.
So, you say it's a shame if somebody publishes opensource code under a license that requires you to give back your code.
But isn't it a shame if people only want to take and not to give back?
It's a shame that my baker asks money for his bread. This way I can't take his bread without giving him money. My baker is too restrictive...
To go with the above post, here is an example of the web UI of the RTB2004, which I'm guessing is the sort of thing that lundmar is getting to:
(note that the mouse was hovering over the horizontal scale knob when I captured this - see the arrows that come up)
Unfortunately implementing this isn't something I can do either (in this case due to lack of skill rather than time, though time is lacking as well!)
To be honest, I don't see the point of front panel emulators. If I want to use the instruments front panel, I dont need a computer.
What would be much more useful in my view would be some way of writing simple scripts so I can do something like this
For V = 0 to 3.3 step 0.1
Set the power supply output to V
Tell the meter to read the current I
Save V, I to file
End for
Surely such automation is the real use of LXI, not just having a remote front panel?
Just tested the HMO/RTB screenshot plugin with some other R&S/Hameg instruments.
HMC8043 power supply: works, autodetects correct plugin.
HMC8012 DMM: works, does not autodetect plugin as IDN string returned starts with "HAMEG", not "Rohde & Schwarz", even though the branding is R&S otherwise. First part of returned string is "HAMEG,HMC8012".
HMO3054: works, same issue as HMC8012: IDN string contains HAMEG, not R&S.