Fluke PM6666 counter freezing after 3 seconds from turning on.

[pizzigri]

Ok, so I just received this counter from an Ebay seller. It looks brand new and has options pm9604 (gpib) and pm9607 (vtcxo). I connect it to mains and turn it on: it checks the display, passes whatever test it does at power-on, and works for three seconds. Then it freezes completely, with what ever option or command I managed to input in those three seconds. I tried connecting a function generator to an input, sending a 10mhz signal, and the counter actually works, for three seconds.... then it freezes up with the frequency displayed on the screen. Using 0.2s measuring time it samples the frequency until it freezes again. Does not matter if it starts from cold or after twenty minutes of being powered up.... i looked at it with a thermal camera and some chips do seem to run quite hot (around 50 C) but it should not be a problem. Can anyone help me?

PS: it seems the previous owner replaced the mains filter - that shows a trend of exploding- with a standard IEC socket and standard fuse.

[Haenk]

My 6666 manual mentions a "local lock-out" function (GPIB only?) and a "display hold" function.
Not that I ever use those, but one of those might be the issue?

Here: http://na.support.keysight.com/pna/help/latest/Programming/GP-IB_Command_Finder/Local_Lockout.htm

Another thing I found is a service status request, which the counter sends out to attached GPIB units and requires a feedback (but gets none) - I'm sure some GPIB expert might help there...

[pizzigri]

Thanks for the help, but it still freezes.... the command should lock out everything except the local key and that locks as well. Actually, even when locked out the display should show frequency of the DUT, instead it freezes as well, I just programed a sweep to test this.....
It’s driving me crazy

[pizzigri]

However, you ARE onto something! I pulled out the GPIB board, and the PM6666 is not freezing any more. Either it’s a broken option board or something to do with it.... I have never used it in my HP34401A, so I sincerely do not know anything about the interface. How can I troubleshoot the GPIB? I was indeed planning to use it. At least I know the counter works!

[Haenk]

