Measurement Control - Direction

Things are changing.

When I restarted my instrument control projects, I had a clear path ahead of me. Then I realized a few things, have to rethink the whole project, my view on it.

I found this project: https://github.com/xyphro/UsbGpib

This is exactly, what I need. I'm 90% sure now, that the firmware I developed for my own board is needless (issues can surface, when I try to adopt it to my hardware and software ecosystem, but it is highly unlikely).

My control software has an additional layer above the VISA. I was thinking to eliminate it, but figured out that I have some instruments on hand what uses HID, or proprietary USB based protocol, what I can't put under the VISA umbrella.

I have a big dilemma regarding the future development. I mean the desktop application of the measurement control.

The situation:

In the software development today is everything about the mobile, web and cloud. It is clear, the word is going to this direction. Even myself as a DevOps professional working on cloud based web projects for several years now.

But...

Always this disturbing "but".

But the instrument control in my hand is a bit different. What I see and feel, the instrument control, visualization applications are mainly not built around web technologies. Those are still desktop apps. I don't want to change this. It is more convenient to use this applications, easier to communicate directly with the hardware, etc.

I started to develop it in C# on .NET Framework with Visual Studio using WinForms. This platform where I have the most experience. If I keep my lazy attitude on it, I can keep it this way and just forget my dilemma. Actually I develop it to myself, so I not really need to care about it.

But something is itching in my mind. The technology above is getting outdated. I also use those projects for learning. So the question is: Which direction?

The other driving factor is Linux. Should I create a multiplatform app? For myself, not necessary. If others want also to use it, that is a requirement.

So the options I see now:

• Keep this, continue the development and just forget it?
• Move to the .NET 6, WPF, MVVM to have a never platform? This means no Linux support, the only thing I can hope, that somebody create a usable version of the MAUI on Linux.
• Move to .NET 6, and use some 3rd party UI (Avalonia or UNO Platform, QT, whatever)?
• Just forget the complete C# and .NET ecosystem and move somewhere else?
• Python has PyVISA for instrument control. I not really like Python, and still need to find a UI
• Java has desktop frameworks, but what to do with the instruments?
• Node.js has Electron, but the VISA support libraries questionable.
• Any other direction didn't pop to my mind?

I try to collect (at least partially) the requirements:

• Native desktop application
• Hardware communication (Serial, USB-HID, IVI stack like Keysight IO Library Suite, USB-TMC, etc.)
• GUI elements - Dialogs, Data Grids, Text controls, and most importantly charts
• Pugin architecture (the pugins for the instruments, communication platforms should be handled separately, need to be expandable)
• Network handling
• File system handling

Maybe there are more requirements. These ones I can see now.

So, If you have thoughts on this, please share with me! 

Instrument Control 1. - The Beginning

 Convergence.

This is the word what pop into my mind when I think about this project.

I feel this is the point where my lab building, instrument collection, instrument/interface building and measurement efforts connected together, giving me some higher level capabilities, than the things what I have on hand.

Where this is started?

I was building audio equipment in my childhood. Later when I restarted this hobby, was the plan, to continue to work audio electronics. I was lack of test equipment (had just a dying DMM). I wanted to build instead of buying. This lead me to the digital electronics.

Later I bought lots of equipment. At a point of time, I bought a HP 8903B Audio Analyzer, to be able to draw various graphs on amplifier performance. But the problem is, connecting an XY recorder is an outdated solution. For connecting to a computer, you need an interface. I wasn't happy with the readily available GP-IB interfaces, so my GP-IB interface is born.

Later, I was looking into the available controller software for the HP 8903B, and didn't like it. In addition, I wanted to connect/control my other instrument to a PC, having more ideas than just controlling the audo analyzer. So after a few control experiment, my "Virtual Instrument" project is born.

After two years, with many struggling, restarting and redesign, it looks like the system started to work.

The concept:

I wanted to create something flexible, while it able to use without programming skills. I wanted something can be used for serious measurements, can be used with many of the instruments I have. Compatible with several communication interface types. The whole system need to be use plugins for the future development.

I created a few object types  

Controller:

Something run the show. Starting the measurement series, even providing some base data for the instruments. Currently I implemented these:

- Continuous controller: Just runs the measurements one after the other. This is the usual work scheme most of the instruments, like multimeters.

- Single shot controller: Just run one measurement, then stops

- Variable controller: Can be setup for a series of measurements. It provide a linear or logarithmic dataset. It is originally created with the HP8903 in my mind. In the first trials I used it as a logarithmic frequency source for the integrated sine wave generator

Instrument:

Some device (typically hardware), can measure something. Can consume measurement results from the previous instruments (or controller) in the chain and/or provide measurement results for the next object.

Currently two type of instruments created: HP8903 Audio Analyzer, HP3478A 5,5 digit DMM

The instruments always working in single shot triggering mode. The reason: The controllers above are running the show and not the instrument's internal controller.

Filter:

It is originally designed for filtering, running maths, converting the results. During the development I realized, that similar functions are needed between the instruments also. So I realized that keeping filter plugins separately from the instruments has no added value.

I'll drop the filter functionality and create the filters as instruments.

Target:

Something can display or save the measured results. Currently two target available:

- Digital Display: can display the currently measured data, also provide min, max and average displays, with variable number of digits displayed

- Chart Display: Capable of displaying the measured data in a chart, using multiple series of data, using linear or logarithmic axes (this is not completely ready)

Connections:

Not part of the measurement chain. It is used by the instruments as communication interface. Currently available:

- AvrGPIB - My own GPIB board (on the development I wrote a few articles)

- IVI VISA - The standard instrument interface. I tried it with the Keysight stack and a Keysight USB/GPIB interface. Actually it was quite unstable, so future development is needed

- Serial - It is implemented and not. Actually it is used by the AvrGPIB, but I never tested directly, so it can have problems

So, this is what I have right now. I tested with the HP 3478A:

And later with the HP 8903B:

It is just AC Level measurement, the input directly connected to the output with 20-20000Hz sweep, 1V AC. Actually you can see some error:

Later with some modifications on the graph (still not finalized):

You can see around 2% error. So the instrument need some repair (at least replace of the filter caps).

So I intend to continue the development, adding support for other instruments and I have many improvement idea.

The code is written in C#.Net with Visual Studio 2019. The repository is located here: 

https://gitlab.com/suf/suf-electronics-VirtualInstrument

Anybody like this project, have spare time, some programming knowledge, and willing to help in the development effort, wellcome.