Keithley 2001

 I bought a Keithley 2001 DMM 1,5 years ago. It has a problem: calibration lost.

Tried to extract the contents of the calibration EEPROM, unsuccessfully (finally I realized, that the type I configured on the TL866 was different, so I'll never know if the EEPROM was faulty or not), so I exchanged it to a new one. This time I also added a socket to it, so it will be easier to exchange next time.

Also burned a set of new EPROMs with the latest firmware available.

Added the Dallas NVRAM option. Later realized, that a cheaper, better option would be available:

https://www.youtube.com/watch?v=upTgM_S5rAQ

Next time!

As you see the range down button is broken. Also time-to-time some buttons are stuck, when pressed.

Ordered a new front panel button set (https://pakahuszar.blogspot.com/2022/01/new-arrivals-2.html) and replaced it.

The multimeter looks up and running, except the calibration. I'm looking for a service to recalibrate it.

New Arrivals 2.

As I planned, continue the new arrivals series

Keithley buttons

I've a Keithley 2001 multimeter. It had some issues with the front panel buttons. One broken, a few others stuck a bit when pushed. I ordered it long time ago. Unfortunately they sent a set for the 2000 one, what has different button labels.

As I also have Keithley 2000 multimeters I kept that one as spare part and reordered once again. Finally the correct one arrived.

I just bought a few J107 J-FETs, nothing interesting in it as such. I'm planning a rather interesting project with those what intend to solve one of my old electronics puzzles in my head.

Also bought 2A 6.3x32 fuses for the new power inlet module in the E1300A.

I made a mistake here. I checked the fuse holder in the old module, but the new use 5x20 fuses:

Keithley 2010 / HP 34401A

This was a local catch. Found a Keithley 2010 and a HP 34401A multimeter locally. Fortunately below the eBay prices. Had not enough time to test them yet. But the first tests looks promising.

New arrivals 1.

I decided to write a "mailbag" like posts.

Here is the first one.

What arrived recently.

As I wrote previously, the mains inlet of the E1300A VXI mainframe blown. The replacement arrived. Unfortunately I got one out of the ordered two. I plan to install it in the next few days.

The boards for the USB-RS232 and the new USB-GPIB arrived. Not yet know, when can I build from it.

A local catch. I bought a "few" Kingbright 15x15mm four element LED bars. Altogether more than 500pcs. It was around ¢15 each. I don't have too much idea what to build from it yet (just some cloudy ones).

This is for this week (I intend to continue on the next)

HP E1300A - EPIC Fail

In the last few days I was working on my instrument control software. I wanted to test, what I achieved with an SCPI compliant device also (now I mainly use my Keithley 199 DMM for the tests).

The first SCPI compliant device I found around is a HP E1300A B-size WXI mainframe with DMM and switch cards (I've three of this).

First I wanted to clean it up, repair if it necessary.

(Read further, text continue after the first set of pictures)

Everything is clean, the dead battery pack exchanged to a battery holder. The only thing still need exchange the old Papst fan. Actually the same fan still in production but it cost insane $60 (I got the two E1300A units as a gift, and bought my first one for  $15). This one if it is new has 36dB noise level. I found a Noctua model, with the same airflow 17dB noise level. I know it is not the "industrial" one, but the unit will be lightly used in my lab, so it will be good enough. Even the fan isn't installed yet.

Just for the try switched on the unit connected a GPIB adapter and checked if I can communicate with it. Looks everything fine after assembly.

Switched off the unit and went to the bathroom. I hear some weird noise from there. Went back to my room. Thick smoke coming out from the switched off unit and stinking like hell. Pulled out the mains cable and didn't understand what happened.

Disassembled the whole unit once more:

The filter in the mains outlet blown.

At least this indicate, that probably the unit itself doesn't has further issues as result of this failure.

New outlet ordered, I'll finish the assembly when arrived.

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).