Funny enough, the german and english manual differ in the "local" mode. The german manual states (translated) "If the counter is commanded via GPIB, it is possible to deactivate the LOCAL key by a command." Of course this command is nowhere mentioned. And this part is missing from the english manual (however that's the first edition, compared to third edition on the german one...).

[tunk]

If the eBay listing said it comes with a GPIB card,
maybe you could get a partial refund from the seller?

[pizzigri]

If the eBay listing said it comes with a GPIB card,
maybe you could get a partial refund from the seller?

Well, it seems I’m stuck so yeah, since the listing did describe the unit as fully functional, I sent a friendly email to the seller describing the fault without filing a claim, so I’ll see how he replies.
Still beats me whether it’s some command that got stuck (?) or the GPIB board that’s broken. Is there any way I could troubleshoot it? Anyone actually use the GPIB interface of this fluke?

Haenk thank you that is most interesting! Maybe someone familiar with the instruction set for this protocol could chime in....

And thanks to everyone that helped!

[Haenk]

(sidenote: Got mine from ebay as "working", too. When powered up, it made noises like it was going to explode. Turned out to be the installed battery option, which failed to charge the loooooong gone NiCd battery. After removing the option, it worked fine. I really like the formfactor and ease of use.)

[pizzigri]

BTW, does anyone have the complete service manual for the PM6666? Not the philips 48 page draft that floats around, the one that is supposed to have 120 pages by Fluke.
And again thank you to all that chimed in!
Franco

[coromonadalix]

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwjJgLHKhfDrAhWnUt8KHf5NDRoQFjAAegQIAxAB&url=https%3A%2F%2Fwww.vintageshifi.com%2Frepertoire-pdf%2Fpdf%2Ftelecharge.php%3Fpdf%3DPhilips-PM-6666-Service-Manual.pdf&usg=AOvVaw030wI2m3EeITr3s1VYs2Ui

has schematics in it ?

41 pages    Phillips    around 6 megs

Just uploaded to KO4BB, should be in the recent uploads ...

[pizzigri]

Thank you Coromonadalix,

that is the draft I was talking about... I know that Fluke has an updated service manual for its version of the PM6666 (the one that officially supports 160 MHz instead of Philips' 120) that is over 120 pages long, and that is nowhere to be found.
That service manual is in fact branded Fluke....

schematics in the draft are good, however no silk screen, no part placement on the PCB and a pain overall the trace back parts on it....

[FransW]

PM6666   operation manual (English) 1989.pdf, 2.8Mb,   70pages no schematics
PM6666  operation manual (English) 1996.pdf,   601kb,     46 pages, no schematics &
              "What Happens When I Switch to Local?", page = 33
PM6666  service manual (English) 1989.pdf,   6,8Mb, 41 pages with schematics & parts list

PM me & suggest where to send (if any)

Regards, Frans

[coromonadalix]

i think the sv manual at 41 pages is the same as the one ive sent to ko4bb

[FransW]

From the Fluke 1996 Manual:
FLUKE , Timer / Counter , PM 6666, 4822 872 20017 7/October 1996

GPIB-INTERFACE OPERATION.............................. …….23
Introduction .............................................................. 23
What can I do using the bus? ................................... 23
Connecting the controller.......................................... 24
Giving the counter an address................................... 24
Checking the communication.................................... 24
Two ways of programming ....................................... 25
Syntax........................................................................ 25
Selecting output separator........................................ 26
How to select function.............................................. 26

GPIB address-selector Location ..................................5
GPIB interface-connector Location .............................5
GPIB-INTERFACE OPERATION....................................23 - 36

What Happens When I Switch to Local?
Switching to LOCAL causes the counter to adapt the set- tings indicated on the display, see ‘How to select function’. This means that the counter will never have settings in LO- CAL which are not possible to set via the front panel.
When switching to remote again, the LOCAL-setting will re- main. Bus-functions like SRQ mask, output separator, EOI, etc. will not be altered by switching to LOCAL and back again.
Summary of Bus Commands Function Selecting Commands

[FransW]

Manual (OCR) attached:

[pizzigri]

That is a wealth of information, thank you!
I will check it out immediately. Frans, I'll PM you immediately!

[pizzigri]

So. I found an ebay listing with the ever slippery service manual:
https://www.ebay.it/itm/PHILIPS-Timer-Counters-PM-6665-and-PM-6666-Service-Manual-2nd-Edition/324162530080?hash=item4b7997ab20:g:aiQAAOSwVkVeuMGp

I can't justify the price being asked though it is the one that is indeed complete (120+ pages), with this reference

PHILIPS Timer / Counters PM 6665 and PM 6666 Service Manual
90-10 2nd Edition
9499 465 01311

[coromonadalix]

@pizzigri     or you buy it,  and you ask for a few $$$  when people need the schematics

[pizzigri]

@pizzigri     or you buy it,  and you ask for a few $$$  when people need the schematics

Price  + sh and duty is almost 60 Euro, too steep for me...

[pizzigri]

Ok, so I got a bargain Philips PM6669 with GPIB option installed. I figured I’d have a “quick-n-dirty” stand-alone counter for casual use and one for more serious work, connected to a PC.
Argh. The transplanted GPIB i/f board freezes the PM6666 just the same. When I mounted the, assumed broken, board from the original Fluke PM6666 on the 6669, no problem. At this point I am sure the fault lies in the PM6666, as it freezes no matter what, including connected or not , and besides it came to me that way from the seller.
There must be something that crashes exactly three seconds after boot. Self test is OK. Maybe  the GPIB board init? Can someone point me in a direction? What to do? Unfortunately I am not a EE but just a hobbyist, so very complex things (and fundamentally equipment....) are a bit out of my reach.

[coromonadalix]

Agin  i"ll say this, there is or was a service manual on ebay, it could help you pinpoint some problems if there is ...    in the end you may loose more time than necessary  or you put a value on you time ??

maybe it could be a firmware compatibility ?? a setting ?  dip switch if there is one ??   i dont know theses counters

without the gpib card  does it operate fully  ?

[pizzigri]

Hi Coromonadalix,
I have the old service manual, the “new” one on Ebay is essentially an update though, and I have no idea what it includes. I will ask the seller. However, the manual is still 60 Euro delivered and that is a Lot for me... Selling copies would be unethical (and maybe illegal).

Anyway the problem I believe is in the counter and not in the board. So maybe the "old" manual may suffice.

Yes the PM6666 operates fully, smoothly and without any problem. I believe that it is something that failed in a previously working complete product; from the PM6666 sn, the GPIB card was installed at the factory. So it cannot be an incompatibility.

Also, I ruled out the card itself, it works in the other counter I just purchased on Ebay, and the PM6666 freezes with both cards.
So it MUST be the data path interface on the PM6666, I followed the path from the connector (labeled BU105 on the service manual) and I have three lines of interest: one is a 5mhz reference, and the other two are SCL and SDA (yeah, I2C bus) which go to a series of IC, I believe the three that could have something to do with the problem could be IC 101, 113 and 114, all labeled I/O (and all PC8574).
Both lines go to the CPU obviously (MAB8461P, with 6K ROM and 128 bit RAM), and to a custom IC, labeled IC 104 -CNT (controller?) an obscure OQ0501, built by Philips. This chip takes the 10 Mhz from the main oscillator and I believe divides it, as it supplies the 5MHz to the CPU and to the I2C bus. The 5MHz also goes to the GPIB card, where it is used by both the onboard CPU (another MAB84xx) and the GPIB IC.

BTW, it makes me think that maybe it could be possible to build a simple I2C to USB bridge to control directly the PM6666 from USB bypassing GPIB, however this is way beyond my possibilities - and I believe it wouldn't work all the same, since the problem is in the main board anyway.

Now what to do?

[coromonadalix]

ok    hum  transplanting parts could be problematic .... maybe a bus buffer  or your strange parts numbering ?

[FransW]

I have a good readable and copyable service manual on the way.
A paper copy.
Please inform me about the uncertain info so I can attach it here.

I will check my PM6666 GPIB card and version.

Regards, Frans

[coromonadalix]

Would be nice to host it  on Ko4bb  website if you can ? It would help the community

[FransW]

I know and I am willing to do so.
The only thing is, I have to scan it.
And that will take quite some time or I have to rely
on a scanning service.

[pizzigri]

Wow, that is absolutely great!
Thank you FransW

As for what information is most important now, well, I imagine the part where the bus logic is explained, so I can try to understand where the whole process hitches and freezes the counter... I cannot believe the I2C logic is flawed, as the whole counter uses this bus and if a GPIB I/F is not connected to the counter mainboard, the thing works flawlessly. There must be something happening in the first 3 secs that hangs the machine. If I could pinpoint an IC, hopefully NOT the custom OQ0501 I, maybe I can replace it, or otherwise test it.
Of course I would be interested in the whole manual, once it is available!


all my best,

Franco

[pizzigri]

BTW, since the PM6666 is totally disassembled, I imagined I could take a few pics of the only option that I could not for the life of me find images on the web - the PM 9607 - 00 10Mhz high stability time base option, in other words, the MTCXO card. I took the copper shielding off to show the components on the board. It uses a Philips crystal that is actually encased in glass, I haven't seen many of these enclosures.
The values are stored in the 85c82 eprom; there'a also a hex ubuffered inverter MC74HCU04N and a LP2951 voltage regulator, plus an IC I cannot ID. The Fluke literature says that ..."The unique MTCXO principle gives a residual temperature stability of 2 x 10-7 over the temperature range"... and that it equals the stability of an oven XO, of which I have some doubts.
However here's the images.

[coromonadalix]

niiice a transparent crystal,   i dont catch why there is an eprom   85c82   IC403 if im not mistaken     what is the part number of ic402 ??

[pizzigri]

The EPROM stores the drift values recorded at the factory for this single crystal at a range of temperatures. As the sensor measures the temperature, these values are used to correct drift, hence “mathematically controlled, temperature controlled XO”...
I can’t read the markings on IC 402, and there is no schematics or pcb detail in the “old” manual for the MTCXO, only the standard oscillator. I suppose it’s a microcontroller. Maybe in FransW new manual there’s a schematic for it!

[pizzigri]

I have traced the I2C bus in the PM6666 and 69.
The whole device is based on this bus, it connects all subassemblies - display, oscillator, to BU105 connector that is used for both IEC (GPIB) bus and optional internal battery and it also goes to the undocumented connector on the rear. In the PM6666, the I2C bus also goes to the input amplifier, to the three PC8574 ICs (I2C bus expanders) connected to a PM7528 Dual DAC, all missing in the simpler, one input amp of the PM6669.

The I2C bus goes to both the CPU and custom IC, and I cannot understand why plugging the IEC - GPIB board freezes the machine. If the Custom IC was bad, or there was something wrong with the I2C bus, I would see malfunctions, and I dont. I can leave it on all day and it will work flawlessly.

So I looked at which other lines are connected to the IEC bus, and found that there is a "option" line that gets connected, going to pin 12 of the CPU, which is an external interrupt (labelled INT/TO), vs. the "ident" used by the prescaler and oscillator (these lines tell the CPU if a MTCXO is installed so that a single button press calibration is available, and if the prescaler installed; I did in fact install the prescaler and it works without a hitch.
But even if the option line int causes a crash, why does it happen three second after I turn on the machine? I would imagine it would be immediate.
An idea could be that there is some corruption in the programming of the CPU (stored in the internal 6K), but I would not know how either to test this or correct it.
I have an hobbyist oscilloscope (SDS1202x-e) and good multimeter, but that's all I have... is there something I can try to troubleshoot this thing?

[coromonadalix]

Nice detective work

Could it crash when enumerating the i2c peripherals ?

A data sniffer like bus pirate or salae logic probe / clones on Ebay  ??

[Ordinaryman1971]

Far fetched idea but... maybe your firmware is somehow corrupted. Let me see if I can burn the copy of of my counter.
Could you see the version you're running?

I know it's silly for me to ask... but did you inspect everything for possible shorts... the seller stated that the meter is working fine.. so, lets assume that he did in fact turn it on and it was working, then... something happen in transit.

What is the frequency of the prescaller you've had installed... can it go more than 1.1 GHz, that's what I have in mine. Actually I've tested mine some time ago and it goes all the way to 1.6GHz.... and I have standard time base btw..

[pizzigri]

No, I don’t think there’s any way to see the fw rev, however the board is rev 12, and the counter is branded Fluke.... built possibly in 1998 or 99 one of the last manufactured. The prescaler is the “B” version, it goes to 1.3ghz.
I took the whole thing apart, as I wanted to add lcd illumination - the screen is horribly hard to read, just like my old PM2534 - and I could not find any shorts, actually the counter seems brand new, clean and tidy.
The PM6669 I got as a great deal on ebay was used and abused, scratched, splashed, dirty as hell.... but works perfectly. Frustrating

[FransW]

In the men time I received this manual:
Timer/Counter PM 6665 and PM 6666, Service manual, 9499-465-01311, 90-10 Second edition, 132 pages.

It will take me quite some time to generate a complete pdf version. The manual contains fold-out A3 size diagrams in color.

To contribute something I refer to the attachment with an introduction to something called "Extended Test Program" which I gathered as important.

Attachment 1: Extended Test Program
Attachment 2: historic overview GPIB parts lists

Frans

[pizzigri]

Downloaded and looking at it! Thank you!

[FransW]

This time all the extended test pages from the manual, repair part.

[pizzigri]

OK, so now I'm going to pass the night working on this. Let's see what goes on! Thank you a LOT.

[FransW]

Rest of the repair section and a clearer  "fault finding tree".

Success,  Frans

[pizzigri]

So, I passed the last 24 hours going crazy around this. I tried following every step, but for starters, nowhere I found any freezing references, and all signals test good on my DSO. As soon as I mount the f**** GPIB card, the counter freezes, after three seconds. I can do anything in those three seconds, and the device will respond. Then it just locks up. Does not matter, either card I have gives the same result, and instead both test good on the 6669 I'm selling. No error codes on the display at startup (and in extended mode the screen is blank anyway).
However, in extended test mode, and with the card mounted, it does not freeze - it does the relay thing, and if I move the jumper as described, it stops doing that, but does not freeze. However, in this case something does not add up, I cant manage to get the signals described on the manual, on the referenced pins. Not sure I am doing anything correctly, the text here does reference other chapters of the manual, i.e. the I2C description chapter.
I also learned something new, the I2C bus includes the TXCO and prescaler, I did not see this on the circuit diagram I had. Possibly it uses the protocol on the"ident" lines I found? No SCL/SDA go to these options, unless I'm blind.
I admit to be a complete noob and hobbyist.
Ahhhh.... I'll just wait for the whole manual, and see if it could be a power issue in the meanwhile. Tomorrow I'll check up currents too from the MB to the GPIB card.

[FransW]

I will try to scan the I2C-bus pages tomorrow.
From the GPIB parts lists not much can be deducted.
They appear nearly exactly the same with minor variations.
Did you check the com port dataflow to your PC?
Is there data flow?
I can not check any GPIB irregularities since mine does not have that unit.
There seems to be something blocking the counter functionality when the
unit is installed. Waiting for (unknown command).
Since working with a GPIB unit is fairly common with the PM66xx counter/timers
I would not expect something like this would happen, given careful consideration
setting the command address switches.
Can you monitor the data exchange with your scope?
Bedtime now, 01:00 hrs here locally.
Regards, Frans

Scanning tomorrow. I will try to OCR these pages, given enough time.

[pizzigri]

OK thank you. I just trashed my SALEAE clone, it just died on me so I have now doubts on whatever i was looking at. I purchased another locally at double the cost (10 Euro)  but at least it should arrive tomorrow, hopefully it's going to be better to check the I2C bus.
I really appreciate your help and the manual excerpts!
Best, Franco

[FransW]

I2C, 3 pages.
Rest to follow.

[FransW]

Pages 27, 28 and 29

[pizzigri]

So I have been checking the I2C bus with the logic analyzer. I probed the SDA and SCL lines, using the rear diagnostic connector, see photo.
I am baffled, I can see that the bus at one point basically crashes but I cant understand why. The Saleae sw I am using shows me an interpretation of the I2C bus but I cannot correlate it to what I read in the manual excerpts, surely I am lacking in knowledge of the bus (dont know crap about it) but surely enough it has nothing to do with the little I do know about it from i.e. arduino.
That something wrong is going on I can tell by the last signals recoded when the machine crashes and locks up, all lines go down and they are supposed to stay up. See images and XLS files, the one with the crash is labeled "withgpib".
Can someone help me with this? Pleease! 

ETA: Image 3 is of the counter WITHOUT GPIB card connected, and 4 and 5 are WITH the card, up to the point immediately before crashing.

[pizzigri]

Far fetched idea but... maybe your firmware is somehow corrupted. Let me see if I can burn the copy of of my counter.
Could you see the version you're running?

I know it's silly for me to ask... but did you inspect everything for possible shorts... the seller stated that the meter is working fine.. so, lets assume that he did in fact turn it on and it was working, then... something happen in transit.

What is the frequency of the prescaller you've had installed... can it go more than 1.1 GHz, that's what I have in mine. Actually I've tested mine some time ago and it goes all the way to 1.6GHz.... and I have standard time base btw..

Ordinaryman1971....
do you have a PM6666?
I checked spec sheet of the MAB8461P cpu, it has Mask ROM therefore impossible to retrieve or program for that matter.
Can Mask ROM corrupt? I find it unlikely, but hey could be.
I still hope it is something else.

[pizzigri]

Additionally, I have run the Logic analizer on the surely working PM6669 counter, and I found that it is mostly silent: the bus stays completely quiet in high until a button is pressed or something else happens, and this, even including the GPIB board installed.
At startup it does a routine check of everything and then just stays listening.

The PM6666 is always "talking", but that could be because of the DAC? This component is not included in the PM6669.

[pizzigri]

coromonadalix, looking at these info obtained with the Saleae clone, do you think that what you suggested could be true?
All my best, Franco

[coromonadalix]

Strange bug i may say,   since i dont have the full schematic, i dont know if there are bus buffers, buffer with a latch / enable  etc ...


The i2c should be relatively easy to read,   i dont know wich software you use or witch version ??  normally you have the bus decoding option in it ?  i recall you have 2 compatible software who works with the clones ...

Could be the MAB8461P who's corrupt at one specific place when the gpib card is there, gpib protocol / enumeration, say a single bit

The best would be to have anoter 6666 and try this chip in the other ...

Or  the last option is to sell it "with the gpib not working warning" and try to find another 6666 ?


Your excel sheet  show  lots of "missing ack"   (acknowledge) ??

[Ordinaryman1971]

I do have two.. they work like  a charm. One with gpib and C channel 1.1GHz second without C channel, both with regular oscillator. Let me open it up and see.... I also have a spare gpib port from 6680B.
Here are pictures of both before and after backlight hack.
It’s not perfect but it will do...
I will open it up later today and get a look.
Odd question... what's the address on your GPIB card... try different setting.... like first or the last address.

[FransW]

Pages 30 t/i 35

[khs]

Is there an interrupt line from the GPIB board to the CPU??

[pizzigri]

Is there an interrupt line from the GPIB board to the CPU??

No, there are only three lines going to the IEC (GPIB) Bus: 5MHz clock, SCL and SDA. Power is supplied via an unregulated 12V, which an LDO onboard the GPIB PCB then converts to 5V reg.
What is interesting, is that the PM6666 has the whole PSU always on, transformer, rectifiers, big levelling capacitors etc; what the power switch does is only to connect the already powered on unregulated rail to the LDOs and the rest of the circuit. So, since the GPIB is powered thru the UNREG rail, it is always on, even if the rest of the counter is "off".

[khs]

If you take a look at IC105 (on page 7 of the service manual) the option signal of the GPIB board  (BU102 on page 15) is connected to the interrupt input of IC105.

Is there a way to check (or cut) the option wire?

[pizzigri]

Yes I see it, I can monitor the line using the BU102 connector. It’s what I used for I2C anyway since it replicates all lines for diagnosing purposes

[khs]

I would be interesting to see I²C clock/data and the option signal (BU102) together - from your working counter and from your not working counter.

Additional you may check the I²C data signal with an oscilloscope and compare the voltages to to your 'working' counter.

There are two pullups for I²C clock / data: R147/R148. You may check the values and solder points.

Again just my 2 cents..

[pizzigri]

KHS,
this evening I'll try to check it out. I do have a DSO, I'll connect it this evening and also the logic analizer and see what comes out! Thanks for the heads up.

[pizzigri]

So I checked the pullup resistors they are basically almost spot on at 1.48K (both of them) however I'm measuring in circuit.
Iterrupts, I treid with the Saleae logic analizer, there's absolutely no traffic that I can see in the Option line, unless I am mistaken.
And also, I have to rectify a statement: it is true that there's always unreg power to the GPIB connectr, however the gnd ref is controlled by the main switch so the board does get powered on when the power switch is pressed. However, and I did test this, using one of the two GND lines and unreg +V, it is possible to keep something always on inside the meter - i.e. an OCXO osc, that then is always ready when the whole meter is turned on.
I am struggling with the brand new Siglent SDS1202X-E, which does have I2C decoding and a lot of other things but I have to learn that too! Uff. I could not see the signal levels yet. However, as I said, no traffic on OPTION interrupt.Surely I'm doing somethng wrong? It HAS to have some traffic.

[coromonadalix]

is there a configuration pin,  something who tells there is an gpib card installed ??    id pin ?

an tensy wheeny little thing  ?  something so stupid to make it work in this 6666 ??

I havent seen the schematic,  was it posted ?

[khs]

However, as I said, no traffic on OPTION interrupt.Surely I'm doing somethng wrong? It HAS to have some traffic.

If there is no traffic I would take my next two cents and:

1) Make an adapter to connect pin by pin from the mainboard to the GPIB board.

2) Isolate all connections - and check the counter.
- the counter should run.

3) Connect GND and check the counter.

