Dumping and restoring the CAL RAM of an HP3457A

[dl1640]

My one has calnum? 34, but I dont know how to see the last caldate.

[maxwell3e10]

Calnum increases by one for each calibration point. I believe 34 corresponds to one complete calibration procedure, on my meter the calnum is also 34. It means the meter was just calibrated once when it was made.

[hazzer]

If you get a chance - a quick Q...
I now have the prologix adaptor - when I run the memory_dumper_3457A.exe (on a windows7 32bit laptop) I can see data fill the window and at the end the prog crashes with an error "Index was outside the bounds of the array".
Interestingly I get the same data to appear irrespective of the GPIB address set in in the utility.
I think I'm missing something here ....

Will start by reading the prologix manual... 

[hazzer]

Worked great, awesome to have the cal data backed up from my 3457A......

hazzer

[0xfede]

Worked great, awesome to have the cal data backed up from my 3457A......

hazzer

Hi hazzer,

so you succeded in dumping the CAL RAM?
Do you mind sharing the content?

Thanks in advance,
0xfede

[maxwell3e10]

hazzer,

I am curious what you did between your first and second message. I tried the program using Arduino emulator of the Prologix adapter and it behaves as you described in the first message. It sends the correct commands to the meter, but doesn't seem to get anything back. Manually I can get the same commands to return results from the meter.

[dl1640]

5  TRIG 4
10 FOR I = 64 TO 512 STEP 2
20 PEEK I
30 NEXT I

are these all we need to dump the content of CALRAM?
if so i will try to use my NI USB-GPIB to talk to the meter. 

[0xfede]

5  TRIG 4
10 FOR I = 64 TO 512 STEP 2
20 PEEK I
30 NEXT I

are these all we need to dump the content of CALRAM?
if so i will try to use my NI USB-GPIB to talk to the meter. 

It is just easy as that. The only thing left to do is to reorder data since each couple of bytes is packed in the response.

Best,
0xfede

[dl1640]

0xfede

i had trouble by sending "TRIG 4", it returns err.16
so i send "TRIG HOLD", it worked.

i attached my dumped CAL constants, FYI.

(i dont know how to re-order them by now)


EDIT:

I think my 3457 GPIB circuitry has some intermittent issue, so "TRIG 4" should work.

[sipo75]

I will add my dump. Will the dump work with this ROM version?

03457-88804 REV 4 WYLE LABS

[0xfede]

Probably it would not work. I think you have the older mainboard, sorry.
Nevertheless you should be able dumping it just by peeking between 0x5000 and 0x57FF:
5  TRIG 4
10 FOR I = 20480 TO 22528 STEP 2
20 PEEK I
30 NEXT I

Best,
0xfede

I will add my dump. Will the dump work with this ROM version?

03457-88804 REV 4 WYLE LABS

[sipo75]

Does this dump look plausible?

[Grippy]

Well I'm not sure if It's the right backup but here's my similar dump, also of a 03457-88804 REV 4 WYLE LABS ROM Version.

Also here's some horrible (but working) python code to dump a memory address range over GPIB. It should work independent of the cable, I tried both a National Instruments and an Agilent one. It does require some Python dependencies and also the National Instruments VISA back-end (all available online for free)

You just need to change the address to your GPIB address in the first few lines since I didn't add a prompt for it.

Code: [Select]

#HP 3457A Arbitrary Memory Dumper
#Andrei Aldea 2018
#Asks for Beginning and End Adress in Decimal to Read
#Reads twice, does MD5 checksum of the two files created and tells user if they match

import visa
import time
import hashlib
rm = visa.ResourceManager()
inst = rm.open_resource('GPIB0::22::INSTR')
inst.write('TRIG 4') #Freeze instrument so we can read from it

