EEVblog Electronics Community Forum
EEVblog => EEVblog Specific => Topic started by: EEVblog on October 19, 2018, 12:13:18 am
-
David explains how to implement a SCPI "Skippy" instrument control command parser in C++
https://www.youtube.com/watch?v=GarToEo6ekQ (https://www.youtube.com/watch?v=GarToEo6ekQ)
-
Thank you very much for this it is very helpful, as an FYI, there is a wonderful library that I used to implement a SCPI interface for a testing instrument I am making, it is super complete and not hard to use, it is written in C and so it is easily portable to anything.
http://j123b567.github.io/scpi-parser/basic/. (http://j123b567.github.io/scpi-parser/basic/.)
We need more David2 videos he is very knowledgeable and gives an alternate view.
-
I'm wondering what was David's primary motivation for making his own SCPI parser. @riyadh144 already mentioned one that is mature and "field proven": It is used as basis for H24005 SCPI (http://www.envox.hr/eez/bench-power-supply/psu-scpi-reference-manual/psu-scpi-introduction.html) support (feel free to test everything online here (https://www.envox.hr/eez-psu-simulator/) just to got an idea: "front panel" display is clickable, load can be apply by clicking and hover over left and right).
We learned over the time that serious SCPI support is not a simple task (like any other good piece of software anyway), and even with decent SCPI parser one could be a pretty busy to make everything well done, and safe what is of paramount importance for any PSU as sourcing type of T&M device.
-
The Python language could be a good choice for SCPI and even GPIB programming.
It works on pretty much any computer (including Raspberry Pi), easy to learn, very suited for data / scientific / technical processing.
It is an interpreted language, so you can sit and play with all the GPIB instruments from the command line without compiling an application (unlike C++)
C++ is a bit of a firebreathing monster if you don't intend to become a professional, full time programmer.
-
Python, being an interpreted language, is a slow and resource consuming behemoth that is completely unsuitable for a piece of test equipment, which should primarily be responsive.
-
Python, being an interpreted language, is a slow and resource consuming behemoth that is completely unsuitable for a piece of test equipment, which should primarily be responsive.
Honestly no offence but of you can’t make a responsive python application for a modern instrument (so likely cortex core A9 at 600 MHz to a GHz (NXP Im.x Xilinx zynq class MPU) then you are doing something really really wrong and you should quit programming altogether.
So stop spreading FUD about python...
It isn’t the fastest languages in town, but that is fine, it isn’t meant to be but if your responsiveness benchmark is the human eye (60Hz at best) you don’t need it
-
I like C and its my most used language, but i have to admit something like python is indeed more suitable. Sure C is fast but its also clumsy for working with strings and quicly doing something usefull with the data in just a few lines if code.
SCPI is in itself ineficent because its human readable ASCII. A lot if instruments like DMMs dont give a lot of data anyway and pretty much no scope can saturate a 1Gbit LAN connection so even a slow laguage can keep up with the flow of data.
I personaly like C# for this as its a nice middle ground between fast C and flexible scripting like Python
-
I just wanted to say that this code is a good first effort, but a bit misguided as far as parsers go.
I suggest reading the first few chapters of the dragon book to get an idea of how to think about a problem like this.
“Compilers: Principles, Techniques, and Tools”, Aho, et. al.
-
Python, being an interpreted language, is a slow and resource consuming behemoth that is completely unsuitable for a piece of test equipment, which should primarily be responsive.
Honestly no offence but of you can’t make a responsive python application for a modern instrument (so likely cortex core A9 at 600 MHz to a GHz (NXP Im.x Xilinx zynq class MPU) then you are doing something really really wrong and you should quit programming altogether.
So stop spreading FUD about python...
It isn’t the fastest languages in town, but that is fine, it isn’t meant to be but if your responsiveness benchmark is the human eye (60Hz at best) you don’t need it
Using a Cortex A9 for something as basic as a power supply seems rather excessive. For something that has to do a reasonable amount of processing, I could see it being useful, but for setting a bunch of DACs and occasionally reading an ADC, it seems way too costly (you also need an expensive PCB and other bells and whistles to go with it).
Python would be a very nice choice for coding the PC-side interface, though.
-
Thanks for this. I will review again when I have more time. A few observations, I think the proper form of the example keyword is :HELLo. Also, sens is usually optional, so does that make the following keywords within the sense subsystem root keywords?