Author Topic: Keithley 3330  (Read 8342 times)

0 Members and 1 Guest are viewing this topic.

Offline alocamTopic starter

  • Contributor
  • Posts: 40
  • Country: ar
Re: Keithley 3330
« Reply #25 on: April 23, 2019, 01:45:49 pm »
Hi DC1MC,

Thank you for your suggestion. I tried to include a stacks directive, to no avail.

Regards

Alberto
 

Offline alocamTopic starter

  • Contributor
  • Posts: 40
  • Country: ar
Re: Keithley 3330
« Reply #26 on: April 23, 2019, 01:52:59 pm »
Hello Andreas,

Thank you for your feedback. I haven't tried DOSBOX or any other emulation, given that the sw requires a specific PCIIA GPIB ISA board, and I assume there is no way to bind ISA hardware to emulated DOS.
Besides, picburner apparently succeeded in running calibration software on a 2.4 GHz based PC, so it rules out the possibility of having a clock speed related issue.

As far as I see, it is likely that this is a QuickBasic program, given that there are plenty of Basic application examples on Keithley's manual, and there is also a BASIC directory that comes installed with the ISA GBIB board.

I will try to reinstall all stuff on a different motherboard, although I cannot imagine what can go wrong under such basic DOS environment to avoid things going smoothly.

In any case, thank you for your concern.

Gruessen!

Alberto
 

Offline picburner

  • Frequent Contributor
  • **
  • Posts: 496
  • Country: it
Re: Keithley 3330
« Reply #27 on: April 23, 2019, 02:30:38 pm »
Hi Alberto,

I prepared a diskette image made with Teledisk 2.23 of the working configuration including the operating system.
Through this program you have to create a floppy disk (1.44MBytes) and start the PC from A:
You have to set the jumpers on the PCIIA card with address: 02E1H, irq and dma: none.
The software is already configured.
If the address 02E1h is already occupied by some other device or you remove it or you have to reconfigure everything.
(You have to download Teledisk from the net, it isn't in the zip file)

« Last Edit: April 23, 2019, 02:39:58 pm by picburner »
 

Offline alocamTopic starter

  • Contributor
  • Posts: 40
  • Country: ar
Re: Keithley 3330
« Reply #28 on: April 23, 2019, 10:49:43 pm »
Hello,

Thank you for taking the time to send the file. I prepared a bootable FDD, and booted directly from it. I do have the same base address, no IRQ, no DMA, and when running CAL same error shows up!

I cannot even determine whether there is something wrong with the GPIB board I purchased (although it does not seem to be the case) or whether there is something else having to do with the PC config.

Anyways, thanks again for helping me on the subject.

Regards

Alberto
 

Offline alocamTopic starter

  • Contributor
  • Posts: 40
  • Country: ar
Re: Keithley 3330
« Reply #29 on: April 26, 2019, 01:08:45 am »
Hello,

For those who might be struggling with the K3330 or interested on the thread, I was finally able to get the cal data from my unit.

After struggling with the DOS programs, I found a "compatible" motherboard that allowed me to run CAL.EXE!!!

The motherboard MUST allow you to disable internal L1 cache, and that solved the puzzle, if you enable L1 cache, it won't work, if you disable it, CAL runs as expected.

A warning for those willing to CAL their Keithley units: the program runs, but it does not allow me to calibrate output voltage. It stalls asking me to connect the signal to the multimeter (I specifically bought a Fluke 8840A in order to run calibration), even though everything is properly set up.  :--

I do not know how much more effort and time I will devote to this issue, but my guesses are that a) there is a problem with GPIB timing and CAL.EXE does not acknowledge the meter's readout (which by the way, is rather consistent at 0.4991VAC), or b) there is some other sort of hidden cause that kills the cal process.

I guess Ash was trying to shed some light on the CAL software, therefore I am attaching the cal data that I could read from the unit. If I could manage to effectively CAL the unit, I could try to sniff the GPIB bus in order to emulate this procedure using up to date GPIB / PC hardware.