def peek_memory(f):
    for x in range(int(start_adress),int(end_adress)): #OR 64 to 512 for older ROM versions? 20480 to 22528 for newer

        try:
            the_str = "PEEK " + str(x) 
            print(the_str)
            inst.write (the_str)
            data = inst.read_bytes(14) #Read data 14  bytes at a time... ~ what the insrument returns
            #NOTE: Instrument always returns Engineering notation... so convert to  float then Int... 'cause why not.
            string_data = str(data).partition("'")[2].partition("'")[0] + '\n' #Split weird formatting and add a newline
            f.write(str(x) + ": " + str(int(float(string_data))) + "\n") #Write it's float equivalent to disk
            print(str(string_data) + " Or Decimal: " + str(int(float(string_data)))) #Print what was written
            pass
        except:
            print("Couldn't read after " + the_str)
            f.write("THIS IS BROKEN")
            f.close()
    f.close()

#Function to Get MD5 Sum
def md5(fname):
    hash_md5 = hashlib.md5()
    with open(fname, "rb") as f:
        for chunk in iter(lambda: f.read(4096), b""):
            hash_md5.update(chunk)
    return hash_md5.hexdigest()

inst.write("ID?") #Ask the instrument what it is
print((str(inst.read_bytes(9)).partition("'")[2].partition("'")[0].partition('A')[0] + " Detected")) #Print instrument response

start_adress = input("Memory Start Adress (64 or 20480 reccomended): ")
end_adress = input("End Adress(512 or 22528 recommended, 65535 max): ")

#First Checksum

fname_1 = "3457_DUMP_" + str(int(time.time())) + ".txt"
f = open(fname_1, "w")
peek_memory(f);
checksum1 = md5(fname_1);

#Second Checksum
fname_2 = "3457_DUMP_" + str(int(time.time())) + ".txt"
f = open(fname_2, "w")
peek_memory(f);
checksum2 = md5(fname_2);

if(checksum1 == checksum2):
    print("Success!");
else:
    print("FAILED. MD5 Sums of Two Reads do not Match!")
    print(fname_1 + " MD5: " + str(checksum1))
    print(fname_2 + " MD5: " + str(checksum2))

Also changed the battery while I was at it... hopefully didn't lose Cal constants...

[ipqobk]

Hi, I tried to make a dump on my 3457A that uses the firmware and the board that I attach in photos, I use the PROLOGIX interface and HP3457A Memory Dumper.zip (Thank to 0xfede), I often have difficulty doing it with win10-64b where it goes wrong when saving the file , with win10-32b it makes the rescue regularly. The multimeter has the firmware 03457-88810 Rev2 (If someone interested I have the .bin of the eprom).
I noticed that if I do more 'dump and compare the content is different, only some parts match, do you have any advice to give me?

Best regards,
Paolo

[ipqobk]

When use the Memory Dumper on Windows 64bit this is the error that appears and what 'appears in the window of the dumper, later' I try to do the same reading on another pc always with win 10/64bit, Paolo

[ipqobk]

This is the comparison of the three dumps with win10 / 32bit

[ipqobk]

Now I tried to read the contents of the ram with Grippy's Arbitrary Memory Dumper (Thanks' Andrei Aldea), with Python 3.7.2 and VISA with the USB GPIB adapter F8235 from Beiming Technologies (nightpanda made it, compatible HP 82357) and windows10 / 64, I made two consecutive dumps that are identical.

[bingo600]

Now I tried to read the contents of the ram with Grippy's Arbitrary Memory Dumper (Thanks' Andrei Aldea), with Python 3.7.2 and VISA with the USB GPIB adapter F8235 from Beiming Technologies (nightpanda made it, compatible HP 82357) and windows10 / 64, I made two consecutive dumps that are identical.

Any pointers to nightpanda's work ?

/Bingo

[ipqobk]

