HPIB Problem on HP 8568B [SOLVED] - Page 1
Forum section: electronics / repair

author: rob.manderson
author_rank: Regular Contributor
timestamp: September 01, 2018, 04:20:56 pm
content: I've been having problems with HPIB on my HP 8568B spectrum analyser. Firmware revision is 9.9.86I bought an HP59401A HPIB bus analyser to help. This way we're adapter independent and questions of whose drivers/software don't enter into it.I see the following behaviour. The instrument is set to Address 3 and the cal output is connected to the input.Set REN to true.Send the instrument listen address.The instrument freezes. The display stops updating.Send a command that would update a front panel annunciator. I chose to change the resolution bandwidth, which should light up that LED.The LED doesn't light up.Set REN back to false.The display resumes updating, the RB LED comes on and the instrument obeys the command.Reset the instrument and repeat the above sequence (REN -> true, address instrument) but this time send it CF20MZSP1MZ(cr)(lf) and assert EOI on that trailing lf.The display stops updating.Set REN back to false.The display updates and the instruments goes to a Center Frequency of 20 MHz, span of 1 MHz, showing the cal signal.Now repeat all of the above again but this time leave REN false.The display does NOT freeze and the instrument obeys all commands. When I change the Resolution Bandwidth that LED comes on.Note that in this sequence (send commands with REN false) no termination characters (cr or lf or cr/lf) are required, nor is it necessary to assert EOI.At no time do the Addressed or Rem LEDs ever come on.As a sanity check I tried using the 59401A analyser to control my HP5335A. It ignores commands sent to it unless REN is asserted. On the other hand, it obeys commands when REN is asserted and they are terminated with a CR/LF sequence. It never requires that REN be deasserted before it will act. In other words, it seems to work as it should. Ditto when controlling my HP3456A.I've examined the relevant part of the HP8568B CPU card schematic. It's pretty simple. There's a TMS9914A directly on the CPU bus and connected to the HPIB buss connector via an SN75160 data transciever and an SN75161 control transceiver. That's all there is. More in hope than anything else I checked continuity from each pin on the HPIB connector back to the transceivers. No opens or shorts. Then I replaced the SN75161 since I had one on hand. No change. That was a difficult procedure when all one has is solder wick, flux and a hand sucker. I'm loathe to attempt a replacement of the TMS9914A until my Hakko desoldering tool arrives sometime next week or the following week.However, I'm finding it hard to imagine there's a problem with the hardware given that the instrument can listen and correctly execute commands, provided REN is not asserted. In other words, the data bits are getting from the HPIB buss to the processor and it's obviously receiving what's been sent. Which makes it seem equally unlikely to be the firmware, given that everything else is working correctly. The instrument doesn't, as far as I can tell from a close reading of the operating manual, have a listen only mode. It wouldn't make much sense to have listen only (or talk only) modes for such a complex instrument.So I'm stumped. Do I replace the TMS9914A or do I look at the firmware? I've seen that there are versions from 1984 and 1987 available at KO4BB courtesy of John Miles. And on that subject, John notes that CMOS EPROMS mostly likely won't work. Is there a pin compatible EEPROM version of the 27256 or am I looking at NOS 27256'sYours, perplexed!

author: bitseeker
author_rank: Super Contributor
timestamp: September 01, 2018, 05:36:27 pm
content: That is odd. REN should be asserted before sending commands to an instrument. So, it's odd that the device is freezing instead of just locking the front panel from local control. It sounds like a firmware problem unless there's something in the hardware that could cause it to freeze when it tries to switch into remote mode.I don't know if its response to remote commands when REN is not enabled is directly related to the problem or not. It would be interesting to try a different firmware version to see if the behavior changes.Hopefully, someone with an 8566/8568 or experience with its HPIB will have more insights.

author: Berni
author_rank: Super Contributor
timestamp: September 01, 2018, 05:42:24 pm
content: I only used GPIB a little bit on my HP 8566 and i never had problems with it.I did see restating the cards to sometimes fix stuff on these old clunkers. But right now mine had some PSU failure and is waiting for repair but i keep delaying it because im not looking forward to getting the heavy boatanchor from my rack onto the bench and they are pretty complex things to fix.

