¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
Date

Re: 2440: GPIB

scott_dixon
 

If I recall correctly, the original poster had pretty modest GPIB requirements. I also found myself wanting to some simple interfacing with a couple of GPIB instruments that I have (a TDS540 and a Fluke 8842A). Not wanting to spend a lot of money on a commercial USB-GPIB bridge or dig up a computer with a largely obsolete interface to use some of the older GPIB interface cards, I decided to build the Elektor USB-GPIB project that a couple of other posters have already mentioned. I redesigned the board to use surface mount parts and built it for around (IIRC) $15 USD. It works OK for me. It is true that, like most of these projects I've looked at, it doesn't use the special GPIB interface chips. Instead it uses microprocessor GPIO pins in open collector mode. So it wouldn't do if you needed to run a GPIB bus with a lot of instruments on it. But for what it cost, I would be happy to dedicate one USB-GPIB adapter to each instrument and just run them all into a USB hub.
So far, I've managed to get this interface to do essentially every documented operation on my Fluke 8842A. And I've also managed to get it to run in hard copy mode from the TDS540 (to capture screen shots in EPS) as well as some simple exchanges of settings and waveform data. I have noticed that the firmware isn't really set up to send binary messages to the device from the host and I've been told by the author of the project that he has heard that sending large messages to the device has reportedly not worked well in some cases.
However, with those exceptions it has worked well and the firmware is open source if I get time to dig into it and perhaps fix any problems. For my needs it has sufficed. For running a large GPIB instrumentation installation, I doubt it would be adequate. It was never intended for that.

--- In TekScopes@..., David Gravereaux <davygrvy@...> wrote:

On 03/19/2013 08:21 PM, Chuck Harris wrote:
David Gravereaux wrote:
On 03/18/2013 10:34 PM, Chuck Harris wrote:
It's not like you won't have to be doing some polling
somewhere in your GPIB software no matter what the board.
Not one bit. An example to a DM5010 to setup async reading of measures:

-> ACV; RQS ON; MODE RUN
You can believe that if you want, but your OS knows the truth.

OS? take the problem back to the cause! With the prologix adapters
(both), what does it say when SRQ is raised by any device on the buss...
for whatever the reason?

nothing.


Re: 2440: GPIB

scott_dixon
 

If I recall correctly, the original poster had pretty modest GPIB requirements. I also found myself wanting to some simple interfacing with a couple of GPIB instruments that I have (a TDS540 and a Fluke 8842A). Not wanting to spend a lot of money on a commercial USB-GPIB bridge or dig up a computer with a largely obsolete interface to use some of the older GPIB interface cards, I decided to build the Elektor USB-GPIB project that a couple of other posters have already mentioned. I redesigned the board to use surface mount parts and built it for around (IIRC) $15 USD. It works OK for me. It is true that, like most of these projects I've looked at, it doesn't use the special GPIB interface chips. Instead it uses microprocessor GPIO pins in open collector mode. So it wouldn't do if you needed to run a GPIB bus with a lot of instruments on it. But for what it cost, I would be happy to dedicate one USB-GPIB adapter to each instrument and just run them all into a USB hub.
So far, I've managed to get this interface to do essentially every documented operation on my Fluke 8842A. And I've also managed to get it to run in hard copy mode from the TDS540 (to capture screen shots in EPS) as well as some simple exchanges of settings and waveform data. I have noticed that the firmware isn't really set up to send binary messages to the device from the host and I've been told by the author of the project that he has heard that sending large messages to the device has reportedly not worked well in some cases.
However, with those exceptions it has worked well and the firmware is open source if I get time to dig into it and perhaps fix any problems. For my needs it has sufficed. For running a large GPIB instrumentation installation, I doubt it would be adequate. It was never intended for that.

--- In TekScopes@..., David Gravereaux <davygrvy@...> wrote:

On 03/19/2013 08:21 PM, Chuck Harris wrote:
David Gravereaux wrote:
On 03/18/2013 10:34 PM, Chuck Harris wrote:
It's not like you won't have to be doing some polling
somewhere in your GPIB software no matter what the board.
Not one bit. An example to a DM5010 to setup async reading of measures:

