04-05-2017, 12:08 AM
(04-03-2017 02:17 AM)Dave Frederickson Wrote: [ -> ]Here you go.
Thanks! I'll just cut that image out of my laptop LCD display and paste it on the bottom. :-)
(04-03-2017 02:17 AM)Dave Frederickson Wrote: [ -> ]Here you go.
(04-04-2017 05:16 PM)Dave Frederickson Wrote: [ -> ]... I loaded the CAL RAM with zeros (all @ characters) using the B3 command, ...
(04-05-2017 07:45 PM)J-F Garnier Wrote: [ -> ](04-04-2017 05:16 PM)Dave Frederickson Wrote: [ -> ]... I loaded the CAL RAM with zeros (all @ characters) using the B3 command, ...
Which syntax did you use exactly with the B3 command? OUTPUT 1;"B3" then OUTPUT 1;A$ or OUTPUT 1,"B3"&A$ in one go?
That is: must the "B3" be terminated by CR/LF or must the 255 bytes immediately follow the "B3" string?
And must the last byte be sent as a HPIL END byte, as for the B2 read?
J-F
10 DIM C$[256] @ C$=""
20 RESTORE IO
30 OUTPUT :1 ;"RS"
40 FOR K=1 TO 16 @ READ D$ @ C$=C$&D$ @ NEXT K
50 OUTPUT :1 ;"CAL2";CHR$(13);
60 OUTPUT :1 ;C$;
100 DATA "@@@@@@@@@@@@@@@@"
110 DATA "@@@@@@@@@@@@OOOO"
120 DATA "@@@@@@@@@@@@OOOO"
130 DATA "@@@@@@@@@@@@OOOO"
140 DATA "@@@@@@@@@@@@OOOO"
150 DATA "@@@@@@@@@@@@OOOO"
160 DATA "@@@@@@@@@@@@OOOO"
170 DATA "@@@@@@@@@@@@OOOO"
180 DATA "@@@@@@@@@@@@OOOO"
190 DATA "@@@@@@@@@@@@OOOO"
200 DATA "@@@@@@@@@@@@OOOO"
210 DATA "@@@@@@@@@@@@OOOO"
220 DATA "@@@@@@@@@@@@OOOO"
230 DATA "@@@@@@@@@@@@OOOO"
240 DATA "@@@@@@@@@@@@OOOO"
250 DATA "OOOOOOOOOOOOOOOO"
(01-31-2018 11:19 PM)juani_cer Wrote: [ -> ]Hi there!
I recently bought an HP 3421. I made the Pilbox and I am trying to save the cal data. I am kind of new to hp programming language and I am struggling to do it. I am able to send and receive simple commands (like measuring voltage or resistance) but I don't now if i'm doing the correct procedure to read the cal data.
Jeff's version of ILCtrl (v1.04) doesn't recognize my pilbox so I'm using Cristoph ILCtrl v1.17.
I put B2 in "Data" and press "Send". Then I erased B2 and press "Enter" but I'm only getting a bunch of 8s (-8.88888E+8 to be precise)
Am I doing it wrong?
I would appreciate a "for dummines" version of the precedure.
Thanks and sorry for my broken english
(01-31-2018 11:19 PM)juani_cer Wrote: [ -> ]Jeff's version of ILCtrl (v1.04) doesn't recognize my pilbox so I'm using Cristoph ILCtrl v1.17.
(02-01-2018 01:28 AM)Dave Frederickson Wrote: [ -> ]B2 is the command to read the cal data from the 3468 DMM and CAL1 is the command to read the data from the 3421A. See the programs in this post.
(02-01-2018 08:45 AM)J-F Garnier Wrote: [ -> ]I'm pretty sure ILCtrl 1.04 works with the PIL-Box :-)
(04-04-2017 05:16 PM)Dave Frederickson Wrote: [ -> ]Here's what I've learned about the cal data for the 3468.
...
It looks like the first 7 nibbles in each row are the Zero, the next 5 the Gain, and the last 4 the checksums.
RRRR YYYYYYY GGGGG SSSS
0000000 00000 ffff
0.3v 9999974 f5d05 1968
3v 9999998 f45de fa53
30v 0000004 f43c2 fd58
300v 0000000 f4024 f2d0
acv 0000240 f3b2f 95eb
300r 0000000 01e11 f0c3
3kr 0000000 01cd5 fad7
30kr 0000000 002b5 f3e7
300k 0000000 00121 fde0
3Mr 0000000 0005c f6ff
30M 0000000 012ee fcc3
3A 0000016 02d04 e2cf
0000000 00000 ffff
...
0000000 00000 000
(04-25-2019 05:24 AM)djd328 Wrote: [ -> ]Did you investigate further?
I've been staring at the hexdumps for a little while, the 9999s jump out at me. Maybe an artifact of the parity algorithm? Assuming you are correct about the nibbles, from my 3468B:
(04-25-2019 08:44 PM)Dave Frederickson Wrote: [ -> ](04-25-2019 05:24 AM)djd328 Wrote: [ -> ]Did you investigate further?
No I did not. Once I was able to save, restore, and reset the CAL RAM data I concluded my investigation.
Regarding the 9's, like your YYYYYYY value for the 3v range, I would think that would be a negative offset from zero.
Dave
(04-25-2019 08:44 PM)Dave Frederickson Wrote: [ -> ]Regarding the 9's, like your YYYYYYY value for the 3v range, I would think that would be a negative offset from zero.
(04-26-2019 03:17 AM)djd328 Wrote: [ -> ]Ah, looking at other posts with cal constant sets, the Y intercept field is surely just BCD encoded. Didn't see that before, simple enough, yes those are trivially interpreted -ve numbers.
MacPro$ cat hp3468B/hp3468B.cal.good
@@@@@@@@@@@@OOOOIIIIIGDOEM@EAIFHIIIIIIHODEMNOJEC@@@@@@DODCLBOMEH@@@@@@@OD@BDOBM@@@@@BD@OCKBOIENK@@@@@@@@ANAAO@LC@@@@@@@@ALMEOJMG@@@@@@@@@BKEOCNG@@@@@@@@@ABAOMN@@@@@@@@@@@ELOFOO@@@@@@@@ABNNOLLC@@@@@AF@BM@DNBLO@@@@@@@@@@@@OOOO@@@@@@@@@@@@OOOO@@@@@@@@@@@@@@@
MacPro$
MacPro$ gcc cal.c -o cal ; ./cal < hp3468B/hp3468B.cal.good
RRRR YYYYYYY GGGGG SSSS Offset Gain
0000000 00000 ffff 0000000 1.00000000
0.3v 9999974 f5d05 1968 -0000025 0.99470502
3v 9999998 f45de fa53 -0000001 0.99446803
30v 0000004 f43c2 fd58 0000004 0.99426204
300v 0000000 f4024 f2d0 0000000 0.99402404
acv 0000240 f3b2f 95eb 0000240 0.99251902
300r 0000000 01e11 f0c3 0000000 1.00081098
3kr 0000000 01cd5 fad7 0000000 1.00057507
30kr 0000000 002b5 f3e7 0000000 1.00015509
300k 0000000 00121 fde0 0000000 1.00012100
3M 0000000 0005c f6ff 0000000 1.00004590
30M 0000000 012ee fcc3 0000000 1.00117803
3A 0000016 02d04 e2cf 0000016 1.00170398
MacPro$ cat cal.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
static char *range[] = {
"",
"0.3v", "3v", "30v", "300v",
"acv",
"300r", "3kr", "30kr", "300k", "3M", "30M",
"3A",
"", "" };
static char h[] = "0123456789abcdef";
int
main (int argc, char *argv[])
{
unsigned char cal[256];
int i, j;
signed char o;
float f, s;
read(0, cal, 255);
for (i=0; i<255; i++) cal[i] -= 0x40;
printf("RRRR YYYYYYY GGGGG SSSS Offset Gain\n\n");
for (i=0; i<13; i++) {
printf("%4s ", range[i]);
for (j=0; j<7; j++) printf("%c", h[cal[i*16 + j]]);
printf(" ");
for (j=7; j<12; j++) printf("%c", h[cal[i*16 + j]]);
printf(" ");
for (j=12; j<16; j++) printf("%c", h[cal[i*16 + j]]);
o = 0;
if (cal[i*16] > 3) o = 9;
printf(" %c", o ? '-' : ' ');
for (j=0; j<7; j++) printf("%c", o ? h[o-cal[i*16 + j]] : h[cal[i*16 + j]] );
printf(" ");
f = 1.0;
s = 100.0;
for (j=7; j<12; j++) {
o = cal[i*16 + j];
o = o > 7 ? o - 16 : o;
f += ((float) o ) / s;
s *= 10;
}
printf("%1.8f", f);
printf("\n");
}
}
ASCII:
@@@@@@@@@@@@@@@@
@@@@@AG@NLLANGEO
@@@@@@A@MOA@OMED
@@@@@@G@MKADOKD@
@@@@@@A@@@LCOAGL
@@@@C@@@MDLDLNLH
@@@DADA@BKAKNMEO
@@@@DCI@BKCNHBLC
@@@@@DG@ADMDKDDG
@@@@@@G@AEKDOCEC
@@@@@@B@NK@@OHDL
IIIIIIIOC@ALOGOD
@@@@@BB@MLMLMMEC
@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@
Hex:
0000000000000000
00000170ECC1E75F
00000010DF10FD54
00000070DB14FB40
0000001000C3F17C
00003000D4C4CEC8
000414102B1BED5F
000043902B3E82C3
0000047014D4B447
0000007015B4F353
00000020EB00F84C
9999999F301CF7F4
00000220DCDCDD53
0000000000000000
0000000000000000
000000000000000
│ E: d 1101 │ F: 7 01░░ │ 1
²↑↑↑↑ ²↑↑ │
│ 0: 0 0000 │ 6: 6 0110 │ 1 ┈┈┈┈┈┈┈┘│││ ││ │
│ 1: 0 0000 │ 7: f 1111 │ 1 ┈┈┈┈┈┈┈┈┘││ ││ │
│ 2: 0 0000 │ 8: 4 0100 │ 0 ┈┈┈┈┈┈┈┈┈┘│ ││ │
│ 3: 0 0000 │ 9: 3 0011 │ 1 ┈┈┈┈┈┈┈┈┈┈┘ ││ │
│ 4: 0 0000 │ A: d 1101 │ 0 ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┘│ │
│ 5: 0 0000 │ B: c 1100 │ 1 ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┘ │
¹↓↓↓↓ ¹↓↓↓↓ │
│ C: f 1111 │ D: 0 0000 │ 1 ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┐┌┈┈┈┘
³↓↓⁴
│ E: d 1101 │ F: 7 0111 │
(08-06-2024 08:27 AM)cdmackay Wrote: [ -> ]Do you think this might also apply to the 3478A?
(08-06-2024 08:27 AM)cdmackay Wrote: [ -> ]Do you think this might also apply to the 3478A?