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

[Michelle Thompson]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20201104/94f8e047/attachment-0001.html>