4) Conenct the positive power supply and check the counter.
If there is a problem check the power supply.

5) Connect I²C clock and check the counter.
The counter should work.

6) connect I²C Data and check the counter.

7) connect OPTION and check the counter.

Then maybe we know more..

[coromonadalix]

@khs   that would be a good start sequence ?    what bothers me  is the gpib cards are all fine on another model ?  an enumeration command ?   something the 6666 doesnt catch after 3 secs

Could it be a given delay to acknowledge the card and if its not reporting back okay, the counter get stuck ? or a   non gpib enabled firmware is running ?? and you have to find an dump of an gpib enabled /working  fw dump ??

[khs]

@ coromonadalix:

You are right. All is possible.

Because we know more or less nothing - and additional the counter is not on our desks - my appoach is to suggest some test as simple as possible.

If we have a running counter at step 6 or maybe at step 7 it could be possible there is a firmware problem.

Before step 5 without any connection to the I²C bus it's possible maybe there are other reasons than firmware problems.

[pizzigri]

Small update, took KHS suggestions and done a Dupont extension/adapter.
Wire by wire, everything works until I connect I2C lines, scl and sda.
Power is fine.
Clock is fine.
 Option line (pin 9) does not make a difference. Crashes either it is not connected or if it is, so long that SDA/SCL are also connected.