author: rob.manderson
author_rank: Regular Contributor
timestamp: September 01, 2018, 07:55:46 pm
content: Quote from: bitseeker on September 01, 2018, 05:36:27 pmYep - every reference to GPIB/HPIB that I've tracked down is clear that REN must be asserted before addressing the instrument and though not explicitly stated it hints that the instrument should ignore everything unless REN is asserted. The freeze is when the listen address is sent - before any commands are sent.I'm thinking I'll have to bite the bullet and try the firmware. (Cue spending on eproms, an eprom programmer and, possibly, an eprom eraser :-) ) Given that HP invented GPIB/HPIB it's hard to imagine they could have got it wrong yet the instrument passes power on checks, which indicates that the rom checksums match, which implies (if it's firmware) that this version of the firmware was always wrong. Like I say, hard to imagine.Perhaps I should try a 'long POP'. Bugger, that means clearing the bench, manhandling the thing yet again to set a jumper. After my afternoon nap methinks!

author: Tony_G
author_rank: Super Contributor
timestamp: September 01, 2018, 10:49:16 pm
content: Does the asserted value for REN flow correctly across the line driver U30? I took a quick look at the service manual and you should see that it changes across there.U6 would be the next guess but that seems to be a custom HP part so it might not be clear what REN is supposed to do.If you haven't done it yet, check if Artek Manuals has a better scan of the service manual.TonyG

author: rob.manderson
author_rank: Regular Contributor
timestamp: September 01, 2018, 11:40:23 pm
content: Quote from: Tony_G on September 01, 2018, 10:49:16 pmI'm working from the Artek scans - worth every cent!U6 is the TMS9914A. What I don't have is extenders to get the CPU card up where I can probe things. I'll try soldering a bunch of wires to 'interesting' places on the CPU card so I can probe them when the machine's running.

author: bitseeker
author_rank: Super Contributor
timestamp: September 02, 2018, 01:27:26 am
content: Good plan. Curious to see what's causing this.

author: rob.manderson
author_rank: Regular Contributor
timestamp: September 02, 2018, 05:40:06 pm
content: Update:A 'long POP' did nothing. I didn't really expect it to - all it adds are some extra memory tests.So I soldered a few wires to various points and probed while the machine was operating. I only have an analog 'scope so what I was monitoring was the REN line at the point where it reaches the TMS9914A, plus one of the data lines and one address line on the CPU bus. First theory was that maybe something was 'hanging' the CPU while the TMS9914A was active but no, I see activity on the data and address lines even when the instrument is 'frozen'.The instrument seems to have the 'wrong' version of firmware for it's serial number. It's a 2517A prefix and according to the manual it should have firmware version 14.1.85, not 9.9.86 which is what it currently has. Is this significant? No idea. I note that the 'right' version is present on KO4BB so I think I'll go down that route. At least try 14.1.85 and see what happens. Though I seem to remember that one was supposed to be able to update to later versions of the firmware - there weren't significant changes in the instrument that would prevent later versions from working. The EPROMS do have the official HP labels on them.This won't happen for a few weeks - we're off to my wife's 50th high school reunion in Los Angeles in a couple of weeks and I won't be able to make the financial investment in EPROMS, eraser and programmer until after that. I'll keep you posted when I've tried the firmware change.I'm glad I went to a tech school - none of this namby-pamby reunion stuff. I don't even remember most of the kids I went to school with and I doubt there'll ever be a reunion. And if there is I'm out of luck - it'll be 8000 miles away!

author: bitseeker
author_rank: Super Contributor
timestamp: September 03, 2018, 02:40:01 am
content: If the firmware is too old for the hardware version, that could very well be it. At least getting the right minimum version in there could avoid other problems from arising.Have fun at the reunion. I went to my 20th; that was enough.

author: rob.manderson
author_rank: Regular Contributor
timestamp: September 19, 2018, 10:20:36 pm
content: Further updates. Due to the incredible generosity of an EEVBlog member I received not one but two HP 8568B CPU Cards in the mail today.Now for the bad news. Both CPU cards work just fine at running the analyser from the front panel. I can't see a difference in manual operation. And both cards behave exactly the same on HPIB as my original card. I tried with the HPIB back panel connector and cable the member so kindly included and again HPIB doesn't work correctly. So I'm stumped - I cannot see why it doesn't work given that the HPIB logic (as far as I can see in the manual) doesn't leave the CPU card except to connect to the back panel connector.I think a much closer and more detailed reading of the manual is required.

author: rob.manderson
author_rank: Regular Contributor
timestamp: September 29, 2018, 04:06:39 pm
content: At last HPIB is working on the 8568B! Woohoo and all that.It turned out to be the A12 RF section interface card. According to the manual this card 'contains digital functions that allow the front-panel controls to interface with the A15 Controller assembly' (CPU).Well, it does a little more than that.Having drawn a blank by replacing the CPU card I went back and retraced ground I'd already been over. And finally, I noticed that the reason the display froze was that sweep stopped. Since it's a digital display it continues to show the last update on screen even if sweep is stopped. (My poor excuse for taking this long to notice is that I was looking at the screen on the left, not at the Sweep indicator LED on the right.) I'll return to this shortly.Having exhausted every possiblity I could think of I decided to check out why the REM and Addr'd LEDs didn't light up. First possibility was dead LEDs. Not likely when every other LED on the front panel was working and doubly unlikely when the two non working LED's were status indicators for the very fault I was trying to fix!So I can see an LREM signal coming out of the CPU card, low for remote, high for not. And sure enough, when the instrument is addressed that line goes low. Transfer the probe to the front panel traces and the line stays high whether the instrument should be in remote or not. So I traced back from the LED and discover it goes through the A12 assembly.And there, on page 2 of the A12 assembly description was the answer. They talk about the Service Request block and it contains the following passage.The priority encoder, U1, collects the outpus of all interface functions, such as keyboard, RPG, sweep, HP-IB, phase lock errors, and so on. When any input is active (low), the priority encoder:1: Stops the Sweep2: Alerts the main processor...etc etc.So now we know why the display seems to freeze but we're not a lot closer, yet.Now the keyboard was working, ditto the RPG and sweep. I've never seen a phase lock error in this machine so I can't talk to that. Only HPIB wasn't working.So let's pull the card and see what can be seen. According to the manual it should have been either an 85680-60168 or an 85680-60181 card. What I had was an 85680-60121 which looks like a similar layout to the 60168 but not exactly the same. As I don't have an extender card to lift it out whilst still running I decided it was time to stop and see if that extremely generous EEVblog member had one he was willing to let me have. He did. An 85680-60168 card. It arrived in the mail this week and the machine now works correctly on HPIB.I used to repair these machines for Hewlett-Packard in Melbourne aeons ago, when they were HP8568A's and stopped shortly after the B's went into production. I remembered that HP sold an upgrade kit and it's documented on the Keysight website. They don't have a description of the 8568 kit, only the 8566 kit but the description and parts list shows that they changed the CPU card AND the RF Interface card. If they changed it for one model methinks it likely it was also changed for the 8568.So I'm beginning to suspect that my 8568B is a 'bitzer' (bits of this, bits of that). I've already noted that the firmware wasn't the right version for my serial number and it seems the A12 assembly also wasn't right for my serial number. I can only speculate that someone had a roomful of faulty 8568's (A and B's) and was charged with getting a few up and running so they could be flogged on Ebay. I doubt that, having determined that it works manually, they bothered checking if HPIB worked as well. And I'm not complaining - I paid $200 including shipping for mine (it was in the same city, Phoenix, hence the low shipping charge).Lessons learned. The first is that the circuitry is somewhat more complex than appears on the surface. The CPU assembly has the CPU, firmware etc but it also has the HPIB interface chips (SN75160/SN75162) and a TMS9914A HPIB interface chip. So looking at the schematic for the card it looks like ALL of the functionality is confined to that card. It's not at all obvious that things go off card and return.I should have noticed that sweep stopped! That would have led me to investigate that part of the instrument and, I have no doubt, would have brought me eventually back to the A12 assembly and I would have seen the description quoted above.I wish I could say that replacing such and such a chip repaired the card but, frankly, I'm just glad it's all working and feel no inclination to dig further. I suspect it's the wrong card for the machine anyway (though I'll be glad to be corrected on that point). As for why only HPIB failed, I have no idea.Incidentally, the firmware still isn't the right version for my serial number - the CPU cards I received had the 7.4.1987 release, which seems to work just fine.And I'd like to record my gratitude to the EEVblog member who so generously parted out an 8568B and made the path to this resolution so painless.