nightpanda I believe is the owner of Beiming Technologies (bmjd.tech) that has realized the interface F8235 USB <> HPIB compatible with the HP82357 (https://groups.google.com/forum/?fromgroups#!forum/gpib-usb ), which I purchased around 2013/2014 and which I use to communicate with my instruments, as well as a prologix and an NI PCI-GPIB 488.2

Paolo

[pomonabill221]

I have the NI GPIB-USB-HS adaptor.  Will your wonderful utility use this adaptor, or is it only for the Prologic?  Thanks for your efforts!  Will come in handy and useful!

Anyone?

[tppc]

When use the Memory Dumper on Windows 64bit this is the error that appears and what 'appears in the window of the dumper, later' I try to do the same reading on another pc always with win 10/64bit, Paolo

Hi there,
I am facing the same issue with W10 64 bits.
Does anyone know a way to have this utility working under W10 64 bits?

PS. I tried it on W7 32 bits, W7 64 bits and W10 64 bits and it did NOT work, always the same issue.
- Did anyone ever successfully run this utility?
- Could the issue be related to a specific version of .NET framework?

Regards

[tppc]

Hi there,
The Memory Dumper works fine.
You just need to know that after pluging the GPIB - USB adapter, you need to configure it with Prologix.exe from the KE5FX GPIB toolkit
http://www.ke5fx.com/gpib/readme.htm



After doing so,  0xfede's Cal RAM utility works great!
THANK YOU.

Regards

[Tryer]

Hi 0xfede,
Thanks a lot for sharing all that information.
I have a 3457a for a few months now and have read your post with huge interest.
My device has a sticker "03457-88810 D/C 8949 REV 2"
The controller board is labeled 03457-66511 Rev.B
I must say that i could not find a schematic for that version.
The one i found, is for Rev. A
I have an ancient PC (ISA slots, win98). The GPIB card running on it,
is one of the reasons i keep it.
You remembered me on old times. My 1st computer was an Apple II with Applesoft basic.
Peeks and Pokes were very common.
I have written a small routine and now i am very happy to have a dump of the 3457's memory.
My eprom is an exact copy of your uploaded one.
So, i only upload the CALRAM area, if anyone want to compare.
I have a question that maybe you or somebody else could answer:
The memory map goes up to 0xFFFF. But the 3457 accepts addresses only up to 0x7FFE.
Why that?
Thanks again
Vos can exsisto rabidus per totum annum, after your discovery...

[0xfede]

Thanks for your kind words tryer.

The reason because 3457A memory peek goes only up to 0x7FFE is because they reused the float number output function to print the peek result in two bytes at time.  If you try peeking 0x7FFF it simply cannot display byte 0x8000 and refuse to do that.

Also thank you for the dump, it will be put in a good use.

μηδὲν ἄγαν.
0xfede 

Hi 0xfede,
Thanks a lot for sharing all that information.
I have a 3457a for a few months now and have read your post with huge interest.
My device has a sticker "03457-88810 D/C 8949 REV 2"
The controller board is labeled 03457-66511 Rev.B
I must say that i could not find a schematic for that version.
The one i found, is for Rev. A
I have an ancient PC (ISA slots, win98). The GPIB card running on it,
is one of the reasons i keep it.
You remembered me on old times. My 1st computer was an Apple II with Applesoft basic.
Peeks and Pokes were very common.
I have written a small routine and now i am very happy to have a dump of the 3457's memory.
My eprom is an exact copy of your uploaded one.
So, i only upload the CALRAM area, if anyone want to compare.
I have a question that maybe you or somebody else could answer:
The memory map goes up to 0xFFFF. But the 3457 accepts addresses only up to 0x7FFE.
Why that?
Thanks again
Vos can exsisto rabidus per totum annum, after your discovery...

[Tryer]

Hi 0xfede,
You mean, peek will work only for the low 32Kb of the memory?
I had the hope, that an additional action for "upper bank" switching would ne required.
Anyhow, this is not as important as the CALRAM dump. And your solution with the switch makes
the whole perfect!
You said "The only drawback is that you have to issue the POKE 48 (which set LOW the CALREQ pin) a few times to be sure to set LOW the NVE pin."
Anything new about that? Is some other routine setting it back?
I have not tried to test it yet.
My battery shows an continuous increasing voltage. Is it the sign before the eruption?
04.Jan 20 3.457V
20.Feb 20 3.474V
01.Apr 20 3.500V
25.Apr 20 3.504V
18.Mai 20 3.508V
Latest at 5V i will replace it.

Greetings, Tryer
 
ΕΝ ΟΙΔΑ ΟΤΙ ΟΥΔΕΝ ΟΙΔΑ