Scope GUI Made Easier

Last time, I assembled a Python object representing a Rigol oscilloscope. Manipulating the object communicates with the scope over the network. But my original goal was to build a little GUI window to sit next to the scope’s web interface. Had I stuck with C++ or even C, I would probably have just defaulted to Qt or maybe FLTK. I’ve used WxWidgets, too, and other than how many “extra” things you want, these are all easy enough to use. However, I had written the code in Python, so I had to make a choice.

Granted, many of these toolkits have Python bindings — PyQt, PySide, and wxPython come to mind. However, the defacto GUI framework for Python is Tkinter, a wrapper around Tk that is relatively simple to use. So, I elected to go with that. I did consider PySimpleGUI, which is, as the name implies, simple. It is attractive because it wraps tkinter, Qt, WxPython, or Remi (another toolkit), so you don’t have to pick one immediately. However, I decided to stay conservative and stuck with Tkinter. PySimpleGUI does have a very sophisticated GUI designer, though.

About Tkinter

The Tkinter toolkit lets you create widgets (like buttons, for example) and give them a parent, such as a window or a frame. There is a top-level window that you’ll probably start with. Once you create a widget, you make it appear in the parent widget using one of three layout methods:

  1. Absolute or relative coordinates in the container
  2. “Pack” to the top, bottom, left, or right of the container
  3. Row and column coordinates, treating the container like a grid

The main window is available from the Tk() method:

import tkinter as tk
root=tk.Tk()
root.title('Example Program')
button=tk.Button(root, text="Goodbye!", command=root.destroy)
button.pack(side='left')
root.mainloop()

That’s about the simplest example. Make a button and close the program when you push it. The mainloop call handles the event loop common in GUI programs.

Continue reading “Scope GUI Made Easier”

How To Talk To Your Scope

It used to be only high-end test equipment that had some sort of remote control port. These days, though, they are quite common. Historically, test gear used IEEE-488 (also known as GPIB or, from the originator, HPIB). But today, your device will likely talk over a USB port, a serial port, or a LAN connection. You’d think that every instrument had unique quirks, and controlling it would be nothing like controlling another piece of gear, especially one from another company. That would be half right. Each vendor and even model indeed has its unique command language. There has been a significant effort to standardize some aspects of test instrument control, and you can quickly write code to control things on any platform using many different programming languages. In a few posts, I will show you just how easy it can be.

The key is to use VISA. This protocol is defined by the IVI Foundation that lets you talk to instruments regardless of how they communicate. You do have to build an address that tells the VISA library how to find your device. For example: “TCPIP::192.168.1.92::INSTR.” But once you have that, it is easy to talk to any instrument anywhere.

I say that thinking it is a problem is half right because talking to the box is one task of the two you need to complete. The other is what to say to the box and what it will say back to you. There are a few standards in this area, but this is where you get into problems. Continue reading “How To Talk To Your Scope”

Hackaday Prize 2023: Over-the-Top Programmable Resistor Looks The Part And Performs

Every once in a while we get wind of a project that we’re reluctant to write up for the simple reason that it looks too good to be true. Not that projects need to be messy to be authentic, mind you, but there are some that are just so finished and professional looking that it gives us a bit of pause. [Sebastian]’s programmable precision resistor is a shining example of such a project

While [Sebastian] describes this as “a glorified decade resistance box,” and technically that’s exactly right — at its heart it’s just a bunch of precision resistors being switched into networks to achieve a specific overall resistance — there’s a lot more going on here than just that. The project write-up, which has been rolling out slowly over the last month or so, has a lot of detail on different topologies that could have been used — [Sebastian] settled on a switched series network that only requires six relays per decade while also minimizing the contribution of relay contact resistance to the network. Speaking of which, there’s a detailed discussion on that subject, plus temperature compensation, power ratings, and how the various decades are linked together.

For as much that’s interesting about what’s under the hood, we’d be remiss to not spend a little time praising the exterior of this instrument. [Sebastian] appears to have spared no expense to make this look like a commercial product, from the rack-mount enclosure to the HP-esque front panel. The UI is all discrete pushbuttons and knobs with a long string of 16-segment LEDs — no fancy touch-screens here. The panel layout isn’t overly busy, and looks like it would be easy to use with some practice. We’d love to hear how the front and rear panel overlays were designed, too; maybe in a future project update.

This honestly looks like an instrument that you’d pay a princely sum to Keithley or H-P to own, at least back in the late 1990s or so. Kudos to [Sebastian] for the attention to detail here.

Screenshot of a terminal showing the HELP command in action - outputting descriptions of other commands

Let’s Make SCPI More Helpful

The SCPI (Standards Command for Programmable Instruments) protocol is exceptionally popular in lab and workspace tools, letting you configure and fetch data from oscilloscopes and lab scales alike in a standardized way. However, when interfacing with a SCPI device, you need to use a programming guide document if you want to know the commands for any of the inevitably extended features; essentially, SCPI isn’t as human-friendly as you might want. [MisterHW] argues that SCPI could use more discoverability by proposing a HELP? command.