-> ACV; RQS ON; MODE RUN
You can believe that if you want, but your OS knows the truth.

OS? take the problem back to the cause! With the prologix adapters
(both), what does it say when SRQ is raised by any device on the buss...
for whatever the reason?

nothing.


Re: 2440: GPIB

Chuck Harris
 

USB is not interrupt driven. When a USB device needs service
it has to cross its legs and wait until it is polled by the
Operating System.

Because it has to be polled anyway, for the low speed stuff
that goes over GPIB, it generally doesn't add all that much
complexity, or overhead to just setup a background task to
handle the SRQ polling, and other traffic with the Prologix.
Some people might call that sort of thing a driver.

Abdul could probably have setup the Prologix to send an 8 or
64byte interrupt packet to the USB controller when the OS
polls for such things, but it is still polling.

Perhaps if you ask nicely, he will do so? My gut feeling is
it will complicate the interface and make things harder for
the sort of work he intended the Prologix to do.

As to your rack full of equipment needs, the Prologix is not
capable, nor was it intended to be capable of doing that kind
of thing. As I recall, it only has 10ma drivers, GPIB calls
for 48ma drivers. It is a great little time saver, but it
was meant to drive a couple of instruments. As it happens,
it usually can do much more.

-Chuck Harris



David Gravereaux wrote:

On 03/19/2013 08:21 PM, Chuck Harris wrote:
David Gravereaux wrote:
On 03/18/2013 10:34 PM, Chuck Harris wrote:
It's not like you won't have to be doing some polling
somewhere in your GPIB software no matter what the board.
Not one bit. An example to a DM5010 to setup async reading of measures:

-> ACV; RQS ON; MODE RUN
You can believe that if you want, but your OS knows the truth.

OS? take the problem back to the cause! With the prologix adapters
(both), what does it say when SRQ is raised by any device on the buss...
for whatever the reason?

nothing.


------------------------------------

Yahoo! Groups Links




Re: Service Manual for early Tek 465 Scope

 

Al,

Try ko4bb.com. There is a low serial number 465 manual there.

--John Gord

--- In TekScopes@..., "Alan Klayton" <arklayton@...> wrote:

I found a 465 service manual (some 291 pages worth) on the web that is
labeled for SNs 250,000 and up. My scope is a much earlier one, SN in the
B032,000 range. Is there a service manual available, comparable to the one
I found, but for scopes with SNs below 250,000? If so, can I assume I would
so identify it just because it lacks the 250,000 and up label? Can someone
point me towards info on the major differences between early and late 465s?

Thx,

Al


Service Manual for early Tek 465 Scope

 

¿ªÔÆÌåÓý

I found a 465 service manual (some 291 pages worth) on the web that is labeled for SNs 250,000 and up. My scope is a much earlier one, SN in the B032,000 range.? Is there a service manual available, comparable to the one I found, but for scopes with SNs below 250,000? ?If so, can I assume I would so identify it just because it lacks the 250,000 and up label? Can someone point me towards ?info on the major differences between early and late 465s?

Thx,

Al


Help Tektronix 466 repair advice

 

Hey everyone,
Just wanted to introduce myself.

I am getting into electronics and have been toying with them for the last 8 months, and love it i want to learn MORE!!!

I have repaired 3 CRT arcade monitors thus far so by basic recapping and fault finding,

However i am little stumped as to where to start with this.

I brought it to learn how they work and gain some experience however i think it is broken i have taken a video of its symptoms if someone can point me in the right direction that would be fantastic, i pulled it apart to have a quick look and this thing has caps that are massive!

