Measurement Control - Direction 2.

There are lots (or you can call nothing) happened since the last post regarding my measurement control application.

Name

I didn't like the random names I gave to this solution (Control software, interface, anything). Didn't look and feel professional. Finally I found a name for it: MeasureFlow

Registered a domain for it:

measureflow.org

(nothing there yet)

A github and a gitlab group:

https://github.com/MeasureFlow

https://gitlab.com/MeasureFlow

Software

I have the direction (partially). The software was plug-in based, but not other ways modular. I decided to architecturally separate the application to frontend and backend. The backend will be dotnet 6 based minimal REST API. The frontend is still question.

Started to write the backend. As the codebase doesn't need too much porting until we just talking about the instrument continuous measurement and not a complex workflow. So it is almost working (just didn't try out the last pieces yet)

Hardware

The ordered PCBs arrived (both the USB-GPIB and the USB-RS232). I was so fortunate in this chip demanding times to find 10 ATMEGA32U4 locally.

I didn't find the time yet to solder and test. Anyway it need firmware, so it is useless until I resolve the firmware related questions.

Firmware

We arrived to the point, what cause most of the troubles to me in this whole picture.

During the last week, in my free time I mostly tried to understand the USBTMC based implementation I found online. I didn't become a big fan of it. No proper reusable implementation of the USBTMC interface what corelate to the LUFA design principles. It is based on a not finished, so fuzzy LUFA demo, bad handling of the AVR pins, weird off interface configuration handling.

Tried to understand, how it is work, how can I port to my hardware. Originally I just wanted to exchange the pin layout for my own hardware design, but I know now, I can't stop there.

Last Sunday then I finally realized the biggest problem I have with this whole thing. What I found was shocking to me. Root of the problems is not the implementation, but the standard itself.

The standardizing board was thinking completely differently than myself.

Their intention: create a solution on instrument side what able to wrap the existing GPIB interface while moving the development to the native USBTMC interface

My intention is to create a device what can sit between the USB and several GPIB based devices, handle sub addresses also.

At first read you may not find too much difference between this two. The difference is that the standard doesn't contains anything to address the GPIB devices. It presume that the USBTMC device with USB488 extension connected to the USB port is a single instrument and not many of it.

If I would just deal with instruments without GPIB sub addresses, I would may live with this, but unfortunately this is not the case. I've VXI mainframes, Power mainframe with GPIB sub addressing.

Even if I dig further neither HP (Agilent/Keysight) nor National Instruments who manufacture USB-GPIB interfaces use USBTMC with USB488 extension in their devices (HP 82357B, NI GPIB-USB-HS). They use standard base device USB ID or vendor specific. Those are proprietary.

Back to my unit. Here I should decide, what direction should I chose while developing the firmware of my adapter. Here are a few possible path I can think of:

1. Resume working on my USB-CDC implementation (based on Prologix command set). It has drawbacks like CDC is slower than the USB native bulk endpoints, on the host side I need to port my own driver to the MeasureFlow software, will not be compatible almost any of the existing host side software stacks.
2. Use AR488 firmware. In addition to all of the drawbacks above, I need to implement the subaddressing (or secondary addressing), in their codebase as it still not implemented yet.
3. Mimic HP or NI interface. This is problematic from various standpoints. Lots of USB sniffing, possible copyright issues, etc.
4. Develop a USB composite device - check with poc if Keysight IO library supports this. The concept is to have one CDC device used as control channel (manual device setup, SCPI emulation, etc.). Generate dynamic USBTMC device for each GPIB device (primary and secondary address) based on automatic device discovery or manual setup.

Currently it looks like that the last one is the target, if I not run into unresolvable issues.