I dont think there is something wrong with the option line, i.e. since there is no reply from it, the machine crashes - because downscale card and TXCO options are also connected to this line and they work correctly. If I remove the 1.3ghz option, the meter does not allow me to select C channel, as it should be, and works well.
So I suppose it has to do with I2C.

[pizzigri]

@khs   that would be a good start sequence ?    what bothers me  is the gpib cards are all fine on another model ?  an enumeration command ?   something the 6666 doesnt catch after 3 secs

Could it be a given delay to acknowledge the card and if its not reporting back okay, the counter get stuck ? or a   non gpib enabled firmware is running ?? and you have to find an dump of an gpib enabled /working  fw dump ??

No way to recover a fw dump, the memory of the cpu is mask rom, and no way to burn a rom....
the cpu is correct for the meter, the last line of the CPU markings include  the meter designation, and the last two digits of the series ( i.e. for the PM66xx the xx is engraved on the chip)
The CPU is correctly engraved “66”. So if it is a problem with the fw, it is a problem with the Mask ROM.
But, I never heard of Mask ROM going bad, is that an actual thing?

[thinkfat]

Did you notice in your LA traces of the I2C bus that the bus gets stuck? SDA and SCL are both fixed low, they're not returning to idle state. Something on the bus is blocking it, physically, while being talked to. The bus is then "busy" and the program in the counter is probably waiting forever for the condition to clear.