author: Gyro
author_rank: Super Contributor
timestamp: September 29, 2018, 04:37:24 pm
content: @Rob,Before concluding this thread, it would be good if you could go back and edit the thread title in your original post to something more descriptive, e.g. 'HPIB Problem on HP 8568B'. That way it will be easier for people with similar problems to find in future.

author: rob.manderson
author_rank: Regular Contributor
timestamp: September 29, 2018, 04:42:26 pm
content: Good point and done!

author: bitseeker
author_rank: Super Contributor
timestamp: September 29, 2018, 09:52:28 pm
content: Wow, thanks for the update, Rob. I didn't know there were so many variations. That was quite the puzzle to solve. Glad to hear it's all working now.

author: ekyle
author_rank: Contributor
timestamp: February 24, 2024, 05:28:31 am
content: This post lead me down the right track when I had the exact same problem after attempting an upgrade from a 8568A to an 8568B. I was able to find a solution without having to replace my A12 board.I found a "B" CPU board for a really good price but it turned out to have a bad EPROM. So, I flashed a new set using the last 7.4.1987 release. Everything worked great except for HPIB operation. I was fearing a compatibility issue with the CPU board and this firmware. It turns out that there were no issues using from using this release.The problem was when it would go into remote, the unit would freeze. The A12 RF interface board has a service request arbiter. On the "A" version,P1-25 is used as a tracking generator request signal (LTRG) and goes to U1 Pin2.The "B" version reused this pin as LRMT (Local/Remote). This pin goes to thecontroller A15 P1-50, which is the LRMT ouput of the periph. interface. So, when this signal went low, U1 pin2 saw it as a tracking generator request and wouldlock up the system. The tracking generator request is not used in the "B" version. So the two mods I did was to break the connection between P1-25 and U27 R7 (Resistor network) leaving the connection from U27 R7 to U1 Pin2. Then connecting P1-25 to U3 pin 13. I also removed Q1 and wired it's collector, which is P1-29 (LRMT) to P3-16. This matches the 85680-60168 board. Q1 is not used in the "B" version.