This proposal is so intuitive, it makes you wonder why it isn’t in the base spec. It adds a built-in command that provides information on other commands. Internally, the description is just an extra string parameter that you add to your command definition code, and you can use it to describe the parameter types and ranges it takes. The output is both human-readable and machine-parseable, and as it’s stored within your code, it’s way quicker to update the description string than it is to re-release programming guides. Which are themselves prone to being outdated as-is, so decreasing reliance on them is a win-win.

The proposal makes a lot of sense, and [MisterHW] is willing to back it up with a pull request to the most popular SCPI library, libscpi. Whenever the pull request finally goes through, you will have the option to easily add the HELP? command support to whatever SCPI-connected device you might have brewing.

While the old devices will eventually fade, SCPI is not about to die out – hackers keep building devices with SCPI as the communication protocol, as the spec is quite powerful. For instance, here’s this fancy temperature logger, or this Source Measurement Unit – both of them use SCPI for hacker-to-device data transfer, and it’s likely to be libscpi under the hood. Ever wondered what SCPI is all about? Check out our overview!

USB Temperature Logger With Some Extra Tricks

Many of us electronics hacker types tend to have at least the same common equipment on our benches, namely a multimeter, an oscilloscope, some sort of adjustable power supply, and maybe a logic analyzer. These are great tools covering many bases, but dealing with temperature measurements is often neglected. A sudden need for such often results in just buying a either dedicated measurement unit, or some cheap eBay thermocouple board and just rolling with a few hacks. [Jana Marie Hemsing] had a need for measuring the thermal side of things, and got fed up with hacking with piles of boards, and designed herself a proper instrument for the task.

The result is a very tidy four-channel thermocouple frontend, feeding the data into the host computer via USB. Each of the four channels can either be a K-type input or a NTC thermistor input, decided at board assembly time, but you could just build two units with four channels of each and cover all bases. The K-type thermocouple input is based around the MAX31855 series device. While the ‘KASA’ suffixed device is probably most common, if you need to dedicate some channels to handling one of the other six or so other common thermocouple types, that just needs the appropriate MAX31855 variant dropping in, and you’re good to go.

For the controller, [Jana] has chosen the common STM32F0x microcontroller, which handles all the USB protocol side of things. The extra functionality added allows direct driving of a heater controller via the DRV8837 H-Bridge, with a extra few open collector outputs for other things you might want to drive. This allows the logger to function as a kind-of thermal IO device. Firmware is written in good old fashioned STM32 HAL, using the standard STM32CubeMX and the GCC toolchain. It looks like the Makefile came via the STM32 Project Generator route. The firmware has a neat trick up its sleeve too; with a flick of the switch on the back, the firmware can switch between outputting CSV data over a standard USB CDC link (a virtual serial port), or it can present a SCPI terminal interface, enabling integration into existing SCPI-based test flows. Nice work!

We’ve seen a few logging projects on these fair pages, like this battery powered ESP32 logger device. If IoT logging is more your thing, here you go.

Open Source LXI Tools Free Us From Vendor Bloat

LXI, or LAN eXtensions for Instrumentation is a modern control standard for connecting electronics instrumentation which supports ethernet. It replaces the older GPIB standard, giving much better performance and lower cost of implementation. This is a good thing.  [Martin Lund] has created the open source lxi-tools project which enables us to detach ourselves from the often bloated vendor tools usually required for talking LXI to your bench equipment. This is a partial rewrite of an earlier version of the tool, and now sports some rather nice features such as mDNS for instrument discovery, support for screen grabbing, and a LUA-based scripting backend. (API Link)

SCPI or Standard Commands for Programmable Instruments is the text-based language spoken by many instruments, allowing control and querying of an instrument. Just to be clear, SCPI is not at all a new thing, and older instruments that have GPIB or RS232 connectors, still could talk SCPI. lxi-tools is not for those. Some instruments can also be very picky about the formatting of commands, especially if they’re buggy, so the ability to interactively debug commands is very desirable. It is quite possible to make poor use of SCPI commands in your test script and end up with tests that just take far longer to execute that they need to. lxi-tools has a benchmarking tool too, which helps you to dig in and find out where all the time is going and make suitable adjustments.

We’ve not seen much about LXI on Hackaday, but we did cover using PyVISA for dealing with SCPI-over-GPIB in python.  If you have an older instrument  with GPIB and you don’t want to sell a internal organ to pay for a USB adaptor, here’s one you can make yourself.

Hackaday Podcast 146: Dueling Trackballs, Next Level BEAM Robot, Take Control Of Your Bench, And Green Programming

Postpone your holiday shopping and spend some quality time with editors Mike Szczys and Elliot Williams as they sift through the week in Hackaday. Which programming language is the greenest? How many trackballs can a mouse possibly have? And can a Bluetooth dongle run DOOM? Join us to find out!

 

Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download (52 MB)

Continue reading “Hackaday Podcast 146: Dueling Trackballs, Next Level BEAM Robot, Take Control Of Your Bench, And Green Programming”