PS: I went back and looked through the spreadsheet you posted with the decoded I2C communication. It gets stuck trying to talk to something with the address 0x10. So I guess whatever has this address in the system is what's causing the hang.

PS2: an interesting test to make: while the counter hangs, disconnect the SDA/SCL lines from the GPIB interface. Does it return to normal?

PS3: Another thing to check: Does the 5MHz signal actually reach IC2 on the GPIB card? I'm guessing that the I2C state machine is driven by SCL so it reacts to its own slave address (0x10), but then if the 5MHz is missing, the rest of the slave I2C processing maybe doesn't happen and the bus is stuck in (or after) the ACK. An I2C slave may pull SCL low if it needs more time for processing. Maybe this is what is hardwired in IC2 and when it doesn't get its main clock, it will never release this SDA/SCL low condition.

[pizzigri]

Thinkfat,
I did as suggested! Yes, that is exactly what happens. I started the meter with the GPIB board connected and waited until the thing locked up. Then, i disconnected the SDA line, still locked up. Then the SCL, and it unlocked, all this obviously with the meter powered. I am  looking at the manual excerpts that FransW is posting, and the "Addr 10" is indeed the GPIB...

[thinkfat]

What I can see is that the OCR didn't really increase the utility of the scanned document :-)

[pizzigri]

Yes, haha!
In any case better than nothing at all...
In the meantime I connected my scope and got a 5mhz signal, quite jittery but that could be imperfect probe technique.

[pizzigri]

Going to say something really stupid here but... could it be a ground related issue?
I see dispersion on the chassis, and the oooold Schaffner filter is still in place - the ones that exploded...
Suggestions?

[thinkfat]

Ground is probably not a major issue, but the 5 MHz signal doesn't look too good. Does the documentation say anything about it? 2.54V peak is too low for a CMOS input (which I assume IC2 has). A CMOS logic high level starts at 3.5V. For TTL it would be OK. Is there anything specified about maximum rise time?

EDIT: I saw you use a 1X probe. That might get you into a bandwidth issue. Switch the probe to 10X and make sure it's properly compensated. Then redo the measurement.

[FransW]

Anything I can do?

Missing manual info?

Frans

[coromonadalix]

@Fransw

Have you scanned the schematics ??   i did not see them if you posted the files here ? or i have missed them

thks for your work

[pizzigri]

OK, so redone the measure with 10x probe. The result is 385mV (forgot to set the scope to 10x) so that makes 3.85V. Therefore good. Bandwidth of the probes at 1x is 6MHz, so I thought that they would work at 5Mhz....

Measuring 72V AC dispersion as well across the chassis. Should I float it? Or add a 1K resistor to gnd pin on power lead?

Today a new thing actually happened: the meter did not freeze with the GPIB connected. It happened once, but I did not notice it until I turned it off - that in fact the GPIB was connected to it -  and then it did not do it again!

I have a mighty headache. Today I cant do anything more, I will put myself back into it tomorrow!
I believe that we are getting somewhere anyhow. I apologize, I am just a hobbyist however I'm learning more trying to figure out this than in years at school.
Thank you for your help guys

PS Frans, are there details on the I2C protocol in addition to what you already posted?

[khs]

Thinkfat,
Then, i disconnected the SDA line, still locked up. Then the SCL, and it unlocked, all this obviously with the meter powered. I am  looking at the manual excerpts that FransW is posting, and the "Addr 10" is indeed the GPIB...

From my understanding the counter should run with the I²C SCL line connected, because the I²C SCL is an output from the CPU.

Is there a difference of the SCL signal from the CPU connected to GPIB and the SCL signal not connected to GPIB?

[coromonadalix]

yep  the "SCL"  clock should'nt be affected  unless something is dragging it down ?   

How do you measure 72vac ?  between the frame and the scope ground ??   for a scope  it would be best to add an isolation transformer for safety reasons,  unless you have a ground problem

Check if your screw(s) hole(s)  are not transfering ground between the main board and the gpib board  Ex  passing thru a strud,  an "pem" "punched stud in the metal" inserted in the metal  etc ...

[thinkfat]

You guys haven't been singing along. The IC2 on the GPIB card is pulling SCL low when it's being accessed. I2C slaves can do that, it's called "clock stretching". The bus master then must wait until the slave releases SCL (never happens) which is the very reason why the counter hangs. Proof: counter continues as soon as you disconnect the SCL line.

[coromonadalix]

got schematics for the 6666

Well the OP  did say the gpib card whas working fine in other instrument, did i read it wrong ?

reply #19
 

Could it be simply incompatible with the 6666 ?   if everything else works  and the gpib works in a 6669    what can we do to solve this ?

Is the jp101  test norm  jumper closed or open ?

[khs]

You guys haven't been singing along. The IC2 on the GPIB card is pulling SCL low when it's being accessed. I2C slaves can do that, it's called "clock stretching". The bus master then must wait until the slave releases SCL (never happens) which is the very reason why the counter hangs. Proof: counter continues as soon as you disconnect the SCL line.

[thinkfat]

I found a datasheet for the MAB84X1 series. The clock input is specified as HCMOS and TTL compatible so we're good here (though I think 3.8V still a bit low), but the maximum rise and fall time of the clock is <10ns. Can you check the clock edges meet that spec?

[thinkfat]

got schematics for the 6666

Well the OP  did say the gpib card whas working fine in other instrument, did i read it wrong ?

reply #19
 

Could it be simply incompatible with the 6666 ?   if everything else works  and the gpib works in a 6669    what can we do to solve this ?

Is the jp101  test norm  jumper closed or open ?

