开云体育

Interleaved.

On 3/22/2025 10:11 PM, Radu Bogdan Dicher via groups.io wrote:

Thank you, Harvey.

If I understand correctly, you're saying that the # GPIB connection may
"port" another, "hot swapped" instrument to the same # GPIB?

Nope.? The address switches on the instrument control the address (much like I2C does it).

HPIB has three functions, all of which can be separate: listener, talker, controller.? For listener and talker the address is set on the instrument.? For controller, there is one only if the instruments are not dedicated listener and controller.

For instance, a meter can be designated a talker, and put into talker only mode (interface talks only, ignores address).? The printer can be put into listener mode (interface listens only, ignores address).? Controller not needed.

The way the HPIB bus works is that nothing is assigned a role, every instrument/device has a hardware selected address.? The controller knows (because it's been programmed to) what instruments are where.? In the previous example, the controller (now present) would address the meter as a talker, the printer as a listener, and then allow the transfers to occur.? When the controller decides (by monitoring status lines) that the transfer is done, the controller then de-addresses the listener and talker both.

I got impatient after posting this and thought I'd play with it a little
more and I connected the GPIB interface to the TDS754D then booted it and
it just landed on #4 GPIB. Not sure why on #4 (whether it had to be
"elevated" at #4 and why there's three below that having nothing
connected).

Go to the manual or read the back panel.? In my TDS640A, like many other instruments with a display, the functions of the HPIB bus are hidden in a menu.? For older instruments, the settings are on the dip switch.

In your case, address #4 was set as a default.? IIRC, it can be any number from 1 to 32. (0 is reserved).

With switches, the other three are typically listen only mode, talk only mode, and I'm not sure about the third one.

Generally speaking, I'm seeing different instruments landing on
a pretty wild "#" GPIB port. I'm always doing a "list" to inquire which
GPIBs have something attached.

The HPIB system was designed for a well determined system.

What you'd have to do to enable some form of hot swap (I think the hardware would forgive it), is to poll instruments periodically, to ask them what they are.? You'd then need a table of active devices.? Any new device would show up at a different address (assuming you did that),? and you'd have to activate that in your software to deal with that instrument.? That makes it a dynamic system.

HPIB is not really designed for that, but you can make it play nice.

Now this assumes that you have a standard 488 bus controller, such as HP.? The microprocessor based USB to 488 bus controllers work a bit differently, since there's only listener and talker functions to activate,? the controller is a little less of a controller, since it doesn't manage conversations, just roles.

Hope that helps a bit.

Harvey

Radu.

On Sat, Mar 22, 2025 at 6:54?PM Harvey White via groups.io <madyn=
[email protected]> wrote:

The 488 bus is an addressed bus, which means recognizing an address on a
bus and having something respond (think I2C for an example).

So when you hot swap instruments, assuming that you don't glitch
something, then an existing address doesn't respond, and a new address
doesn't yet get recognized.

The controller (and I think it doesn't , unlike USB) start a new connect
sequence. You'd have to program it.

That means, to autoconnect, you'd need to be polling the interfaces (all
of them), and when one doesn't respond, you need to forget it. You then
need to scan for a new device. (and 488 has, IIRC, none of that),
although the controller by polling each device.

So somewhat different there, and not like USB.

Harvey


On 3/22/2025 7:47 PM, Radu Bogdan Dicher via groups.io wrote:

Hi all,
As I'm exploring GPIB in my environment on multiple instruments, a

newbee question - is GPIB essentially hot swappable?

Differently put, can I typically just hook it up to an instrument that's

running and expect it to smoothly connect? Or is it typically better to
connect GPIB while the instrument is off, then turn it on, so it'd scan its
"peripherals" during the booting sequence and this would guarantee it's
connecting with no issues?

I assume there's a rule of thumb, instead of a situation where maybe all

instruments may be different and it's hard to tell what's the best approach.

I've connected it plenty before, but 95% of the time it's been hooked up

to one instrument and so "hot swapping" wasn't a consideration.

This is for a TDS754D, reason I'm posting on this board, but I'm looking

for some input applicable to any instrument/brand.

Thank you,
Radu.

Perfect! Thanks a bunch for all that info!

I also am a bit miffed that Tek nerfed their forums, there was good info there, they could have at least archived it.....