Please find attached the text file that I could get from the unit's cal data.

Hopefully all this pain is useful for someone else!

Regards!

Alberto
 

Offline Ash

  • Regular Contributor
  • *
  • Posts: 161
  • Country: au
Re: Keithley 3330
« Reply #30 on: April 26, 2019, 02:24:27 am »
Hello,

For those who might be struggling with the K3330 or interested on the thread, I was finally able to get the cal data from my unit.

...


I guess Ash was trying to shed some light on the CAL software, therefore I am attaching the cal data that I could read from the unit. If I could manage to effectively CAL the unit, I could try to sniff the GPIB bus in order to emulate this procedure using up to date GPIB / PC hardware.

Please find attached the text file that I could get from the unit's cal data.

Hopefully all this pain is useful for someone else!

Alberto

Hi Alberto - Great news!  :-+ and the file certainly will help me as well.

I've been getting into the application code and I've just found where it starts assembling the commands to send over GPIB, but I'm 100% emulating so I don't have hardware. I'll have to modify the GPIB driver code to "succeed" and allow the program to move between steps, but this will take some time. If anyone is interested, it is a compiled Quick Basic application (probably QB4.5), I'd love to be able to reverse the Basic code from it, but it appears that there is no public information about this (but there was a guy who was offering a paid decode service many years ago).

I've found all the strings it uses to do the work and teased out all the commands it sends, the only undocumented one I've come across is "KC" (which I had also found by dumping the firmware EPROM). My K3322 responds to this with different errors depending on the state of the calibration write jumper on the device. (By error I mean I get bad parameter errors in cal mode, but invalid command type errors in normal mode)

If you have the ability to capture the entire GPIB bus conversations for the calibration and the read/write of the calibration constants that would be a really great help Even if it isn't a fully successful calibration. The Read/Write calibration commands would be really useful as a start even if you don't get the full calibration.

From looking at the strings in the application, the calibration seems to be done by reading the standards as a normal measurement and getting back the data to the CAL.exe, then it must do some calculations against the reference standards data to compute the constants and then sends these constants to the device at the end.

If you are able to capture the GPIB bus, I'll need that data and the refdata file as well that is used to define the standards used for calibration.
Then I'll use that to write a python script to do this in the future so we can continue to support these devices without needing to go through the pain again!

Cheers
Ash.




 

Offline alocamTopic starter

  • Contributor
  • Posts: 40
  • Country: ar
Re: Keithley 3330
« Reply #31 on: April 28, 2019, 11:37:17 pm »
Hello Ash, all,

I kept insisting on the subject, up to a certain extent, I am glad I did, as this meter is really good...

