Help out a GPIB newbie again? - Page 1
Forum section: electronics / projects

author: c4757p
author_rank: Super Contributor
timestamp: January 10, 2014, 11:53:50 pm
content: OK... after my last failed experiment with GPIB, I finally got myself a proper GPIB adapter. An Agilent 82350B PCI-GPIB card, and I installed the Agilent IO Libraries Suite. Now, I can finally talk to my 3437A. It works perfectly.As well as my TDS-380 (goodbye floppies), and the software handles my Fluke 45 as well, though that's on RS-232.But...... every time I try to send a command to my 3325A function generator, it either ignores me completely (most often), or gives me the middle finger. (Yes, it has one, shaped like the message "Error 7". Error 7 means "invalid command".)My first suspicion was a faulty connection. I've checked numerous times, includinginsidethe instrument.Itisconnecting to it. The "remote" annunciator activates, as well as "talk" or "listen" at the right times (as far as I can tell). But nothing happens. No functions change, no response is given to queries.Can anybody help me debug this?

author: AlfBaz
author_rank: Super Contributor
timestamp: January 11, 2014, 12:00:04 am
content: It's a HP also, so there's a possibility it may be the same one I had with the 3457A. I'll go back through my old code and see if I can find out what it was... Something to do with expecting a specific combination of CR/LF if I recall

author: AlfBaz
author_rank: Super Contributor
timestamp: January 11, 2014, 12:04:30 am
content: Still can't remember the specifics but it had something to do with the HP-IB End Or Identify (EOI) function which was enabled/disabled with the END command

author: c4757p
author_rank: Super Contributor
timestamp: January 11, 2014, 12:08:27 am
content: OK. That doesn't seem to be anything I can control in the little Agilent tool I'm playing with at the moment, so I'll have to finish getting the rest of the software set up (I had to install - *shudder* -Windowsto get it working, so nothing is installed ATM)It can't be anything to do with CR/LF, unless I missed some secret combination involving standing on my head while pressing Send with my left little toe...

author: AlfBaz
author_rank: Super Contributor
timestamp: January 11, 2014, 12:17:54 am
content: Quote from: c4757p on January 11, 2014, 12:08:27 amThere's your problem right there. Its therighttoe!

author: han
author_rank: Frequent Contributor
timestamp: January 11, 2014, 12:24:32 am
content: My experience with GPIB is when 82357B USB/GPIB Interface, there is several old instrument that "hang" when receiving :IDN? command. and have to restart the instrument first before send another command.Maybe the instrument didn't like when the I/O suite send a unknown command (not in it's dictionary.)