You're right, the GPIB from the PM6666 is working in another counter, and the GPIB from that counter also fails in the PM6666. That's why I keep pressing on thoroughly checking the 5MHz

PS: if you have a function generator, try connecting a 5MHz square wave from the generator to the GPIB module, instead of sourcing the clock from the PM6666. If it works then you have found your culprit. Then you need to find out how to restore or improve the 5MHz clock. Maybe add a 74HC14?

[pizzigri]

OK...
I connected my crappy FY6900 to the 5mhz pin on the board, 4V 50% duty cycle, square wave. I checked it on the scope and sincerely the original square wave from the meter is nicer. But I digress, on how crappy the FY DDS is. Anyway, turned on and the meter never goes past the POST, all leds lit and all segments in the LCD on.
So I thought to use an external 10 MHz reference using the rear BNC, bypassing completely the internal MTCXO oscillator, and no joy. Now it works as before three secs after power on, it locks up.

Then, I imagined that the 10MHz internal ref and 5Mhz square were out of sync, yielding the POST lockup, since I was using the DDS for the external 5mhz clock. SO, I connected the 10 MHz to the rear connector and 5 mhz clock to the GPIB card, using both channels of the DDS, therefore in sync with each other - reasoning being, this way I'm bypassing everything on the board save for the 5mhz clock for the master cpu (but still in sync due to the external ref coming from the DDS). Again, no joy; locks up three seconds after post. It's getting real frustrating.

[pizzigri]

I found a datasheet for the MAB84X1 series. The clock input is specified as HCMOS and TTL compatible so we're good here (though I think 3.8V still a bit low), but the maximum rise and fall time of the clock is <10ns. Can you check the clock edges meet that spec?

No they dont. It looks like a sawtooth especially in the rise edge, and not a square wave. Rise time is about 60ns, fall is 20ns. Amplitude is actually 4.20V, if I measure directly the pin.
Could it be the reason? The square wave I believe is built by the custom ASIC, if this is the case, I'm done for....

[coromonadalix]

you could use logic device ic's   to square up the signal ??

[thinkfat]

you could use logic device ic's   to square up the signal ??

Yes, a buffer with Schmitt trigger input for example, 74HC7541.

But, please show screenshots of the waveforms of the 5MHz signal.

I hope you disconnected the counter-generated 5MHz from the GPIB card before you fed it from the function generator? I don't see how it could be looking worse than the 5MHz from the counter itself - that one is abysmal.

Also, please show screenshot of the 5MHz waveform without the GPIB card connected.

Yes, there's one ASIC (IC104) that creates among other signals the 5MHz for the internal CPU (IC105) of the counter and the GPIB interface (BU105, pin 3). From what I can see in the schematics, the 5MHz go nowhere else.

I figure either there's something wrong on the GPIB board that loads the 5MHz signal and distorts it (that's why I want to see the signal without the GPIB card attached) or there's something wrong with the clock signal output driver in IC104, or the clock input of IC105 has a problem.

[pizzigri]

Hello Thinkfat!
OK so here are the screenshots.

First one, output from FY6900 at 5MHz, using bnc end to end.
Then, output of the 5MHz coming from the pin of the GPIB option connector on the meter mainboard.
I then tried to trace the output directly out of IC104, third image. The quality is worse because I had to use the smallest grabber I had, form the logic analizer and that has a long unshelded wire. Gnd is always on the frame of the counter (except for the first image obviously). I tried to hook up the 10 MHz but if I do so, somehow the meter doesnt start giving garbage on the screen.
What I find strange how ever is that the onboard CPU, that is exactly the same part mounted on the GPIB card, can use the sawtooth signal nicely and works, and the one on the card cannot. As I mentioned before, the counter works as a charm without any glitch that I can see if the card is disconnected.

Oops I mean here are the images....

[thinkfat]

It seems attaching the screenshots didn't work, however, I have a general advice on probing with an oscilloscope: Don't use a far-away ground point for probing. Don't use the frame as ground, in particular. Find a ground hook on the PCB or something similar. And of course, use the oscilloscope probe and nothing else.

EDIT: there's obviously a TP100 next to IC104. It has a pin labeled "GND", connect the oscilloscope probe's ground lead to this pin. Put the probe tip directly on the chip pin.

EDIT2: IF the waveform we see is real (which I doubt when I see the probing setup), it looks like the output driver on the clock output of IC104 is damaged. The high-side mosfet might be dead or deteriorated. It looks a bit like the recent "Intel Atom C2000 bug" that killed thousands of NAS, switches and other appliances. Maybe a similar "fix" could be used: You can try pulling the clock line up with a small resistor (200 or something).

[Dr. Frank]

Hello pizzigri,
maybe it's a silly question.. have you ever attached the GPIB to a PC interface and tried to steer the PM6666 from there?
Reading through this thread, I am under the impression, that you never tried that.

I'm only asking, because I used a PM6669 with GPIB many decades ago, and I'm not sure if that was required also.

Frank

[pizzigri]

Hello Dr. Frank!
the device freezes whether I connect a GPIB cable or not. However, I also have other devices with GPIB, a Philips PM2534 DMM, a HP34401A and of course the smaller sibling to the PM6666, exactly a Philips PM6669 which never showed the problems this one has.

[0xdeadbeef]