On one hand, I am still stuck with the CAL software, although I found a very interesting issue: there was a hardware failure on my K3330. The output signal was half of what the CAL routine expected, and I was lucky enough to locate a defective transistor that was responsible for such signal loss. Once I replaced it, the signal got back to its normal amplitude, and I could move one step ahead in CAL. Now it gives me some weird message while trying to run a frequency response test (I guess it will run a measurement of output signal at all available frequencies, but I don't get why it stops and gives an error message. This time output voltages are spot on).

In any case, I was able to write the original calibration data back, and I could verify that the system is now performing as expected. This means I would not need to go through calibration as the system is now OK, however I feel that leaving things like this may turn out to be a problem in case I need to run calibration in the future.

I have to find out some more time to experiment on the subject, but it is very frustrating to deal with old hardware and software.

I am posting a capture of GPIB bus that I could apparently run while writing cal data back into the unit, and while reading cal data from the unit. It's been ages since my last experience with GPIB commands, and more specifically with NI calls, so I do not know whether this info is good enough to make a move on migrating the calibration software to a newer platform.

In any case, this is what I have right now. I do not know whether I can manage things to have another GPIB controller as "passive" to listen and capture all bus activity. If anyone is aware on the subject, I look forward to any comments.

My current setup is PCIIA (mandatory for CAL.EXE to run), and I could connect an HP E5810A GPIB hub as well.

In case you are interested to have a look at the attachments, please check the WriteDat first, as this one may have two commands that belong to the readdata sequence that I ran afterwards. The original CAL data is the one I posted a couple of days ago. Hope this helps.

Best regards!

Alberto
 

Offline Ash

  • Regular Contributor
  • *
  • Posts: 161
  • Country: au
Re: Keithley 3330
« Reply #32 on: April 29, 2019, 03:32:46 pm »
Hi Alberto,

Awesome, that has really helped.

It appears that the files don't contain the full command list, there seems to be missing values at the beginning of read (the first floating point number read from the LCR meter is half way through the saved constants file you gave. It also appears that the write file contains a bit of the checksum calculation process.. as there are only 3 write operations to select words.

I have started to play with what I have found in the file and I have dumped a range of ram from my instrument using the following undocumented commands.

Code: [Select]
CMD               Returned                  Notes
------------      ----------------          --------------------------------------------
KCx                                         No idea. the command and parameter is accepted for x = 2,3,4,5
                                            This command was in the CAL.exe and perhaps is something about saving the
                                            calibration constants. Perhaps the 2-5 relate to the 100, 1K, 10K, 100K standards?
                                            as it looks a bit like the number of zeros...

?ID               2322,2.00                 Needs cal jumber, otherwise Err32.
                                            Firmware version 2.0, Keithley 3322 (not sure about the "2322")

`~1,0xxxxxx       0yyyy                     Read an integer at HEX address xxxxxx. Note this is used on
                                            2 byte boundaries only.
                                            This seems to be used to read back RAM locations to compute a checksum,
                                            there are many reads in sections, then a single write.

`~1,0xxxxxx,0yyyy                           Write hex value yyyy to hex address xxxxxx.
                                            This seems to be used by the CAL.exe to store a checksum.

`~3,0xxxxxx       floating point number     Read an 8 byte floating point number. Note this is used on
                                            8 byte boundaries only


`~2,0xxxxxx       floating point number     This also works, but appears to give different results to the "3" version.
                                            different format or floating point number size? it is not used in the calibration
sample data.

The type numbers "1, 2, 3" may be related to the NR1, NR2, NR3 formats for the normal GPIP commands as documented in the operation manual.

The read commands don't seem to need the calibration jumper enabled, but I'm guessing the write one will. I don't intend to test writes at this stage as I really don't want to mess up my unit. Also strange that the ?ID command needs the jumper.

The following is a dump of the ram integers and associated floating point numbers from my ram.

Code: [Select]
0001070: 3F84 9.99978241E-03
0001072: 7AC4
0001074: 1335
0001076: 915E
0001078: 3F10 6.28431473E-05
000107a: 7955
000107c: 0C92
000107e: 6A82
0001080: 3F84 9.99980868E-03
0001082: 7AC7
0001084: 99E3
0001086: 490C
0001088: 3F20 1.25666890E-04
000108a: 78AE
000108c: 5C78
000108e: E249

I tried converting the number into standard double format and dumping bytes but it doesn't quite work. So I'm guessing it isn't the standard PC format. Will look at this later.

More detail coming as I work out more.

Cheers,
Ash.




 

Offline alocamTopic starter

  • Contributor
  • Posts: 40
  • Country: ar
Re: Keithley 3330
« Reply #33 on: April 29, 2019, 05:53:12 pm »
Hi Ash,

Great news, it looks like you are working hard on the subject. I need to catch up with piles of stuff I left aside while repairing the LCZ meter.

Just as a comment, you mentioned the 2322 figure, and I guess this is the real model number. My unit is a K3330, also known as NF 2330, which is the original japanese manufacturer of the unit. They still produce great LCR products, but I have already checked and they do not provide any support on the former Keithley/NF units.

Your K 3322 should be the original NF2322, Keithley rebranded.

Hope this trivia help understand the version figures. I look forward to any progress you achieve, and I will try to set up a workbench to run further tests and GPIB captures as soon as I can.

Regards

Alberto

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf