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! 

USB-GPIB Interface v2.1

 

This is a small upgrade, bug fix of my previous ATMEGA32U4 based USB-GPIB interface. The previous had some flows. It had collision between the bootloader LED handling and the GPIB signals. Completely mixed up the original Arduino signals to be able to use the interrupt handling of the processor. Also used a full 8 bit port for the data bus to be able to read/write once and not bit by bit.

• For this version I chose a bit different view:
• Try to stick to the original Arduino Leonardo pin configuration as much as I can
• Give up the interrupt handling except for SRQ line
• Kept the 8 bit data bus
• Made it configurable - you can choose between the pin config used by the AR488 project and the 8 bit data bus above (the AR488 version doesn't need custom bootloader)
• Keep the capability of the using the activity LEDs
• Added serial debug port

Later this design will be based on this adding the proper GPIB line drivers. This design is only capable to drive one instrument (maybe good for more, but I rather not try).

The schematic:

The PCB design:

The "exploded" 3D model:

Yes I know that the gender of the connector is not the correct on (but who knows today, what gender is appropriate), but I didn't find 3D model of it and It wasn't so important, just to represent the size for model design.

Here you can find the complete design:

https://gitlab.com/measurementcontrol/gpibinterfacehardware

With this design the number of finished designs in the group is rise to two so here is the time to order the PCBs.

New workshop

Finally it is official. It was a big fight with the bureaucracy at the local municipality to achieve this. I've a new workshop. It will be lot of money and work until I can move in (I expect a few month for this).