[Ground-station] "Hello World" acceptance testing for test equipment

[Drew Arnett]

Hmm.  May not be able to do that quickly let alone ever.  Legal
posture is a bit protective.

I could walk through it with someone interactively (zoom, the other
one I forget the name of, whatever) if you're not that far along, yet.
General idea is open a (tcp) socket to usually port 5025 (lxi
default).  Put together functions/methods to read/write and then ask.
Ask and write are all you'll use.  I like to mimic pythonic
writelines, too.  Bonus points for checking *IDN to make sure it's an
instrument you expect to be talking to.  Write functions that use
write and ask and do natural type conversion for the functions you
want to use.  Continue layering from there as appropriate.  Easy to
agnosticize between telnet, lxi socket, and serial.  And even pyvisa
if you must.  Everything else is done with instrument manual in hand,
as SCPI is the language of the instrument.

Some similar ideas here:
https://github.com/morgan-at-keysight/socketscpi  I haven't talked to
them, yet, but could nitpick.  Introduces unnecessary dependencies for
one.

Haven't looked recently to see if anyone has done anything else
interesting.  PyVISA may work fine with no VISA stack installed for
LXI stuff.  I haven't looked at that in a LONG time.  Who has time to
wait for a VISA stack to install?  :-)

Drew

On Wed, Nov 4, 2020 at 5:01 PM Michelle Thompson
<mountain.michelle at gmail.com> wrote:
>
> Drew writes,
>
> "I guess I should check with work to see how I can help.  I have a
> small, useful example library that I had been pondering doing the
> paper work to publish as open source.  I guess I could actually do
> that now."
>
> This would be great.
>
> I think we're doing the things you outlined, with Python. We've been fortunate to get advice from engineers that work remotely in digital communications.
>
> While there are a number of academic papers about setting up labs for university level work, there are not many papers about industrial or professional remote labs. However, they do exist, there are useful design patterns, and we are going to use those patterns and take the good advice we've been offered. I think your philosophizing is right on track. I'm very much looking forward to the variety of work that can be enabled by doing all this.
>
> -Michelle W5NYV
>
>
>
>
> On Wed, Nov 4, 2020 at 3:25 PM Drew Arnett via Ground-Station <ground-station at lists.openresearch.institute> wrote:
>>
>> More philosophizing.  (Which of course is useless next to getting it done.)
>>
>> I'm not one to validate everything in a vendor's product.  That's one
>> of the things I'm paying them for.  And why I'll get bent out of shape
>> when I find something wrong.  And, yes, I find problems or limits in
>> documentation or implementation in stuff from Keysight and R&S.  And
>> that's not even from trying to exhaustively use the features.
>>
>> I myself don't write giant full featured libraries for instruments.
>> It's so easy to add whatever I need as I need it with the docs in
>> hand.  I think pre-existing libraries distance engineers from a level
>> of knowledge that might be helpful for them to wring the most out of
>> their instrument.  And frankly, it's a lot of work.  I think full
>> featured libraries make sense if the equipment vendor or a good
>> community group take it on.  In the python world, both are starting to
>> happen.  I see a community effort for a Rigol o-scope.  And, wow,
>> Keysight is doing so at least for some of their instruments.
>> Something I've been waiting for them to do for almost 20 years.  It's
>> OK if the test equipment vendors do different implementations for
>> their own stuff, so long as they don't do weird stuff that can create
>> run-time integration problems.
>>
>> So, back to this situation.  You've got a big order and are getting a
>> new lab full of gear.  Sitting with an instrument and using its front
>> panel and playing with it is the fastest way to get breadth of
>> coverage of the functionality.  Soft front panels are OK.  This could
>> be custom program or a web server running on the instrument that you
>> use with a browser.  The latter is super awesome these days for doing
>> a screenshot!  I didn't look, but I guess would be curious what the
>> soft front panel options are for your set of gear.  You want a front
>> panel/interactive experience for the first time doing anything.  But
>> each step you figure out, it should be moved to automation.  I use
>> interactive, automated setup + interactive, automated as my
>> progression with anything.  Python works great of course.  (Can you
>> tell I'm a python nut, yet?)
>>
>> Some simple examples for each of the instruments, maybe with a tiny
>> bit of reusable library that can be whipped up, using python to do a
>> few things with each of the instruments using standard interfaces (IP,
>> serial, serial over USB, libusb) may be very useful for some of the
>> folks who will be collaborating with this lab.  Doing this can help
>> get through some of the instrument learning curve.  And some 'demo'
>> stuff would be nice; always good to have some youtube fodder.
>> Lissajous or Bart heads anyone?  :-)
>>
>> I guess I should check with work to see how I can help.  I have a
>> small, useful example library that I had been pondering doing the
>> paper work to publish as open source.  I guess I could actually do
>> that now.
>>
>> Obviously I'm really keen on how to interface with instrumentation.
>> So, I'm always interested in early bringup of such or evaluation of
>> instruments for fitting in with what I consider best practices.
>> (Sorry, minicircuits.)  Fleshing out the entirety of an instrument's
>> feature set I never have interest in.  20 years of python test
>> equipment interfacing and I still don't have interest in that.  The
>> code is so small, lean, simple, and quick to implement for the 20% or
>> 80% of the featureset I need, that I cannot have interest in doing
>> more.  For example, for a Keysight 34410A DMM, I implemented only
>> 'read voltage', 'read current', 'read ohms' functions.  (With more
>> pythonic names of course.)  In my use case, had no need to override a
>> lot of the automagic settings like # of PLC to integrate over, or
>> continuity beeper, etc., etc.
>>
>> Drew
>>
>> On Wed, Nov 4, 2020 at 5:25 AM Drew Arnett <arnett.drew at gmail.com> wrote:
>> >
>> > I wonder if that HTTP protocol is safe from Little Jonny Drop Tables.
>> > :-)  (You know the old xkcd reference to sanitizing your input.)
>> >
>> > If you use python and one of the standards based interfaces:  SCPI
>> > over any one of TCP, telnet, serial, then the test software will run
>> > on anything.  Windows, linux, osx, pi, whatever.  No need for drivers
>> > of good or bad quality just to control the instrument.  Looks like
>> > those Rigol and even that Minicircuits meets my standard.  A simple
>> > thin abstraction and you don't care what the underlying transport for
>> > the SCPI is.
>> >
>> > Put all that test gear on a private lan and only with a trusted host
>> > with access to it.  Then don't worry about the security of the test
>> > equipment.  Unless you don't trust the test equipment.  :-)  Maybe
>> > firewall up?
>> >
>> > Telnet is just fine in some cases, but yeah, it has to be passwords in
>> > the clear are OK and no authentication needed kind of cases.  :-)
>> >
>> > Still not a fan of the HID 'trick' to try to make USB easy.  We've had
>> > libusb forever now.
>> >
>> > Drew
>> >
>> > On Wed, Nov 4, 2020 at 5:04 AM Paul Williamson via Ground-Station
>> > <ground-station at lists.openresearch.institute> wrote:
>> > >
>> > > > On Nov 3, 2020, at 7:50 PM, Drew Arnett <arnett.drew at gmail.com> wrote:
>> > > > Hello world for SCPI instruments is ask("*IDN?"), no?  What are you
>> > > > thinking about?
>> > >
>> > > I was thinking about something a little more instrument-specific. Make a meaningful measurement, exercise some of the neat features.
>> > >
>> > > > Are you accepting the gear or are you accepting the
>> > > > users for remote controlling of the gear?
>> > >
>> > > My notion was just to get the gear tried out right away, even if it wasn’t needed for any urgent testing requirement. If there’s a DOA we can get it fixed or replaced before it becomes a bottleneck. (Coincidentally this provides an excuse to play with the gear as it arrives!)
>> > >
>> > > Keeping those quick tests handy is a good idea, too. When things aren’t working and we start to suspect the test gear, it’s really useful to have a set of known-working procedures to run against the instruments. They may also be useful as basic programming examples for lab users to refer to. For instance, that power meter comes with examples for USB and Windows. If we want to talk SCPI/Ethernet and Linux, we will have to translate.
>> > >
>> > > I’m not thinking about accepting users in the sense that they’d have hoops to jump through before being allowed access. There’s no need for that. I just want to provide whatever resources we can in order to make it easy to get started and be productive.
>> > >
>> > > > Side note:  I usually put test equipment on a private test equipment
>> > > > LAN.
>> > >
>> > > That’s pretty much a given, since we have to provide our own access control.
>> > >
>> > > >  If folks need to use the gear remotely, they can remote into the
>> > > > test control PC that is multihomed on the test equipment LAN.
>> > >
>> > > That’s one good way to do it, but it might not always be the best. I’m thinking that a Linux box can do access control and also provide VPN access to the test equipment LAN. I’m prototyping that right now with a Raspberry Pi 4, which may well end up being sufficient for production. Some tests will probably be easier to run on the Pi and some will be easier to run on Windows or whatever else we have.
>> > >
>> > > > Touch screen with gestures?  Sorry, not a fan of touch screens on test
>> > > > gear.
>> > >
>> > > Not so easy to remote a touchscreen, so the feature is pretty much wasted on us.
>> > >
>> > > > But SCPI over telnet works just fine, too.
>> > >
>> > > Telnet! This is why access control is important.
>> > >
>> > >   -Paul