USA Cal Club: Round 2

[bitseeker]

I just looked at the data after switching to the Uno from the kit.  I don't see any glitches.  I *should* have made note of when I changed over, but did not.  But I'll know in the morning.

It's entirely possible it was EMI, but the regularity makes that difficult to believe.  If it is not resolved before I send the kit back, I'll send the Uno I programmed along with the original so if the glitch reappears it's just a board swap to test the software change and we don't have to deal with different compiler versions, etc.

It could be a problem with the IC. Did you change the 328 or the whole board? If the latter, there could be something going on elsewhere on the board, too.

I think it's very important that until we resolve the actual cause we do *not* modify the FW on the Uno @bitseeker was using.

Agreed. Otherwise you don't know for sure what fixed it.

[rhb]

Sigh...   No joy.

No glitches all night.  I swapped another board I had on  an acrylic base with plastic feet for the attempt at fixing it.

I'm going to drop the Tempduino effort for now and focus on the cal work.  I'll build a Tempduino replacement in a nice case with in transit logging to an SD card after I send the kit back out.

[TiN]

Regarding measurements - I never had 3478A and had 34401A only for few days to do a calibration/repairs for people.
I'm not familiar with PX loading behavior, but for FX it's no problem to drive multiple meters at once, it can source/sink up to 25 mA (however I'd say use High-impedance mode on meters, when available just in case).
You'd want to run separate set of wires from each DMM to the FX terminals. I usually log at least 5-6 meters at once, so when one (or two) start acting funny, others can reveal that business.
Log at least a day of data to see stable readings, so one can determine stability figures. Usually best bet to use highest NPLC, maximum resolution and fixed 10V range. Keep azer enabled, make sure mains frequency is correct.
Use high-quality copper wiring to reduce thermal EMF effects (no need super-pupper fancy cables, just twinaxial piece of LAN UTP cable, with freshly cut and cleaned ends will do great).
After you done, upload CSV to FTP, I'll run a graph python to plot some wonky lines.

[rhb]

TiN Thanks.  I did a daisy chain, so I'll redo it.

My main problem right now is that something on the Windows system I'm using has loaded python 2.7, but it doesn't appear in the list of installed programs.  I've got 3.7.4 installed and I see that, but Cygwin wants to use 2.7. 

Sigh..  It just sank in that Cygwin is the culprit.  Time to shutdown Windows and start Debian.  I'll sort out fixing Cygwin some other time.

[bitseeker]

Sigh...   No joy.

No glitches all night.  I swapped another board I had on  an acrylic base with plastic feet for the attempt at fixing it.

I'm going to drop the Tempduino effort for now and focus on the cal work.  I'll build a Tempduino replacement in a nice case with in transit logging to an SD card after I send the kit back out.

Yeah, that graph looks wonderful. Thanks for digging into it. Perhaps we should see if anyone else runs into the same glitches. If not, then either it's something in my environment or a problem that might be caused/fixed during shipping (bad solder joint?).

[rhb]

After considerable confusion on my part I am now able to talk to both my 34401A DMMs using putty and the Twilight-Logic board.  I'd bought a GPIB-USB dongle on Amazon, but could not get it to work and returned it.  So I have *no* experience reading data via GPIB.

I *really* need a  logging program for a pair of 34401As and a pair of 3478As if anyone can point me to one.  I'll feel terrible about delaying sending it to the next person if I have to write one myself.

If I can just get the data in files with timestamps I can massage it with awk and generate all manner of plots with gnuplot.  But without an RTC on the Tempduino I'm unsure how to do that. 

I've got EZGPIB installed on a Windows 7 system, so I can use that if needed, but I am *much* more comfortable on Debian.  It sort of behaves like Unix.

Edit:  I'll be sending out a spare Uno with the modified code installed  just in case it's an intermittent  HW fault

Edit2:  I've got it sorted using awk.   Piece of cake, which is why I never learned python.  I need to hack the
Tempduino code a bit, but that's all.

[bitseeker]

Replied to your PM with the SCPI codes to configure and get readings from the 34401A. Not sure if you still needed that, but it's there in case you do.

I haven't programmed a 3478A yet (mine are in the repair queue), so I'm not sure how different it is. Interestingly, the 34401A has a 3478A compatibility mode. So, in theory, you could treat all four DMMs as 3478A. I wonder if you'd lose a digit on the 34401A by doing that.

[Andreas]

I *really* need a  logging program for a pair of 34401As

All you need is a terminal program a serial interface and setting the GPIB-Adress to 31 on the 34401A. (Printer mode according to handbook).
Note that you will have a cable with crossed RxD and TxD lines for the serial interface.

With best regards

Andreas

[rhb]

It had been so long since I got serious with awk that I forgot about the rather odd semantics of writing to files.  This works with the Twilight-Logic GPIB board on Debian 9.3.  I spent a long time chasing my tail before I remembered the weird bit about needing to close files so that they get reopened.   Otherwise you get the same value every time even though it has changed.  A pipe has the same semantics. 

Code: [Select]

#!/usr/bin/nawk -f

BEGIN{

     system( "stty 9600 </dev/ttyUSB0" );
     system( "stty 115200 </dev/ttyUSB1" );


     for(;;){

        system( "/bin/date +%s >/tmp/a");
        system( "/usr/bin/head -1 /dev/ttyUSB0 >>/tmp/a");

        getline sec <"/tmp/a";
        getline th <"/tmp/a";
        sub(/\r/ ,"" ,th );
        close("/tmp/a");

        print "++addr 10" > "/dev/ttyUSB1";
        print "read?" > "/dev/ttyUSB1";
        getline dmm10 < "/dev/ttyUSB1" ;
   
        print "++addr 22" > "/dev/ttyUSB1";
        print "read?" > "/dev/ttyUSB1";
        getline dmm22 < "/dev/ttyUSB1" ;
   
        printf( "%s,%s," ,sec ,th);
        printf( "%s,%s\n" ,dmm10 ,dmm22);
     }
}


the output looks like this:

rhb@Debian-9:~/wrk/cal-club/34401A$ ./tst2
1563661854,24.691,48.824,+1.00001120E+01,+9.99993960E+00
1563661858,24.722,48.824,+1.00001160E+01,+9.99993840E+00
1563661862,24.735,48.811,+1.00001110E+01,+9.99994090E+00
1563661866,24.722,48.827,+1.00001140E+01,+9.99994460E+00
1563661870,24.717,48.849,+1.00001160E+01,+9.99994090E+00
1563661873,24.699,48.853,+1.00001170E+01,+9.99994330E+00
1563661877,24.685,48.859,+1.00001170E+01,+9.99994090E+00
1563661881,24.662,48.863,+1.00001170E+01,+9.99994210E+00

The first value is the time in seconds from the start of the Unix epoch.  I'm using the Uno I hacked rather than the one that came with the kit.  I've been careful not to modify it.

I need to get a bunch of FTDI USB-Serial adapters for reading data from DMMs and save the GPIB for other instruments.

I notice that the GPIB-USB interface is returning 8 digits.  Can anyone shed light on that?  It appears to be the string returned by the 34401A.

Many thanks to all, but especially to cellularmitosis, vindoline and TiN for making this possible.

After 4 straight hours of tearing my hair out I'm going to take a break.  But with modest luck I should be able to test my 4 DMMs, do  differential tests with the references from Doug Malone and get the kit back in the mail on Wednesday.

Once it's in the post I'll write up the scripts and stuff.  My sister is very proficient at making booklets on the computer, so I'm going to sit down with her and show her what to include from bitseekers links.  I'm sure we can do better, but it will be a start.

Reg

[bitseeker]

The DMM is integrating over 100 power line cycles, so you get additional resolution. However, depending on the amount of noise included in the signal, the extra data may or may not be useful.

[rhb]

I'm planning on doing a bunch of noise analysis of the temperature logger once I recover.  That's fairly simple as one can readily estimate the physically possible temperature fluctuations.

Voltage measurement noise is a lot harder.  I'm sure I can estimate age related drift really well if I can ever get data, but short term noise is a whole other ball game.

[maxwell3e10]

Regarding data logging, I have found several available serial loggers helpful:
https://bitbucket.org/hyOzd/serialplot/src/default/  - nice logger with real-time plotting and logging but no time stamping so far
https://www.compuphase.com/software_termite.htm  - good for interactive debugging and logging to file with a time stamp
https://sites.google.com/site/terminalbpp/ - also can do logging and timestamping plus execute macros repeatedly

The AR488 USB-GPIB program also can execute macros repeatedly or perform continuous reads.

So for continuous logging one can often find a way to do it without having to write an actual program.

[rhb]

I powered off the bench yesterday once I had everything working as I was too tired to continue.  This morning I made a new cable to connect both DMMs per TiN, hooked it up and powered up.

No workee!!!!!

The part that gave me trouble yesterday, the Tempduino works just fine.  But I can't read data from either meter.

If I use putty and the GPIB-USB interface *IDN? causes an error on the front panel and does not show the device but *CLS clears it.  I've been through all the menus checking that everything is set properly.

So, what was working doesn't and what wasn't working does.

The fact that I can select a meter, and the unit beeps and sets the error light in response to *IDN? without returning a string to putty but *CLS clears the error has me utterly baffled.
 
On one unit *IDN? clears all the digits but READ? restores them, but without returning anything to putty.  The other unit also sets an error on *IDN?, but does not blank the digits.  In both cases *CLS clears the error light.

[TiN]

Stupid question but why turning off the power on the bench? References for sure hate that! Fluke 732's shipped and transit with backup battery exactly for the reason of uninterrupted power.
I'd start with obvious - check the cables, make sure all GPIBs screwed down firmly, power cycle the meters, make sure addresses are all correct, and line termination are set right.

Issues like this are the reason why experienced *nuts prefer to use industry standard more expensive interfaces like NI or Agilent or GPIB-LAN bridges.
Yes, they cost much more than some one-off-DIY-cheap-PIC-adapter, but save your hair on the head and sleep at night.

[MaxFrister]

I don't know anything about the Twilight-Logic GPIB-USB-serial interface" so what I am about to say is generically about GPIB interfacing instruments.

Individual instruments. Each must be set to different GPIB address.  On newer instruments this is set via the UI, older ones required switches to be changed.

Cabling.  The GPIB cable is a big fat parallel cable.  Instruments can be connected in any topology, star, daisy-chain, misc.  Cabling is used to interconnect instruments.

GPIB to computer connection.  There are various kinds including cards that install in a computer or GPIB-to-usb converters.  I've had good luck with a probably counterfeit agilent 82357B one.  Unless you want alot of complications, only use one GPIB interface per computer.

GPIB driver.   Each hardware GPIB interface requires a (different) software driver.  The main ones I have used have been the National Instruments and HPAK.  I recommend the NI one.  Note that various home-brew GPIB interfaces will require their own drivers.

Warning.  Both NI and HPAK by default install GIGABYTES of software that you can not *ever* uninstall and are incompatible with each other.  Don't let them.  Install only the parts you need. 

Testing. For testing I use the "keysight connection expert" (but the NI GPIB driver).   Start the software with the test instrument turned off.  Then turn it on and refresh.  Your instrument should appear in the software.   This will confirm that the GPIB address is what you expect and that the cables are connected.   Try sending "*IDN?" and reading the result.

Logging software.  You need something on the computer that sends commands to and reads data from the various instruments.  TIN and others have published very good logging "frameworks".  I just write very short and simple python scripts that use the Py-VISA library and log to a CSV file.

[rhb]

Line termination?  Please explain.  Having had to kill a goat or two to get SCSI to work I was wondering about that.

I just cleaned all the flux residue from the board in hope it might be that as it is *very* humid here.  No joy.

I've reseated the cable and tried moving the GPIB-USB to the other end.  It worked yesterday with no issues. I hooked it up, added myself to the dialout group, installed putty and except for one meter which was set for RS-232 had no issues with reading data.  The time, temperature and humidity beat the bejeezus out of me, but getting data from the DMMs was not a problem.

I can talk to the units, but they are unable to reply for some reason.  Unfortunately, I don't know the electrical details of the GPIB interface.  The only time I *ever* worked with it was the serial version of IEEE 488 used  on the Commodore 64 which was a *very* long time ago.

IIRC I bought a handful of cheap RS-232 interfaces, but have never tried them to see if they work.

The bench is setup so that certain power feeds stay on and the rest are powered off.  This is for general safety and to in particular to protect CRTs from burning.  Doing it yesterday was a bad idea but I was exhausted and not thinking very clearly.

[JXL]

Verify puTTY communication with the USB-GPIB interface is working by typing "++ver" which should return the version of the firmware.  You may have to type <ctrl>J instead of <Enter> to allow puTTY to send <LF> to the interface.

Make sure the above works, and after you send "*IDN?", your meter should respond.  You have to type "++read" to get the response from the interface, or set automode ("++auto 1") to have the interface automatically issue a gpib read command.

Hope this helps...

[rhb]

Yeeha!!!!

"++auto 1" was the missing incantation.  I had done that manually early in fiddling with the GPIB-USB device.  After 4 hours of fighting lovely entertainments like '\r' and the odd business that awk is not nawk (which I'm used to in the Solaris world) and that I had to close the temporary file where I was storing the date, temp and rh, I'd completely forgotten about "++addr 1".

rhb@Debian-9:~/wrk/cal-club/34401A$ ./tst2 | tee tst2.log
1563747834,23.618,53.234,+1.00001100E+01,+9.99992850E+00
1563747838,23.615,53.195,+1.00001070E+01,+9.99993100E+00
1563747842,23.608,53.167,+1.00001060E+01,+9.99992850E+00
1563747846,23.600,53.143,+1.00001100E+01,+9.99993100E+00

@JXL I owe you a *lot* of favors.  I was on the verge of giving up and falling back to the end of the queue to give me time to sort out the problem.  I was feeling terrible about delaying the cal kit while I sorted out issues I should have resolved beforehand.  I was quite surprised to learn I was the next person after @bitseeker and almost asked for a delay.

NB for those not aware of it, nawk does not strip '\r' when it reads a string.  You have to do that manually with "sub( /\r/ ,"" ,str );"  If you don't if you "printf( "%s,%s\n" ,str ,next_str );"  all you will see is next_str.  The '\r' will rewind and you'll print next_str over the top of str.  It's one of those rare and obscure things you run into if you're dealing with both Windows and Unix centric hardware and software.  I've run into it less than a dozen times in 30 years of Unix.  It's *very* easy to overlook and it will make you crazy, especially in conjunction with the need to close a file so it will reopen.

[vindoline]

rhb, I'm glad you've got the GPIB adapter sorted.  It looks like you're making great progress! Please don't feel under pressure to finish and send the gear on. Take the time you need to learn and do the measurements that you would like, calibrate your meters, etc. It could be a while before the kit comes around again!

[vindoline]

Yeeha!!!!     "++auto 1" was the missing incantation.

For what it's worth, you can set "auto 1" as default in the AR488.ino firmware for the USB-GPIB adapter. It's pretty simple to do via the Arduino IDE.

[vindoline]

I was on the verge of giving up and falling back to the end of the queue to give me time to sort out the problem.  I was feeling terrible about delaying the cal kit while I sorted out issues I should have resolved beforehand.  I was quite surprised to learn I was the next person after @bitseeker and almost asked for a delay.

I don't want anyone feeling stressed about their time with the club kit! If your time arrives and you're not ready for whatever reason, we can swap your spot with the person behind you in line. Also, please feel free to take the time you need to familiarize yourself with the kit and take the measurements that you would like. It's a long wait for your turn and you should have the time to explore, learn, and have fun.

[rhb]

I feel as if Rod Serling is standing somewhere around the corner smoking a cigarette...

Now *cls produces a -420, Query "UNTERMINATED" error and turns *on* the error indicator.  Which I can clear with the  syst:err? command.

You can store the desired configuration in the AR488, so no need to change it in the source.

Were it not for @JXL I think I would have completely lost it today.

I've put everything on hold while I get this working.  And I'm leaving it all running even though I'm not logging data tonight. My initial script was generating errors and I don't consider that acceptable even if it appeared to be working.

I should be able to put together something which is portable across any system which can talk to the AR488 and which can be configured to talk to any DMM.  I only have the 34401A and 3478A, but those have different command sets, so by the time I accommodate both of those adding another DMM should just require describing the commands for that meter.

In addition to the data logging, I'll add plots and data analysis using gnuplot.  Though that will probably not get finished until after I send the kit back.

I'm quite amazed by the 34401As.  The older, heavily used one reads 60-70 uV below 10 V and the newer, almost unused one reads 110-120 uV above 10 V.

[rhb]

What is the correct setup for the 34401A?

As I read the manual I want to send the meters the following SCPI commands before I start collecting data.

INPUT:IMPEDANCE:AUTO ON
SENSE:ZERO:AUTO ON
SENSE:VOLTAGE:NPLCYCLES 100
SENSE:VOLTAGE:RESOLUTION MAX

Should I also set?

SENSE:DETECTOR:BANDWIDTH 3

Is there anything else I've overlooked?

Thanks,
Reg

[rhb]

FWIW I had given up for  the day.  But decided to have one more go at it before turning in.

The AR488 was not working even from putty, so I power cycled the AR488.  Much to my immense relief, it is now logging time, temperature, humidity and voltage for my pair of 34401As.

No idea at all what the problem was, but at the moment I'll settle for getting my calibration done.  I'll find out what the issue was and fix it later.

Reg

[MaxFrister]

Oddly enough I was just reading about this in the manual.  I think resolution is a measurement of the smallest size.  Here is what it says:

"Specify the resolution in the same units as the measurement function, not in number of digits. For example, for dc volts, specify the resolution in volts. "

and provides the example:

MEAS:CURR:AC? 1,1E-6                      6-1⁄2 digits on the 1 A range

I think you also need to set the range explicitly.  This sets both the range and resolution:

Sense:Voltage:DC:Range 10, MIN