Jared.

Steve and all,
Thank you for elaborating on the topic. It's really useful to put some good
detail and get a better understanding of the general rules and mechanisms
of the protocol. Steve - thank you very much for pointing me to your
excellent manual.

I am aware of setting a certain "GPIB address" (I've set it myself on a few
instruments, and that was in order to avoid conflicting same addresses on
multiple units in my environment). I decided as a matter of "intake" to set
a unique address to each instrument that lands at my bench and may stay.

For the connected TDS754D, here's what my list of devices looks like (see
below). Please note though, that the GPIB address set for the scope is
"14," and not "4" (which is the reason why I interpreted it as "landing" on
#4, as opposed to a deliberate process). I believe some GPIB addresses for
different instruments previously connected to the computer would be "07,"
"08," "29" below (I'm not sure why there's two GPIB_07...). The TDS754D
seems to not report its own GPIB #(?)... It does state its firmware version
though.

(visa) list
( 0) USB0::0x03EB::0x2065::GPIB_07_55137323934351C07071::0::INSTR
( 1) USB0::0x03EB::0x2065::GPIB_07_75935323239351A0F1F0::0::INSTR
( 2) USB0::0x03EB::0x2065::GPIB_08_55137323934351C07071::0::INSTR
( 3) USB0::0x03EB::0x2065::GPIB_29_55137323934351C07071::0::INSTR
( 4) USB0::0x03EB::0x2065::TEKTRONIX_TDS_754D_0_CF_91.1CT_FV_v6.3e::0::INSTR
(visa)

My initial question was meant to ask a slightly different thing though (I
did a bad job explaining). Is it customary to just plug GPIB into a running
instrument while making sure the address is different than any other
(previously) connected instrument, and then start to talk to the
instrument through it? Or doing it while the instrument is off is a safer,
"best practice" procedure?

I probably am overthinking this, but I typically try to learn a process
correctly, rather than trial and error, if I can. Also, hopefully my
question is better phrased this time around.
Radu.

<>
Virus-free.www.avg.com
<>
<#m_-1007817960827559090_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Mar 23, 2025 at 4:27?AM Steve Hendrix via groups.io <SteveHx=
[email protected]> wrote:

On 2025-03-22 10:11 PM, Radu Bogdan Dicher via groups.io wrote:

If I understand correctly, you're saying that the # GPIB connection may
"port" another, "hot swapped" instrument to the same # GPIB?

GPIB doesn't have the concept of a "connection". Each device sets its
own address, sometimes via DIP switches, sometimes, via front panel
commands, etc., but that instrument "knows" its own address. It's up to
the user to ensure there are no collisions. There are 31 available
addresses - often set by 5 DIP switches. The 32nd address is reserved as
described below. The whole concept is quite different from either USB or
Ethernet addressing.

To start a data transfer (which may be a command, or some sort of data),
the Controller (usually a PC adapter of some sort these days; could be
an internal board with special drivers, or external like my KISS-488)
issues a command to one address (maybe even itself) to become the
Talker, and to one or more devices (instruments) to become a Listener.
The talker then proceeds to send bytes, ending with a specified
termination condition. The Controller usually then turns the bus around,
addressing e.g. the instrument to become Talker, and e.g. itself as
Listener, and data flows the other way. at the end, it issues Untalk and
Unlisten commands (that 32nd address).

I include a fairly detailed discussion of GPIB concepts in the beginning
of the manual for my KISS-488, which you can download freely at



Steve Hendrix

Tek really messed up when they killed the old site. Maybe if more people complained (I did, a bit) they would backtrack ?

I dumped all my notes and screenshots to my website,
and here's also a copy of the important bit:
****
Console port - Option 13 Board - (Signal Name)
A10 - 1 - (D24)
B10 - 3 - (D25)
A9 - 5 - (D26)
B9 - 7 - (D27)
B8 - 2 - (D28)
A7 - 4 - (D29)
B7 - 6 - (D30)
A6 - 8 - (D31)

B1 - 21 - (A1)
A1 - 23 - (A2)
B2 - 25 - (A3)
A2 - 22 - (A4)
+5V (B6) - 24 - (A5)
GND (A3/A8) - 26 - (A6)

B5 - 12 - (INT#)
B4 - 15 - (IOCS#)
A5 - 16 - (SYSRESET#)
A4 - 17 - (RNW)

A3, A8 - 9, 13, 19 - (GND)
B6 - 10, 20 - (+5V)

B3 - not connected

not connected - 11 - (DS#)
not connected - 14 - (DSACK0#)
not connected - 18 - (AS#)

Notes:
- As displayed in the "TDS520B Mod CM" service manual, On the console port "B" is the top side of the processor board.
- Signals A5 (Pin 24) and A6 (Pin 26) need to be set to +5V and Gnd to make sure the serial port of the option 13 board is selected.
- The 3 ground pins (9, 13, 19) should be connected on the option 13 board, so normally you only need to connect one of these to the console port connector.
Nevertheless I connected them all.
- The 2 +5V pins (10, 20) should be connected on the option 13 board, so normally you only need to connect one of these to the console port connector.
****

On 2025-03-22 10:11 PM, Radu Bogdan Dicher via groups.io wrote:

If I understand correctly, you're saying that the # GPIB connection may
"port" another, "hot swapped" instrument to the same # GPIB?

GPIB doesn't have the concept of a "connection". Each device sets its own address, sometimes via DIP switches, sometimes, via front panel commands, etc., but that instrument "knows" its own address. It's up to the user to ensure there are no collisions. There are 31 available addresses - often set by 5 DIP switches. The 32nd address is reserved as described below. The whole concept is quite different from either USB or Ethernet addressing.

To start a data transfer (which may be a command, or some sort of data), the Controller (usually a PC adapter of some sort these days; could be an internal board with special drivers, or external like my KISS-488) issues a command to one address (maybe even itself) to become the Talker, and to one or more devices (instruments) to become a Listener. The talker then proceeds to send bytes, ending with a specified termination condition. The Controller usually then turns the bus around, addressing e.g. the instrument to become Talker, and e.g. itself as Listener, and data flows the other way. at the end, it issues Untalk and Unlisten commands (that 32nd address).

I include a fairly detailed discussion of GPIB concepts in the beginning of the manual for my KISS-488, which you can download freely at

Steve Hendrix

On Sun, Mar 23, 2025 at 03:11 AM, Radu Bogdan Dicher wrote:

booted it and it just landed on #4 GPIB. Not sure why on #4

The address is selected in the scope (like most other instruments) and you don't have to reboot if you change it.
If you have National Instruments GPIB hardware you can try and play with this

/H?kan

Apologies for the gravedig, but does anyone have this pinout for the J40 Debug port to Option 13 adapter? Seems the Tek website links no longer work...

I'm currently designing a USB debug adapter and want to check the pinouts to make sure mine are correct.


Thanks!
Jared

Wolfgang the original Tektronix relays can often be reworked, eg exercise contacts or clean with Iso alcohol, contact cleaner and paper strip.

See threads years ago

Jon

Thank you, Harvey.

If I understand correctly, you're saying that the # GPIB connection may
"port" another, "hot swapped" instrument to the same # GPIB?

I got impatient after posting this and thought I'd play with it a little
more and I connected the GPIB interface to the TDS754D then booted it and
it just landed on #4 GPIB. Not sure why on #4 (whether it had to be
"elevated" at #4 and why there's three below that having nothing
connected). Generally speaking, I'm seeing different instruments landing on
a pretty wild "#" GPIB port. I'm always doing a "list" to inquire which
GPIBs have something attached.
Radu.

On Sat, Mar 22, 2025 at 6:54?PM Harvey White via groups.io <madyn=
[email protected]> wrote:

The 488 bus is an addressed bus, which means recognizing an address on a
bus and having something respond (think I2C for an example).

So when you hot swap instruments, assuming that you don't glitch
something, then an existing address doesn't respond, and a new address
doesn't yet get recognized.

The controller (and I think it doesn't , unlike USB) start a new connect
sequence. You'd have to program it.

That means, to autoconnect, you'd need to be polling the interfaces (all
of them), and when one doesn't respond, you need to forget it. You then
need to scan for a new device. (and 488 has, IIRC, none of that),
although the controller by polling each device.

So somewhat different there, and not like USB.

Harvey


On 3/22/2025 7:47 PM, Radu Bogdan Dicher via groups.io wrote:

Hi all,
As I'm exploring GPIB in my environment on multiple instruments, a

newbee question - is GPIB essentially hot swappable?

Differently put, can I typically just hook it up to an instrument that's

running and expect it to smoothly connect? Or is it typically better to
connect GPIB while the instrument is off, then turn it on, so it'd scan its
"peripherals" during the booting sequence and this would guarantee it's
connecting with no issues?

I assume there's a rule of thumb, instead of a situation where maybe all

instruments may be different and it's hard to tell what's the best approach.

I've connected it plenty before, but 95% of the time it's been hooked up

to one instrument and so "hot swapping" wasn't a consideration.

This is for a TDS754D, reason I'm posting on this board, but I'm looking

for some input applicable to any instrument/brand.

Thank you,
Radu.

The 488 bus is an addressed bus, which means recognizing an address on a bus and having something respond (think I2C for an example).

So when you hot swap instruments, assuming that you don't glitch something, then an existing address doesn't respond, and a new address doesn't yet get recognized.

The controller (and I think it doesn't , unlike USB) start a new connect sequence.? You'd have to program it.

That means, to autoconnect, you'd need to be polling the interfaces (all of them), and when one doesn't respond, you need to forget it.? You then need to scan for a new device.? (and 488 has, IIRC, none of that), although the controller? by polling each device.

So somewhat different there, and not like USB.

Harvey

I recently acquired a PG502 from Tek surplus (aka Country Store) and found several setting to be intermittent. Expecting that a good cleaning would be in order, I was astonished to find that cam switch drum appears to be decomposing. It looks dull, powdery and parched like mud flats after a dessert gully washer!
In fact, there was a lot of fine debris on the contact board. Cleaning the board and the contacts made no difference because the cam lobes are deteriorating. I have not touched the cam drum with any cleaner or other chemicals.
This unit was used in the production test area; perhaps its entire life. It was last cal’d June 2022. Perhaps it is the result of 45 years of continuous up time in a rack.

I have never seen a cam drum look like this.

Has anyone seen such a thing?
(See photo gallery for “Decomposing Cam Switch Drum.”)

Hi all,
As I'm exploring GPIB in my environment on multiple instruments, a newbee question - is GPIB essentially hot swappable?

Differently put, can I typically just hook it up to an instrument that's running and expect it to smoothly connect? Or is it typically better to connect GPIB while the instrument is off, then turn it on, so it'd scan its "peripherals" during the booting sequence and this would guarantee it's connecting with no issues?

I assume there's a rule of thumb, instead of a situation where maybe all instruments may be different and it's hard to tell what's the best approach.

I've connected it plenty before, but 95% of the time it's been hooked up to one instrument and so "hot swapping" wasn't a consideration.

This is for a TDS754D, reason I'm posting on this board, but I'm looking for some input applicable to any instrument/brand.

Thank you,
Radu.

Hello everyone,

its been a while since my last post. There were a lot of things which kept me from posting an update.
Nevertheless, I finally managed to do some measurements of my relay replacements. The VNA at work was blocked all the time. Therefore, I had to find a different way to measure the relays. In the Album there are now the measurement result of almost all possible combinations you can have in a DPDT relay. /g/TekScopes/album?id=299851

All in all the replacements perform quite a bit worse than the originals. This is not surprising as the original relays are close to perfect in terms of HF coupling (tiny cross sections with relatively large gaps between adjacent parts). The PCB in contrast provides 'long' traces in parallel.

As the VNA was not available I had to measure the relays with a automated setup composed of my 60MHz function generator as signal source and my digital oscilloscope as measurement device. Due to the noise floor of the oscilloscope and the low output level of the funtion generator dynamics of the measurement was not crazy high.
To get an impression how much coupling would be possible at the given distances between pins, I always measured one complete trace without any DUT at all (the traces called 'Fixture').
Nevertheless, the measurements always show that the replacement performs not as good as the original relay, but I think this is the price you will have to pay to get a relaibly switching relay.

Regarding leckage current I will try to perform a few measurements to see if the required 0.2nA is achivable or not. I hope the next update will not be delayed as much as this one.

Right now I have 4 unpopulated panels left over (each with 36x 148-0034-00 and 30x 148-0035-00 relays). Plus some additional ones of the first panel which were already populated with SMT components.
If you are interested, send me a message off list with your needs and we can discuss how I can help you.

Best regards,

Wolfgang

Wamor,

If you see the service manual, there is an annotation: "Version ID resistor
placement: place U4 & R12-R17 only on boards that have exceeded the ID
number 11110XXX. In this case, the version number is decoded via pins 2,3,4
of U4. R7,R9,R11 are not placed & pins 5-9 of U3 are wired high"

Regarding TDS640 ID,
I sent the ID from TDS640A to you. I do not have them for TDS640, but I can
see that TDS520,TDS540, and your TDS620 have the same IDs.

Regarding AUX and Ch,
Aux input has a simplified schematics than Channel on two channel boards.
Maybe new firmware will fix the wrong names. And maybe some additional
calibrations will be needed after the wrong hardware error will be fixed.

Regarding NVRAM backup,
See tektool program here:
!-(firmware-flash-tools-for-old-tds-series)/
This one do not work on my PCII/IIA card, which i bought for Field
Adjustment, but works on Prologix, as i know.

WBR,

Peter

сб, 22 мар. 2025?г. в 18:27, wamor2006 via groups.io <tektronix=
[email protected]>:

Hello all,

I have upgraded my TDS620 scope to display 4 (=>TDS640) by reconfiguring the acquisition board resistors.
The scope is reporting to be a TDS640 and the channels are visible and working.
Only in the log-file the scope is reporting that the number of channels is incorrect every time at startup.
I’ve learned on this forum that the firmware for the TDS640 differs from the TDS620 firmware but that version-numbers is the same.
Could someone maybe supply me with the TDS640 firmware?

Regards,

Wamor

Hi Peter,

No problem, your are not encouraging me. This only gives me more energy to sort this out.
Could you give me the ID to set with U3 for the TDS640 which you have in your table?
And maybe also for the TDS620?
I saw some pictures in the internet of the TDS640 CPU board and there the resistors connected to U3 are the same as on my TDS620 CPU board?
When I look at the pictures I also see that the version numbers of the software are the same
Another reason that H?kan is right.
What I also see on my scope that the extra channels are identified on the screen as AUX1 and AUX2 and not CH3 and CH4 what I was expecting.

Yes, your right. I need to find the firmware for the TDS640 then. I will post a new question on this group for that.
Maybe I could remove the resistors connected to U3 and connect switches to check each configuration.
Its only 7 new possibilities. I hope I don't destroy my scope when doing this. Or corrupt the NVRAM.
I did the same with the acquisition board which worked really well.
I am still busy creating a program in Labview to backup the NVRAM using the Prologix GPIB interface.

Regards,

Wamor

Bob,

Yes, thank you. I see that I concluded that it doesn't have sections 8 and 9 because I was looking at the end of the PDF, which are the Change Information pages. I do see the duplicate pages.

Without a copy of the original manual (or an original manual itself) I can't tell what else might be incorrect with the online copies. Since many of the pages of the online copies are partial pages, I'd have to compare the pages in the online PDFs to an original manual. Perhaps someone out there could do that, but since the 7934 is pretty rare, I doubt that there is anyone who is paying attention to this thread who will do that.

I have sent pp. 31, 6-22 and 6-23 to Mark, the OP. That will have to suffice, for now. I may upload my revised PDF that contains those three missing pages. I can scan my original that is a later revision, but that will take a lot of time due to the fold-out pages.

DaveD
KC0WJN

--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Hi Wamor,

As far as I see the IDs on my boards, in my table, and your ID, the ID
refers to something else. TDS520,TDS540,TDS620 use the same ID. Sorry to be
encouraging.
Maybe, H?kan is right. The only question is, where can we get the firmware
from the TDS640?

I'm doing similar research: how to convert TDS544A to TDS644A. The processor
board is the same, the Acquisition board is different. The firmware of the
TDS544A board does not see the Acquisition board from the TDS644A

Regards,

Peter

пт, 21 мар. 2025?г. в 15:57, wamor2006 via groups.io <tektronix=
[email protected]>:

The copy I look at came from this link:



Part No. 070-5880-00
MANUAL Product Group No. 42
First Printing May 1986

It has what I assume is section 8, which isn't numbered, then section 9 followed by a section of Manual Change Information then the duplicate pages.

Bob