[URL="][/URL]

The Manual is here.
[URL="][/URL]


Thanks everyone i really want to get this going as i can use it for so many applications!

And like everything these days this is my hobby however money is tight these days i would go buy another but i can not afford it.

Thanks All


Re: 2440: GPIB

scott_dixon
 

If I recall correctly, the original poster had pretty modest GPIB requirements. I also found myself wanting to some simple interfacing with a couple of GPIB instruments that I have (a TDS540 and a Fluke 8842A). Not wanting to spend a lot of money on a commercial USB-GPIB bridge or dig up a computer with a largely obsolete interface to use some of the older GPIB interface cards, I decided to build the Elektor USB-GPIB project that a couple of other posters have already mentioned. I redesigned the board to use surface mount parts and built it for around (IIRC) $15 USD. It works OK for me. It is true that, like most of these projects I've looked at, it doesn't use the special GPIB interface chips. Instead it uses microprocessor GPIO pins in open collector mode. So it wouldn't do if you needed to run a GPIB bus with a lot of instruments on it. But for what it cost, I would be happy to dedicate one USB-GPIB adapter to each instrument and just run them all into a USB hub.
So far, I've managed to get this interface to do essentially every documented operation on my Fluke 8842A. And I've also managed to get it to run in hard copy mode from the TDS540 (to capture screen shots in EPS) as well as some simple exchanges of settings and waveform data. I have noticed that the firmware isn't really set up to send binary messages to the device from the host and I've been told by the author of the project that he has heard that sending large messages to the device has reportedly not worked well in some cases.
However, with those exceptions it has worked well and the firmware is open source if I get time to dig into it and perhaps fix any problems. For my needs it has sufficed. For running a large GPIB instrumentation installation, I doubt it would be adequate. It was never intended for that.

--- In TekScopes@..., David Gravereaux <davygrvy@...> wrote:

On 03/19/2013 08:21 PM, Chuck Harris wrote:
David Gravereaux wrote:
On 03/18/2013 10:34 PM, Chuck Harris wrote:
It's not like you won't have to be doing some polling
somewhere in your GPIB software no matter what the board.
Not one bit. An example to a DM5010 to setup async reading of measures:

-> ACV; RQS ON; MODE RUN
You can believe that if you want, but your OS knows the truth.

OS? take the problem back to the cause! With the prologix adapters
(both), what does it say when SRQ is raised by any device on the buss...
for whatever the reason?

nothing.


Re: 2440: GPIB

 

On 03/19/2013 08:21 PM, Chuck Harris wrote:
David Gravereaux wrote:
On 03/18/2013 10:34 PM, Chuck Harris wrote:
It's not like you won't have to be doing some polling
somewhere in your GPIB software no matter what the board.
Not one bit. An example to a DM5010 to setup async reading of measures:

-> ACV; RQS ON; MODE RUN
You can believe that if you want, but your OS knows the truth.

OS? take the problem back to the cause! With the prologix adapters
(both), what does it say when SRQ is raised by any device on the buss...
for whatever the reason?

nothing.


Re: 2440: GPIB

 

On 03/19/2013 06:24 PM, John Miles wrote:
And BTW, the OS isn't watching the hardware lines, the device driver is
through the adapter.
If it's running on the CPU, it's running on the CPU. At GPIB service rates, the benefits of doing so at ring 0 are either nonexistent, or arise from suboptimal architectural decisions at the application level.

We're not exactly talking gigabit Ethernet here...

My tennis court must be an airport tarmac then, cause I'm talking to 15
devices, not counting the 42 relays and 10 buttons through the 6 50M30s
on the routing box
And your goal in attempting to control all of that with a low-end $150 GPIB adapter intended for plotter emulation and basic instrument scripting was what? To save money?

-- john, KE5FX

I'm trying to help others from thinking it's a real GPIB controller that
will grow with their system. Same price and you can get a real NI
PCI-GPIB card off eBay.

The fact that it uses a tcp socket or an emulated serial port doesn't
matter to me. The command/response nature of their app layer protocol
as spoken over either duplex link layer was a limiting design decision.
The features of IEEE-488.1-1987, that more than likely can/will be used
by the devices you'll have to talk to, just don't fit inside their
protocol. Tek's "RQS ON" command for their 5000 plugins is a great
example of SOL with the Prologix. Out-of-band announcements of RQS with
status bits would bring that controller up at least a few more notches
in value and usability.


Re: 2440: GPIB

Chuck Harris
 

David Gravereaux wrote:
On 03/18/2013 10:34 PM, Chuck Harris wrote:
It's not like you won't have to be doing some polling
somewhere in your GPIB software no matter what the board.
Not one bit. An example to a DM5010 to setup async reading of measures:

-> ACV; RQS ON; MODE RUN
You can believe that if you want, but your OS knows the truth.

now when SRQ is raised with a status byte from it of 132 returned from
the serial poll, I call ibrd() then go back to WaitSRQ() and repeat for
each measurement taken.

I'm not ever asking if it is ready, it tells me.

The throughput is blazing and made a world of difference using the same
technique with my AA5001 for doing 3-D plots of freq/level/thd when the
number of points taken are quite high.

Also helps tremendously using this method when your count of involved
devices on your buss is high and you're interacting with all of them for
large test suites.

PS. the I/O model isn't USB, it's being emulated as a serial device
which is fine as it stands except for the application layer of the
prologix communication which forces you into command/response.
Actually it is. Standard USB devices cannot interrupt anything. They
are slaves in a master slave relationship. Unless the master asks, the
slave stays mum.

It may seem like your USB port interrupts the OS when you stick a thumb
drive, etc... into the jack, but that is only because the OS is polling
the USB ports until if finds one that talks back.

-Chuck Harris


Re: 2440: GPIB

 

cleyson@... wrote:
Hi

A cheaper and perhaps less complicated option would be to
either buy or build a RS232 or serial USB to GPIB converter.
There's a 4041 out there right now for $75 BIN.

:-)

-ls-


Re: 2440: GPIB

 

Hi

A cheaper and perhaps less complicated option would be to
either buy or build a RS232 or serial USB to GPIB converter.

There are a few open source projects, and of course the
Elektor GPIB converter. I also found this one the other day
which is worth looking at and C source code is available.

I used to use an NI IEEE488 PC card and either Microsoft
Quick-C or GWBasic to talk to GPIB instruments. It was
really easy back then. I've still got a few cards but no
ISA slots to plug them into.

Moving on a few decades, how about an Agilent 82357B USB to
GPIB converter ? Load up the Agilent IO bloatware and the NI
LabView bloatware talk to the converter through visual basic
or visual C and it takes days instead of minutes, talk about
a complicated path for 8-bit data to go through.

Another option would be to use serial to GPIB converter and
Goeff Graham's Maximite single board computer running MMBasic.
A basic interpreter running on a Microchip 80MHz MIPS processor.
I happen to have the Olimex version of Geoff's design and it's
pretty impressive and you don't need a PC :-)



Just my thoughts on cutting out bloatware and trying to make
life a bit easier for electronics engineers.

Chris

--- In TekScopes@..., Mark Richards <mark.richards@...> wrote:

I want to thank David Daniel and Chris Jones for their very kind and
helpful assistance with my prior operational questions for the 2440.

This question is regarding capturing the screen to a graphic image on my
workstation.

It seems GPIB applies (I've never used this prior), but is GPIB the only
option for a screen capture from the 2440 (other than the camera, of
course)?

Looking at GPIB, there's a rather expensive interface needed and then
rather expensive software.

Do folks in TekScopes who use GPIB prefer a certain option?

I am leaning towards building my own (there's a nice Elektor Magazine
project with firmware).

/mark


Re: 475 channel 1 intermittent

 

Like Tom says, you can use channel 2 to probe channel 1. Just be
careful not to allow the probe ground lead to touch anything except
ground.

I would take a careful look at the channel 1 BNC connector on the
inside of the chassis. Sometimes movement breaks the connection to
the center conductor.

A DC measurement of the collectors of Q172 and Q182 will reveal a lot.

If you can display a stable signal on channel 2 then the trigger
circuits are not the problem.

On Wed, 20 Mar 2013 01:23:11 -0000, "anson_williams@..."
<tractormananson@...> wrote:

My 475 channel 1 is pretty much dead it comes on intermittently mostly dead. channel 2 works perfectly. I had this problem since I got it but It was originally mostly working and has just gotten to the point it is unusable. I don't have a second scope so I will have to deal with only probing with the multimeter but I am unsure of where to start. Is my issue in the channel 1 vertical pre-amp or in a trigger? I've checked the power supply that is all working fine.


Re: 475 channel 1 intermittent

Tom Jobe
 

¿ªÔÆÌåÓý

A Common failure on 4xx scopes are the solder joints inside the input attenuators. They are white plastic rectangular things with 100X, 10X, etc marked on them.? They have component numbers between C30 and C37 between the two channels. The forum message archive has lots of discussion about fixing them, and it just gets down to a solder problem where the 6(?) pins come up and join the PCB inside the attenuators.
It's a simple fix if that is your problem, and in my experience cleaning the area to be re-soldered is the most critical thing as there is some kind of (silicone?) grease in there that needs to be kept away from the soldering touch up work.
tom jobe...
PS the little covers come off of the attenuators easily, look closely at how they attach. The attenuators just unplug from the vertical preamp.
?
?
?

----- Original Message -----
Sent: Tuesday, March 19, 2013 6:23 PM
Subject: [TekScopes] 475 channel 1 intermittent

?

My 475 channel 1 is pretty much dead it comes on intermittently mostly dead. channel 2 works perfectly. I had this problem since I got it but It was originally mostly working and has just gotten to the point it is unusable. I don't have a second scope so I will have to deal with only probing with the multimeter but I am unsure of where to start. Is my issue in the channel 1 vertical pre-amp or in a trigger? I've checked the power supply that is all working fine.


Re: 475 channel 1 intermittent

 

¿ªÔÆÌåÓý

Use channel 2 to trace the signal in channel 1. Work through to the channel switch.
?
Tom
?
?

----- Original Message -----
Sent: Tuesday, March 19, 2013 9:23 PM
Subject: [TekScopes] 475 channel 1 intermittent

?

My 475 channel 1 is pretty much dead it comes on intermittently mostly dead. channel 2 works perfectly. I had this problem since I got it but It was originally mostly working and has just gotten to the point it is unusable. I don't have a second scope so I will have to deal with only probing with the multimeter but I am unsure of where to start. Is my issue in the channel 1 vertical pre-amp or in a trigger? I've checked the power supply that is all working fine.


Re: 2440: GPIB

John Miles
 

And BTW, the OS isn't watching the hardware lines, the device driver is
through the adapter.
If it's running on the CPU, it's running on the CPU. At GPIB service rates, the benefits of doing so at ring 0 are either nonexistent, or arise from suboptimal architectural decisions at the application level.

We're not exactly talking gigabit Ethernet here...

My tennis court must be an airport tarmac then, cause I'm talking to 15
devices, not counting the 42 relays and 10 buttons through the 6 50M30s
on the routing box
And your goal in attempting to control all of that with a low-end $150 GPIB adapter intended for plotter emulation and basic instrument scripting was what? To save money?

-- john, KE5FX


475 channel 1 intermittent

 

My 475 channel 1 is pretty much dead it comes on intermittently mostly dead. channel 2 works perfectly. I had this problem since I got it but It was originally mostly working and has just gotten to the point it is unusable. I don't have a second scope so I will have to deal with only probing with the multimeter but I am unsure of where to start. Is my issue in the channel 1 vertical pre-amp or in a trigger? I've checked the power supply that is all working fine.


Re: 2440: GPIB

 

On 03/19/2013 04:54 PM, John Miles wrote:
Well, no, it isn't "telling you" anything The OS is doing the polling on your behalf in a way that makes it look asynchronous to your code, but is not
Let's define what asynchrous means, shall we?

Asychronous means at it's core, that without having to ask, you are
given through an alert mechanism.

And BTW, the OS isn't watching the hardware lines, the device driver is
through the adapter.

My tennis court must be an airport tarmac then, cause I'm talking to 15
devices, not counting the 42 relays and 10 buttons through the 6 50M30s
on the routing box


Re: Tektronix 221 BIN $60

Richard Solomon
 

Looks like it got dropped.

73, Dick, W1KSZ


On Tue, Mar 19, 2013 at 4:59 PM, jayw_comark <jayw_comark@...> wrote:
?

No affiliation.

Ebay 121083990160

Jay



Tektronix 221 BIN $60

 

No affiliation.

Ebay 121083990160

Jay