author: c4757p
author_rank: Super Contributor
timestamp: January 11, 2014, 12:32:15 am
content: I think I'm losing characters somehow... is it possible for the bus to run too quickly for old instruments?The commands "FU1" through "FU5" should select the function, and I made them work a couple times. Then they stopped working completely. I reset the instrument, and then tried again. I sent FU2 and it switched to a square wave. Then I sent FU1 and it threw a 1 up on the display, as if I had pressed that key. So it seems to have missed the FU.The EOI line is being asserted after transmission, as is the default. If I disable that, then there is absolutely no response.Quote from: hanIt's not being sent.(By the way... screenshots from my TDS-380 inliterallyone twentieth the time or better. I'm almost giddily excited. Might be the end of photographed analog scope shots in my docs.....maybe... I kinda like the analog though.)

author: han
author_rank: Frequent Contributor
timestamp: January 11, 2014, 12:43:05 am
content: maybe probing the GPIB connector using osciloscope or just led with connector will help.

author: AlfBaz
author_rank: Super Contributor
timestamp: January 11, 2014, 12:57:33 am
content: Quote from: c4757p on January 11, 2014, 12:32:15 amI think that was the problem with the HP3457A, it boots with this off by default, which required having to send "END 2" to enable it before you could do anythingQuote from: hanThese old instrument need just "ID?" with no preceding "*"If you are using that agilent IO utility, make sure you have "/r/n" as the EOL string in the options. It may be the EOI line is asserting before the actual end of the commandQuoteI still haven't gotten over the novelty of receiving streaming measurement data O0

author: c4757p
author_rank: Super Contributor
timestamp: January 11, 2014, 01:01:23 am
content: Quote from: AlfBaz on January 11, 2014, 12:57:33 amTheseoldinstruments don't respond toanyID requests!QuoteTried it. As well as every other combination.Oh well. I'll deal with it later. More important things at the moment - I don't have any function generation to automate today!

author: C
author_rank: Super Contributor
timestamp: January 11, 2014, 01:07:12 am
content: Been a lot of years.With proper hardware and the software to drive that hardware you can not talk to fast.In fact as you use longer cables to connect things your speed will slow to counter the effects of the longer cable. There is a signal that says data valid and a signal from the receiver that says I got it.Back in my day the first command to try to get to work with something from HP was the "Tell me what you are" command.From what I remember it makes a difference if you send a command or a sequence of commands chained. And if I remember correctly you could not have extra spaces when trying to say a number.Remember each device on the buss has an address that you need to send before the command to get a response from that device.C

author: c4757p
author_rank: Super Contributor
timestamp: January 11, 2014, 01:23:29 am
content: Quote from: C on January 11, 2014, 01:07:12 amGood to know. Thanks. Though I did find some speed-related setting in the config tool, set to 500ns (handshake timing, I believe); I moved it up to 2us. Didn't help though.QuoteYep, I got that all already.

author: AlfBaz
author_rank: Super Contributor
timestamp: January 11, 2014, 01:37:23 am
content: Quote from: c4757p on January 11, 2014, 01:01:23 amWas just looking at the manual, it isold!Curiously in one of the tables its says the End Of String (EOS) is LF* or 0x0A and 0x2A

author: c4757p
author_rank: Super Contributor
timestamp: January 11, 2014, 01:47:46 am
content: Tomorrow, I think I will open it up and probe along the signal path. Perhaps one of the lines is out.It seems to have a rather flukey behavior in general. I just saw it hang, then reset, when I pressed "hardcopy" on the oscilloscope...I think I've figured out the exact reason why the 3437A didn't work with the GPIB-232CV-A. It has no "read" command; it just gives a reading whenever you prompt. And the 232CVA takes a reading whenever it claims to have one ready. So they just kept feeding data back and forth until someone's buffer barfed.

author: edpalmer42
author_rank: Super Contributor
timestamp: January 11, 2014, 04:08:10 am
content: How do you have your cables connected? Some controllers and instruments can be picky about such things. Make sure the cables are a straight run from unit to unit to unit. No 'T' connections are allowed. i.e. A - B - C. Now, if you add D, it must be connected to A or C, not B.Check your cable connnectors. Install and remove them a few times to make sure the connections are clean. Maybe you've just got a bad cable. Are they all the typical big, thick cables?I'm not familiar with the Agilent software, but the software for my NI card includes an app that is a GPIB command sniffer that reports on what is being sent and received on the bus. Another app allows you to manually access the lowest level of the comm link and send and receive very low level commands. Do you have anything like that for the Agilent board?Ed

author: c4757p
author_rank: Super Contributor
timestamp: January 11, 2014, 04:15:31 am
content: The cables are all in a line: computer -> 3437A -> TDS380 -> 3325A. All are 1m cables fat enough to be murder weapons... I'll try swapping cables to see if the problem happens earlier up the chain.Quote from: edpalmer42 on January 11, 2014, 04:08:10 amI'll report back tomorrow after I've messed with the cables a bit.Yeah, I have those tools. Also tomorrow, I'll play with them a bit, and if they don't give me any insight I'll post screenshots.

author: MarkL
author_rank: Unknown
timestamp: January 11, 2014, 06:06:39 am
content: Quote from: edpalmer42 on January 11, 2014, 04:08:10 amIEEE 488.1 does not place this constraint on the topology. You can have star, linear, or any combination in between.For the OP, I've found HP gear from this era can be very finicky in what they accept and it's best to follow the manual to the letter. The 3325A manual says you need to terminate the commands with a EOS, which can be a LF or a "*". So, I would try "FU2*" or "FU2\n" (or however LF is passed in a string in your SW). Don't send it a CR - it's not expecting it and can confuse the primitive parser.The manual also talks about data modes 1 and 2. You could try settting data mode 2, "MD2", and see if that helps.

author: c4757p
author_rank: Super Contributor
timestamp: January 11, 2014, 03:55:34 pm
content: Yes, I tried all those line termination combinations.I can't find anything on the data modes. Where did you see that?It's not the cable. I tried every cable I have, and I removed the rest of the bus and connected it directly to the PC... no luck. Error 7.... Error 8.... occasionally the interface appears to hang until I either press the "Device Clear" button on the Agilent software, or the Local button on the 3325A. The IO monitor says nothing of interest, it only verifies that it is transmitting precisely what I tell it to.Cable is connected fine internally, and nothing looks "interesting" on the digital board.I've tried every setting I can find. Line termination, EOS character, "Set EOI with the last character", "Set EOI with the EOS character", bus timing, "Assert REN when System Controller".

author: AlfBaz
author_rank: Super Contributor
timestamp: January 11, 2014, 10:23:43 pm
content: Quote from: c4757p on January 11, 2014, 03:55:34 pmTable 3.9 shows all the commands and page 3-20 talks about the "Data Transfer Modes" I haven't read it but the next page (which seems to continue with the explanation" has been scanned off centre, chopping off the top of the pageI've downloaded the labview driver for the HP3325A and fortunately it's merely a "vi" made up of basic "string formatters. I'll go through it and see what command strings it generates. It's a shot in the dark but may be worth a try

author: c4757p
author_rank: Super Contributor
timestamp: January 11, 2014, 10:44:03 pm
content: I saw that there was a LabView driver for it, and I considered downloading it and... er, "acquiring" LabView... to try it out. Maybe I will do that.

author: AlfBaz
author_rank: Super Contributor
timestamp: January 11, 2014, 11:36:15 pm
content: So here's the final output string sentCode:DM 2 MP 0 MA 0 FU 0 FR 1000.000000HZ AM 1.000VO OF 0.000VO ST 1000000.000000HZ SP 1000000.000000HZ MF 5000000.000000HZ TI 1.00SEHere's a break down of what I think it all meansDM 2: Data mode 2. The unit powers up in data mode 1 where all received bytes are processed as they arrive and EOS ignored. DM 2 buffers received bytes and apparently doesn't hog the bus whilst it processes the commandMP 0: Phase modulation offMA 0: Amplitude modulation offFU 0: Fucntion 0- DC onlyFR 1000.000000HZ: FrequencyAM 1.000VO: amplitude in VOlts, there are 4 other options hereOF 0.000VO: offsetST 1000000.000000HZ: Sweep Start FrequencySP 1000000.000000HZ: Sweep Stop FreqMF 5000000.000000HZ: Sweep marker frequencyTI 1.00SE: Sweep Time in SEcondsWhat the command string doesn't show is how it's terminated. For that the GPIB Write module in labview, which writes this string is set to mode 0, which is "Send EOI with last character of the string" Not sure how you implement that

author: AlfBaz
author_rank: Super Contributor
timestamp: January 11, 2014, 11:38:49 pm
content: Quote from: c4757p on January 11, 2014, 10:44:03 pmInspite of my stance in that "other" thread, when it comes to instrument data I just want to be an end user, and to that end I find labview invaluable

author: c4757p
author_rank: Super Contributor
timestamp: January 11, 2014, 11:57:41 pm
content: Quote from: AlfBaz on January 11, 2014, 11:36:15 pmIt's the default, "Set EOI with the last character" in the preferences.I'm not really interested in the termination anyway, since in my desperation I've triedeverything.....Those are the same as what I've been sending. (Except the spaces, but the manual says spaces are ignored. I'll try them anyway...) I guess it must be something else. Clearly the GPIB adapter in the PC is fine, since everything else (including the 3437A which is even older) is happy with it. I guess it's time to scope out some signal paths...Quote from: AlfBaz on January 11, 2014, 11:38:49 pmMy favorite for data acquisition is either MATLAB or Python.

author: JackOfVA
author_rank: Unknown
timestamp: January 12, 2014, 12:11:41 am
content: The 3325A manual says that the maximum message length is 48 characters - I believe your message is much longer than the permitted length. Paragraph 3-114 of the manual. Hence, the instrument is receiving an invalid message string and it responds accordingly.You might try breaking up the command sequence into several messages.Also, some early equipment - and the 3325A meets that definition - may take some time to implement a command string, so you may find it necessary to add delay between each command message sequence. The proper method to do this is to query the instrument status after a command sequence to see if it has processed the sequence and is ready for another command. Don't know if that's supported in the 3325A or not, and if it isn't then throw in a fixed delay as a fudge factor.You have to treat the early HPIB/GPIB capable instruments differently as their processing power and memory is limited compared with modern gear.

author: AlfBaz
author_rank: Super Contributor
timestamp: January 12, 2014, 12:14:36 am
content: Quote from: c4757p on January 11, 2014, 11:57:41 pmI keep thinking you need to be a math expert to use matlab. Ive seen Shahriar of SignalPath fame use it to very good effect. This sort of stuff makes me wish I knew what I was doing

author: c4757p
author_rank: Super Contributor
timestamp: January 12, 2014, 12:19:04 am
content: @JackOfVA - I haven't sent it such a long command string. It can't even take just a simple "FU1" (switch to Sine), all by itself. I just meant I've been using the same command identifiers and arguments.Quote from: AlfBaz on January 12, 2014, 12:14:36 amIt helps to be familiar with linear algebra, as that is its intended purpose (and it'll make some of its idiosyncrasies seem less WTF-ish). I find Python simpler for very general signal acquisition, but if I need to do any software filtering or anything of that nature, MATLAB is handy.

author: AlfBaz
author_rank: Super Contributor
timestamp: January 12, 2014, 12:24:28 am
content: Is there any difference in command response after sendng it DM2? If not is there a way to set the data mode from the front panel?

author: c4757p
author_rank: Super Contributor
timestamp: January 12, 2014, 12:45:32 am
content: From a fresh power-on, termination \n, EOI on end of string, 3325A the only thing on the bus using a known-good cable:- Device Clear. GPIB activates, "remote" and "listen" LEDs comes on.- DM2. Command "successful" (or, at least, nothing is hanging), instrument returns to remote/listen.- FU2. Command "successful", instrument returns to remote/listen... but the function has not changed.- FU2 again. Same thing.- Read status byte. 0x00- Read status byte again. Hang.- Device Clear.- FU2 again. Hang.

author: c4757p
author_rank: Super Contributor
timestamp: January 12, 2014, 01:23:06 am
content: Hmm.....Couple measurements on R51:1 -> 3: 2.12k, took a few seconds to charge up2 -> 3: 2.41k, took a few seconds to charge up.The schematic shows 3k and 6k2. That pin goes to pin 3 on an SN7438. The only other place it goes is the GPIB port, which is disconnected. I didn't think the output impedance of the 7438, powered down, would be low enough to cause that, so I clipped the lead and tested again. The measurements are the same.Would that resistor network being so far out cause that problem? I would think those are just for biasing the port when it's not connected, and the output driver sending signals to the 3325A would override those levels.

author: AlfBaz
author_rank: Super Contributor
timestamp: January 12, 2014, 01:40:18 am
content: Quote from: c4757p on January 12, 2014, 12:45:32 amDevice clear sets it to initial turn on state which means it back to data mode 1 where it waits for a command to be processed before relinquishing the bus. The manual seems to set out a data phase, presumably the commands, followed by a trigger phase (that I cant see in the long command string I gave you earlier) I wonder if all the params have to be set before it does it's thingAnother thing which springs to mind, is the dip switch at the back of the unit set to listen only

author: AlfBaz
author_rank: Super Contributor
timestamp: January 12, 2014, 01:42:33 am
content: Quote from: AlfBaz on January 12, 2014, 01:40:18 amor is it waiting for an external trigger?

author: c4757p
author_rank: Super Contributor
timestamp: January 12, 2014, 01:45:59 am
content: Quote from: AlfBaz on January 12, 2014, 01:40:18 amOh, HP wouldn't be so nice as to put it on the back! No, that's under the cover on the digital board...I looked in the manual for any text at all on the DIP switch and didn't find any, other than that the factory default address is 17... But "LON", which I'd assume is "listen only", is 0/off. "ROM" is 1/on - what's ROM?

author: AlfBaz
author_rank: Super Contributor
timestamp: January 12, 2014, 01:48:52 am
content: Quote from: c4757p on January 12, 2014, 01:45:59 amLOL!QuoteI think I saw that in there somewhere, it showed the layout of the dipswitches an I seem to remember something about testing

author: AlfBaz
author_rank: Super Contributor
timestamp: January 12, 2014, 01:51:25 am
content: I know you don't want to hear about termination strings but in table 3.10 EOS is shown as 2 characters "LF" and "*". Seeing as they break up all of the commands into a separate line for each character in the command, I can't help but feel that you need /n* as EOS

author: c4757p
author_rank: Super Contributor
timestamp: January 12, 2014, 02:00:03 am
content: ROM is for testing the ROMs with a signature analyzer, and is in the correct position for normal operation.Quote from: AlfBazThat would be bizarre, and it wouldn't match the example commands they give, but I will try it as soon as I get the lid back on.

author: c4757p
author_rank: Super Contributor
timestamp: January 12, 2014, 02:04:37 am
content: Nope.Now that this bigwashing machinefunction generator is on top of my workbench I'll do some probing while signals are coming in.

author: AlfBaz
author_rank: Super Contributor
timestamp: January 12, 2014, 02:20:19 am
content: Have a look at page 48 (PDF pg not man pg) of the manual it has some stuff there about starting sweeps

author: c4757p
author_rank: Super Contributor
timestamp: January 12, 2014, 02:26:04 am
content: Found it! Possibly.I was probing waveforms, and found #1 on pin 9 of U66. (The lower waveform is on pin 2.)So then I probed +5V. #2.Hmm... bad rectifier capacitor? I think so!...or maybe not. Feeding power in externally doesnotmake it work.

author: c4757p
author_rank: Super Contributor
timestamp: January 12, 2014, 03:07:26 am
content: I found these lower two waveforms on various pins on U66, one of the bus transceivers. (I don't recall where I found the lower one - one of the four bus-facing pins - but the middle one is on pin 9, which drives DIO8.)So I disconnected the cable and probed just the cable while transmitting, and got the upper waveform.Is that shorter pulse at the beginning small enough to cause issues? 2.32V low to high.

author: MarkL
author_rank: Unknown
timestamp: January 12, 2014, 03:42:01 am
content: Data mode 2 is "MD2", not "DM2".The manual states mode 2 buffers the command string (up to 48 bytes) and then executes it, as opposed to mode 1 which executes the commands as the characters come in. It's just something to try...I don't think you're wrong to start suspecting the hardware, but I wouldn't give up on the notion that the controller is not sending exactly what you want with regard to the ending sequence. If you have one, this would be a good time to connect a logic analyzer to the GPIB to verify the command string and bus control signals are doing what the 3325 manual specifies.

author: c4757p
author_rank: Super Contributor
timestamp: January 12, 2014, 03:44:18 am
content: Yup, I'll hook up an LA and post the output. Just have to find the software for the damn thing...

author: c4757p
author_rank: Super Contributor
timestamp: January 12, 2014, 04:27:23 am
content: OK, here's what it sends for the message "FU2" with termination \n:My talk address: 21UNL - unlistenMy listen address: 17"FU2"\nEOIEdit: Ooh, think I found something. I had switched it into Listen Only while I was probing because then the messages would transmit unimpeded and I'd be able to see signals on the scope. That's how it was configured here. But I just changed the mode and transmitted again. It gets through MTA and MLA, but when it receives FU2, the 3325A pulls NDAC ("data not accepted") high and the transmission halts.But I still have no ideawhy.It seems to behave more predictably with the 5V rail fixed, at least - now itneverworks...

author: AlfBaz
author_rank: Super Contributor
timestamp: January 12, 2014, 08:34:10 am
content: Don't know if this would be helpful but if you disconnect the cable and ensure pin 12 on the transceivers is low (data output disabled) you should get around 3V on the external bus pins if the pics of the transceivers in the manual are anything to go by. You could also throw a logic pulser on the data input side of them and see that you get corresponding changes on the bus side. (so long as pin 12 is high)Testing the other way might be a good idea also

author: C
author_rank: Super Contributor
timestamp: January 12, 2014, 08:40:35 pm
content: Back in the 80's HP had many different groups making things. Not all good common things got to the other groups very fast so you end up with different groups of standards. Some HPIB connections could be thought of as just replacing the serial port with HPIB while for some equipment the HPIB was the limiting factor.Said in a simple way, you could have two voltmeters with a HPIB connection produced by two different groups and have some differences in the commands needed for the HPIB.When I first started working with HP at this level, I though that they never built something for their customer. They would build something to cure a problem a group was having and then later may sell it to their customers.The standard calculator for control of HPIB instruments if there was one was probably the HP9825. It was $$$ back then. The 9825 was really a custom built computer with a custom built by HP processor. The 9825 was programed in HPL a very simple but powerful language. Appendix B of the attached link contains a HPL program to test a 3325A. Using this program listing you have something that works to build on. Note: that program listing looks like it came strait from the built in printer so there should be no typing errors.To better read this HPL program you may need some help. The HPL language was logical to the extreme. No weird stuff possible. It allowed real time programed interrupts but would only jump to the interrupt code only between lines in the main program. You could have many commands on a line up to the line limit.The->that you see in the listing is the "GOES IN TO" operator. An assignment operator. It was a single character symbol but when printed some printers had to use two characters to print this symbol.A+B->C+5+D->EThe above line says take A & B and add them. Put the result in C. The result gets 5 added to it along with D and that result gets put in to E. This is all numbers as there is no $ added to the var name.In the first example you have "wrt 717,". The first 7 is the interface address for the calculator with the next two 17 being the HPIB buss address. An HPIB Address will always be two characters here, so a buss address of 6 would be 06 with this added to the IO device address.What is in between the " " is exactly what is sent on the buss.line 2 you see "RDS (717)"That is read status of hpib device 17 on IO interface 7. If it was RDS(7) that would be read status of the IO interface 7If you have problems reading the program, ask, I may be able to translate.===========HPIBSome but not all devices connected to the HPIB have an identify command so that the calculator could ask "what is at this buss address". These commands were not always in the docs for the device. No device support would give you an error from the device or be as if you never asked. The response was a text string when supported, normally the model of device.ID?IDN?Are the two commands to try.When I was building up programs to work with HPIB, I would do the followingAsk a working device for it's ID thenAsk the same working device for it's ID againIf this did not work then there is a problem even if it is dumb to ask twice.I would then try to get the ID of the new device by putting request between the working device's ID requestsIt was not surprising to get a valid ID response from a device that did not have it listed in the manuals.Sounds dumb but this sequence will catch many problems you could have. If your good working device does not have a working ID then use something else that will work every time with no delay.I would then work on inserting commands between these working commands to the device that required no response from device that I could check on the device interface.Then progress to Asking for data back that would have no delay needed.At first my program would build the command strings as text so that I would know exactly what was sent and received.You may not have noticed the followingA device will know if you ask it to talk. If it has nothing to say, most times the buss will hang until it does have something to say. Sounds dumb until you think of an a device operation that takes some time. Telling a counter to take a ten second freq reading and then addressing that counter to talk will stop all buss activity until the counter has a reading it can send. If the buss is hung in this way you can not ask for the status of a device as that requires a buss not hung. You could ask for the status of the buss. For the 10 sec freq reading with many devices on the buss you would normally poll the device instead of hanging in a read.At the computer end you have a buss status register some what like a serial or parallel port status register. You also have the computer as a device on the buss status. Each device connected to the bus also has a status. For some devices you have to be careful when asking it's status. The device could be busy so asking a wrong time hangs the logic.This is from memory so could be wrong. Part of the time a HPIB buss signal line is acting like a wired OR but later may be working with a totem pole driver. This is what allows a parallel response from many devices while the totem pole driver allows faster speed when this is not needed.The buss has a min between connectors limit and a max total length. You can wire in T, X, W patterns but not have a O pattern.You can have more than one of what you may call a controller and it can shift around during normal buss operations. While not normal, some of the fancy devices would use this to print a plot on request by what you might think of as a controller.may help someChttp://cp.literature.agilent.com/litweb/pdf/03325-90014.pdfhttp://cp.literature.agilent.com/litweb/pdf/03325-90002.pdf

author: MarkL
author_rank: Unknown
timestamp: January 14, 2014, 04:40:21 pm
content: Quote from: c4757p on January 12, 2014, 04:27:23 amWell, by your bus analysis it appears the 3325 is getting the right sequence for "FU2" (gee, nice acronym), including the termination.The FU commands can take up to 1500ms to execute, so if you're in data mode 1 (the default), it's probably trying to do it and holding the bus until it's finished. I take it by your description it's hanging forever.If you do a simpler and faster command, say "SM1" or "SM2", does that work? Does the behavior change when using "MD2"? Just doing "MD2" by itself might also be enlightening since it likely only changes a mode internally to the processor and doesn't try to change anything in the signal gen section. Does anything interesting happen when you send it self-test, "TE"? Can you get any command at all to consistently work?It's also interesting you found bad caps, I'm assuming, in the pre +5V regulator supply. What did you replace? (C53, perhaps?) Have you poked around with a scope at the other DC rails to see if they're steady?There's a fairly extensive debugging flow chart in section 8-B for the unit's HPIB interface, but it really needs a signature analyzer to work through it. There's a few things, though, you can check without one. Specifically, the manual calls attention to the optoisolators as a common failure point and provides some things to look at with a scope (see 8-B-1).

author: c4757p
author_rank: Super Contributor
timestamp: January 14, 2014, 04:47:12 pm
content: Sorry, I haven't replied in a while. Been busy with other stuff.Yes, it's hanging forever.I haven't replaced any capacitors yet, as I don't have the time or ambition at the moment to go through the whole instrument to find bad caps, and it's enough of a pain in the ass to fully disassemble that I don't want to change just a single one. Nor do I have any on hand that not only match, but are of a quality worthy of installation in this well-built instrument.It doesn't appear to leak enough to overheat, so I just disconnected the transformer tap and fed 9V DC externally into the rectifier before the regulator.Nope, no commands work at all. I tried every command in the manual; all make it hang upon receiving the first letter. In listen-only mode it receives the whole command, but doesn't act on it.Optoisolators - that's interesting. This strikes me as exactly how it would fail if they were bad. The address recognition is all on the GPIB side of the isolators in discrete logic, so that would continue working, as it does, but the system would hang when it can't shift out the received data to the processor. I'll take a look at that tonight.

author: MarkL
author_rank: Unknown
timestamp: January 14, 2014, 05:12:52 pm
content: Hmmm, and extra suspicious considering there's clocking and acknowledge signals being passed on that opto interface.Unfortunately, the service manual I got from the Agilent site is missing that part of the schematic (figure 8-32, sheet 2/5). Hopefully it won't be difficult to trace the signals looking at the actual board. Have fun this evening...