Mainly to get updates on this thread automatically: I also bought a PM6666 for cheap quite some time ago and it locks up (no reaction to key presses) occasionally directly after startup (probably three seconds, didn't measure that).  Originally, it worked most of the time, lately, I needed to start it a few times to avoid it locking up. So this seems to be something becoming gradually worse. Never really looked into this as I upgraded my Tabor counter in the meantime and even if I needed the PM6666, I got it to work after a few trials.

[pizzigri]

Ok, so here’s the updated measure. Did as told (thank you Thinkfat) and I do get a cleaner wave but it is still a sawtooth.

[thinkfat]

Aand you forgot to switch the probe to 10X again 

Really, make this a habit when you probe digital signals or anything above audio frequencies: Your probe in 1X mode has a bandwidth of maybe 5 MHz, which means you basically get to see the fundamental tone of the square wave and all higher order harmonic will be attenuated a lot. So you see a distorted sine wave at best, but not the true waveform.

[pizzigri]

Oh my god! But you pegged me perfectly: I'm an audio enthusiast, and I mainly play with amplifiers etc
Give me a moment, I'll redo it...

[pizzigri]

Here it same conditions

[thinkfat]

OK. Is that with or without the GPIB card connected? I'd like to see both.

[pizzigri]

Without, this one is with. The shape doesn’t change much but amplitude is less

[thinkfat]

Well yeah, that doesn't look OK. The signal is out of spec already without the GPIB card, with the additional load of the card it's not improving of course. I suspect that there's something wrong with the output drive of IC104, it just cannot source enough current to drive the line high fast enough. The counter itself seems to be happy, though.

The fall time of the signal seems to be OK'ish. If you want to try a small experiment, get a resistor of maybe 500 Ohms, connect it between the clock signal and +5V, see if this improves the situation. If you see a difference, try a smaller resistor, maybe down to 200 Ohms.

However, lifting the clock output pin of IC104 and feeding it into a Schmitt trigger buffer and from there back into the board would be a better idea.

Maybe, just maybe, touch up the solder joints of IC104. If you have a cold joint, that could explain it, too.

[shakalnokturn]

Agreed, that doesn't look fantastic.
What does that 5MHz look like on the PM6669 with GPIB installed?

[pizzigri]

Well, IC 105 and 106 are mounted on a socket so maybe I could lift them out and clean the contacts,  ow that I think about it it was a standard protocol for any problems on Macs with the ram. Will try that. And OK for the resistor, that’s next.
I don’t have the 6669 any more- waiting on an Hp 5385a with which I replaced it.

[pizzigri]

Wow what a difference, here’s the result of a R500 between +5v and clut on the signal:

...however it still locks up after 3 secs. I'll try now a R300

[pizzigri]

so taking +5v from pin 22 of IC104, closer than the 5v pin on the oscillator connector... going with a R280 tht's what I have now.
However, the meter doesnt boot, if I feed it this way

[thinkfat]

Don't go too crazy on the resistors. If the counter doesn't boot any more, that's a clear signal to stop what you're doing. If you damage the ASIC you have a paperweight.

The first attempt more or less proves that there is a problem either with the output driver or with the CPU (IC105) loading the clock signal too much. I'd now try recovering the clock with a buffer only for the GPIB card.

[0xdeadbeef]

Could be something totally unrelated though. Like due to aging of some component the GPIB card takes longer to boot but the CPU already started the I2C communication before the card is able to properly react on that. So it missed the request to answer and thus the CPU is blocked since it waits for an answer. Or something like that.

[thinkfat]

Could be something totally unrelated though. Like due to aging of some component the GPIB card takes longer to boot but the CPU already started the I2C communication before the card is able to properly react on that. So it missed the request to answer and thus the CPU is blocked since it waits for an answer. Or something like that.

The GPIB card pulls the SCL line low doing "clock stretching". The CPU is blocked waiting for the I2C bus to return to idle. It continues normally once you disconnect the SCL line to the GPIB card.

[0xdeadbeef]

Well, it's not really clock stretching in its usual meaning since it obviously continues forever. And one reason for this might be that the card's I2C state machine is confused because of timing issues.

[thinkfat]

I think so as well. What I imagine happening is that the I2C part of the GPIB CPU has a hardwired state machine driven by SCL. As soon as it receives its slave address it pulls SCL low to stall the master, then issues an irq. The processor part would then act on the interrupt and carry out whatever reaction is programmed. This part does not happen and so the bus stays blocked.

[0xdeadbeef]

My main point was: if this happens in lots of PM6666 counters (and it seems it does) and it is a process of deterioration (which it is in my case), there should be a common, typically aging related root cause. And a change of timing is something that caused similar problems in other cases. Programmers tend to rely on the timing that they saw during development. Things like performing a worst case analysis and explicitly waiting for the maximum time before trying to communicate with another IC is rarely done. Also adding an emergency break condition from a wait loop (that waits for some HW acknowledge) is something that is frequently forgotten.

[thinkfat]

There is probably an aging related defect in the clock output, it looks like the high side mosfet of the output driver has deteriorated (electron migration?). That's why you see it improve with the pullup resistor connected. Would be interesting to see the clock waveform in your counter.

[0xdeadbeef]

Didn't look into the schematics but is there actually a highside at all? That's not necessarily the case. Many designs just use a lowside output with passive pullup (i.e. "open drain"). Doesn't matter if the active edge is the falling edge - which it usually is.

[pizzigri]

There is probably an aging related defect in the clock output, it looks like the high side mosfet of the output driver has deteriorated (electron migration?). That's why you see it improve with the pullup resistor connected. Would be interesting to see the clock waveform in your counter.

So essentially this is non repairable, at least not easily. Are you asking Oxdeadbeef for his waveform, or me for the original 10 mhz  clock from MTCXO?
Can the 500 ohm resistor create a potential damage or speed up deterioration ? I was going to Implement it ito increase reliability but I may actually get the opposite!

[thinkfat]

There is probably an aging related defect in the clock output, it looks like the high side mosfet of the output driver has deteriorated (electron migration?). That's why you see it improve with the pullup resistor connected. Would be interesting to see the clock waveform in your counter.

So essentially this is non repairable, at least not easily. Are you asking Oxdeadbeef for his waveform, or me for the original 10 mhz  clock from MTCXO?
Can the 500 ohm resistor create a potential damage or speed up deterioration ? I was going to Implement it ito increase reliability but I may actually get the opposite!

I wanted to see the 5MHz clock from his counter.

The 500 Ohm resistor is not really a good solution. I meant it mostly to check a theory of mine. Buffering the signal would certainly be better, but we still haven't found the actual reason for the hang. We know what causes it but not why.

You mentioned the GPIB card worked fine in another counter. Did you manage to use it for PC communication or was it just that it didn't hang the other PM6669 during boot?

Since we don't have a lot of options here, it's best to play the elimination game to isolate the fault. The IC105 (CPU) is socketed as well? Could you pull it and check if the 5MHz looks better then?

[khs]

Now I've learned a device can stop I²C communication by holding SCK low.

So here my suggestion:
What happens when we insert a SCL buffer between the SCL output of the microprocessor and the GPIB controller , so the I²C bus cannot stopped by the GPIB device holding SCL low?

Not to destroy the SCL input/output of the GPIB device I would insert about 100 Ohm between the output of the buffer and the SCL input/output of the GPIB device.

 

[thinkfat]

Now I've learned a device can stop I²C communication by holding SCK low.

So here my suggestion:
What happens when we insert a SCL buffer between the SCL output of the microprocessor and the GPIB controller , so the I²C bus cannot stopped by the GPIB device holding SCL low?

Not to destroy the SCL input/output of the GPIB device I would insert about 100 Ohm between the output of the buffer and the SCL input/output of the GPIB device.

 

Violation of the I2C bus protocol. A slave must be able to stall the master when it needs more time for processing the access. This is called "clock stretching". If the GPIB card stops the counter from working I'd just remove it. It doesn't work anyway so it doesn't make any sense to have it.

[0xdeadbeef]

Dunno when/if I'll find the time but I'll consider it. Is this Pin19 of the IC marked L5899MC?

[pizzigri]

Well it's pin 19 of the custom ASIC labeled 0Q0501P, but yes, it's the same chip.
It's interesting to note markings, this IC was built in week 34 of 1997 in Nijmegen Holland, then sent to Taiwan for assembly and again tested in Holland.

[pizzigri]

Violation of the I2C bus protocol. A slave must be able to stall the master when it needs more time for processing the access. This is called "clock stretching". If the GPIB card stops the counter from working I'd just remove it. It doesn't work anyway so it doesn't make any sense to have it.

Thinkfat, therefore I think that this will place a nice nail in the coffin. I am wasting too much of the precious time of all EEVB members, and I am extremely grateful for all your help, at this point I will just remove the GPIB card for good and close the meter.

Maybe I'll use the option connector on the M/B as convenient way to power a OCXO inside the unit, simply routing the output externally using a 4cm BNC patch cable, the meter will see it as a External ref, and that's it.
But it has been a great ride, and I have learned a lot!

Just for info, I will remove the CPU once I get back home and see what the clock looks like without it...  All my best, Franco

[0xdeadbeef]

Did some quick measurements. Currently, the counter stops reacting to key presses after ~3s about every 2nd start.
So I did a measurement while frozen and while running. They look the same to me though.
I didn't invest any time to get rid off environmental crosstalk, but the measurements were made with a low capacitance active differential probe and a scope with ~750MHz bandwidth.
[EDIT]
The frequency measurement at the bottom of the screen is using the rising edge (no way to change that AFAIK). The falling edge frequency is pretty stable though if you look at the upper (trigger) frequency.

[thinkfat]

Thanks. If your IC105 is socketed, could you pull it out (carefully) and measure again? The counter will not boot (IC105 is the main CPU) but I'd like to see if that changes anything about the waveform.

PS: if you have a GPIB option, maybe pull it as well and try if the reliability improves?

[0xdeadbeef]

Not today or tomorrow. But I'm not convinced that this signal is the root cause anyway.

[shakalnokturn]

@0xdeadbeef: Does your counter also have the VTCXO option?

@pizzigri: Did your sold PM6669 have the VTCXO or not?

[0xdeadbeef]

I'm not at home right now, but I have that TCXO thing that can be calibrated by pushing some internal button when an external 10MHz reference is connected. Wasn't this called MTCXO?

[shakalnokturn]

Yes sorry my bad it is MTCXO.
Is it only the counters with this option that freeze after 3 seconds?

[0xdeadbeef]

Well, from what was concluded in this thread, the MTCXO option doesn't seem to be the issue but the GPIB option.

[pizzigri]

My PM6666 had the MTCXO option inside, the PM6669 a standard oscillator. But, I used also an external ref and it froze all the same. It only locks up with the GPIB option.

[shakalnokturn]

A little far fetched maybe...
What if the main code jams on an unexpected situation when GPIB is present due to a defect on MTCXO?
I'm thinking of a bad EEPROM or corrupt data, would be curious to know if keeping the temperature sensor well above or below ambient temperature (most accessed compensation values) has any effect.

[Ordinaryman1971]

I guess you can easily check it...  Pizzigri has working PM6669... that would be actually interesting... he didn't mention if he moved the oscillator over to the other machine..

[shakalnokturn]

I don’t have the 6669 any more- waiting on an Hp 5385a with which I replaced it.

But the next person who runs into a freezing PM6666 that has both GPIB and MTCXO could give it a try.

[FransW]

I don’t have the 6669 any more- waiting on an Hp 5385a with which I replaced it.

But the next person who runs into a freezing PM6666 that has both GPIB and MTCXO could give it a try.

I am wondering whether this a TE step forward.

However, it gives me the time to pdf the service manual and upload to KO4BB.

Frans

[0xdeadbeef]

If I pull the MTCXO board, the counter won't start anymore.
I didn't get why you guys would suspect the MTCXO board anyway. It's working fine and from the previous discussion, it seems clear that the fault is clearly related to the GPIB board.

[pizzigri]

May I also add that, differently from 0xdeadbeef, my PM6666 never showed (and still doesnt show) any freezing or problems of any kind as long as the GPIB card is removed from it. So it is the card undoubtedly, in my case, causing the lockup. And, the card works perfectly in the PM6669, and viceversa, the card from the 69 freezes the 66! Bah

BTW, I have been doing some tests and been surprised with the stability of the MTCXO, I thought it would have been some sort of gimmick instead it actually works, at least as well as a decent TCXO. Definitely better than the TCXO from the HP5385, that's for sure...

I havent given up, but the meter is reassembled and working as a standalone counter for now. And again, I want to thank everyone for your time spent trying to help me!

[pizzigri]

I don’t have the 6669 any more- waiting on an Hp 5385a with which I replaced it.

But the next person who runs into a freezing PM6666 that has both GPIB and MTCXO could give it a try.

I still have the PM6666, I sold the PM6669, which btw worked perfectly.

[0xdeadbeef]

May I also add that, differently from 0xdeadbeef, my PM6666 never showed (and still doesnt show) any freezing or problems of any kind as long as the GPIB card is removed from it.

Why would you say this? I never removed the GPIB card. At the moment my counter starts most of the time anyway, so removing the GPIB card would just be my last option if it should freeze all the time at some point.

[pizzigri]

May I also add that, differently from 0xdeadbeef, my PM6666 never showed (and still doesnt show) any freezing or problems of any kind as long as the GPIB card is removed from it.

Why would you say this? I never removed the GPIB card. At the moment my counter starts most of the time anyway, so removing the GPIB card would just be my last option if it should freeze all the time at some point.

Because my Pm6666 never starts up if I leave the GPIB card installed inside - it just does not work. Yours at least still works most of the time, so there is no need to remove the GPIB card. You see, differently from you, removing the card WAS MY last option....
I admit the phrase was not clear.

[Xgentec Jason]

Well now you lot have gone and done it.
I get caught up in reading every thread in this subject and now I have gone and bought the Fluke Pm6666 with Pm9604 for testing.   

The Fluke meter just arrived. Tested frequency calibration and it is spot on but further function testing tonight.