TDS460 Hardcopy

[T3sl4co1l]

So I've built up a GPIB-serial interface, based on:
https://github.com/Galvant/gpibusb-firmware
(somewhat cleaning up the code and porting it to the AVR platform I happen to be using).  I've got it TALKing with my TDS460 scope, but I'm confused that the HARDCopy command seems to do nothing.  From remote via GPIB, or doing it manually on the scope (in TALK only mode).

In fact, I put some LEDs on the GPIB bus to see what's going on, and setting HARDCopy doesn't seem to do anything at all.  Actually the odd thing is it does exactly one thing: when set to TALK mode, the scope asserts two data pins, and nothing else, no control lines at all (at least not for very long, as I could miss a short pulse, I really should scope the lines to make sure).  So I'm really confused how it's supposed to send hardcopy to, say, a printer, if it's not asserting any control lines?  Did they do something weird for that mode?...

The important part seems eminently functional though, so that's nice:



It's been way too long that I've not had digital output from this thing!

Tim

[Tony_G]

I don't have one but is the TDS460 one of those rare instruments that requires a specific GPIB address, like 31, to do talk only? Are you asserting the handshake lines (NRFD & NDAC) appropriately to make your GPIB adapter appear to be a listener?

You probably are but I thought it might be helpful to ask.

TonyG

[james_s]

I was just playing with this on a TDS410A last night, this instrument is a little newer than the TDS460. What I found is that the scope had to be set to talk-only and then I tried using the 7470A plotter emulator program with mixed results. I was unable to get it to respond but then using a terminal I gave it a ++read command and managed to get the scope to spit out the HP-GL data which I could then paste into a text file and open in the plotter emulator to render it. Then once I managed to get the plotter emulator to automatically receive and plot the image but it only worked once for me. I noticed while reading it from the terminal I often had to execute ++read multiple times to get all of the data.

At that point it was getting late and I didn't really need to plot from that scope anyway so I put it away but I do intend to mess with it again at some point. I also have an older TDS460 that I can try it with but my first priority with that scope is to fix whatever is causing SPC to fail. I suspect there's some quirks related to timing or some other aspect with these scopes. The 7470A emulator with the AR488 Arduino based GPIB interface works flawlessly with my 8594E but I've had much less success with Tek scopes.

[T3sl4co1l]

Ah, that does it, +read makes it work. Strange, I thought the scope would assert lines as the talker, not wait for something else to.

Now to capture some binary data...

Tim

[james_s]

Now that you mention it, that is very odd. I wonder how it works with a real printer?

If you set it to output HP-Gl to a plotter you don't have to capture any binary data, it's just plaintext.

[T3sl4co1l]

I may yet do that; bitmap output is being weird.  Fixed one problem, overloading the serial buffer.  Was getting 8kB files.  Simple enough, add a delay to purge the buffer and now I'm getting the 38kB I should be.  Except... it's actually stuffing bytes every so often, so the output ends up skewed heavily to the right.  Need further testing to see what's going on.  Actually quite impressed I can save binary data at all with dumb old Hyperterminal.

Also weird that the scope displays a "hardcopy in progress" dialog, which flickers rapidly as data is being read out.  Wonder if that's a side effect of the interface's logic not quite being to spec, or if it does that normally. Just interesting.

Tim

[james_s]

Maybe the printers and plotters assert a line whenever they are ready? It seems they are designed to talk directly to a printer that is the only other device on the bus as it is not addressed. Anyone have any sort of compatible printer with a GPIB interface? I'd be curious to see how it actually works. Is the plotter emulator open source? This seems like something it could be fairly easily tweaked to handle.

[T3sl4co1l]

Think the address still has to match, but yes, it appears the read device asserts lines (when I send a +read, several control lines assert).

If you're curious, the stuffed bytes looks like this:



Tim

[T3sl4co1l]

Buttoned up the interface with some classic copper-clad paneling:









Don't have a schematic handy.  The connection is unremarkable: an ATXMEGA64D3 with crystal, two ports wired directly to GPIB, one serial port, a MAX232 and 3.3 and 5V regulators.

The external headers on ribbon are just taking the GPIB pins out directly, so I can view the signals on the LED board.

The 6-pin header on the side is the AVRISPMKII programming header (man, I've had this programmer for quite a while now, come to think of it; crude as it is, with no debug support even..).  Which of course on XMEGA is PDI, only 4 wires are used.

Early (working, but I'd still like to do more refactoring, and optimization not that it needs it) code here:
https://github.com/T3sl4co1l/GPIBSerial

Which, on a related note -- Github has (correctly) picked up on this being a branch of the original codebase.  But, how?  Is this normal?  I have some original files in the project folder; I created the git repo late, after modifying the active files.  Presumably it isn't picking up on those.  Is it looking at all files in the folder, even those not tagged for the repo?  Did I do something horribly, terribly dumb when committing/pushing/merging/whatever the repo?  Is this something insidious that git does, that nobody talks about...or automatically understands and accepts and I'm out of the loop?

Tim

[maginnovision]

Your screen shot seems to have 78 extra bytes unless I missed something. Total should be 9600 and I see 964E. Oh never mind I thought I read you were receiving all the bytes but missed that it's adding some. Is that pretty consistent?

[james_s]

Did you happen to note which lines need to be asserted in order for the scope to start dumping data? I'm wondering if this is something that can be fixed in the AR488 (or other) GPIB interface code, or if it's something the plotter emulator needs to be doing. I do suspect this is what's going on, the plotter emulator is sitting there waiting for the data to be pushed but the scope is not sending it until a ++read command is sent.

[T3sl4co1l]

Yeah, whatever (+)+read asserts, does it.  Check the logic in gpib_read().

Tim

[Tony_G]

Taking a quick look at the code shows that it doesn't set NRFD & NDAC for reading until you issue the read command. If HARDcopy expects to send to a listener then you need to have those set before the talker will transmit. You might want to add a listen command that automatically reissues the read command after an EOS arrives.

TonyG

[T3sl4co1l]

Hmm, I wonder if that's what the currently-unimplemented ++lon command is supposed to do.  (Anyone have a Prologix to test..?)

Tim

[Bark]

T3sl4co1l, I love the way you hand built this.  Like a blacksmith forging something out of raw metal.  It may not be the most beautiful, but it works and I'll bet it would survive a tornado! 

[james_s]

Hmm, I wonder if that's what the currently-unimplemented ++lon command is supposed to do.  (Anyone have a Prologix to test..?)

Tim

Ah! ++lon is Listen Only, that certainly sounds promising.

[james_s]

Did you look at what serial instructions the plotter emulator is sending to the interface? I've done a bit of experimenting and found that if I request a plot NDAC asserts and the scope starts sending the data, but the data ends up being interpreted as the instrument state. If I just put it in listen mode then NDAC is never asserted and it just sits here. I had it in my head that ++lon was not implemented but now that I look I realize that it is. I'm not 100% sure whether the problem is with the interface code or the plotter emulator code. The latter says that it's open source but I didn't actually see where to get the code.

*edit: Oh, so the KE5FX source is included right there in the installation folder. Of course I don't have the software needed to compile it anyway but at least I can take a look.

[Tony_G]

If the emulator code you're talking about is KE5FX's then the source is placed in the same directory that it is installed in.

From quickly looking at his code, when you select the 'listen only' acquire menu option it eventually ends up in 7040.cpp:*async_read() and that eventually calls gpiblib.cpp:GPIB_read_ASC(). I'm assuming that this device looks like a Prologix so as long as the Connect.Ini file is setup for a Prologix then GPIB_read_ASC() should issue a '++read'. The code must do something w.r.t the timeout but I didn't go looking for that. That '++read' should result in the NDAC & NRFD handshaking lines being asserted properly.

If it's just acting a serial device then the path is probably similar but from the comments in gpiblib.cpp there might be another method that has a larger buffer allocated.

BTW it doesn't appear that the emulator code uses '++lon' anywhere so it shouldn't matter that it isn't implemented/correct.

BTW #2 from looking at the makefile is uses VC++ 2013 - It should still work under VS 2019 Community but for best compat you should install the downlevel toolsets and set those up in the makefile - If you have an MSDN subscription then VS 2013 is still available for download and you could just run nmake with that toolchain.

TonyG

[james_s]

Yeah I figured that out after looking around for a while, I guess I just assumed the source would be in a separate folder at least.

The interface I'm using is this: https://github.com/Twilight-Logic/AR488

It does emulate a Prologix interface although now having a real Prologix interface to compare to I can't say how accurate it is. I'm too tired to mess with this more tonight but it's really bugging me that it won't work. There are loads of these old TDS scopes out there and GPIB was standard on the 400 series so it seems like an obvious target to support. Also I know it's *so* close to working since I can convince the scope to dump the data which I can then paste into a file and render properly.

[Tony_G]

The v140 C++ build tools in VS 2019 Community should build it from the command line - I've always been meaning to go in and create a VS Project System implementation for the entire library but that just never got to the top of the list of things to do next.

If I had to take a wild guess, there is something that faults out due to the Prologix emulation and that is causing the '++read' to not be issued - no idea what it would be though and then code is rather long so you might just have to end up getting it under the debugger and breakpointing in the menu item and stepping through.

TonyG

[icezebra]

I came across this tool several years ago. 

http://mkelzenb.caltech.edu/software/TDSHC/index.html

-It is well crafted and feature rich.
-It works with TDS420A/460A equipped with a GPIB option card (Be sure to set GPIB for talk AND listen) and many other TEK scopes with Hardcopy
-It works on Windows 7 and Windows 10
-It work with NI-GPIB-USB-B


Recently the author added a full and a light install version.
The full install gets the correct vintage of drivers installed, and you want that, because getting them all downloaded and lined up manually is a 1/2 day job. 
Furthermore, one of the drivers is no longer available from NI (for your own protection) knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019QOfSAM

On a somewhat related note, be aware that if you have an NI GPIB-USB-B that the NI-488.2 driver will not work beyond version 17.6
www.ni.com/en-ca/support/documentation/supplemental/06/ni-488-2-supported-versions-for-gpib-devices-and-modules.html

  A big shout-out to Mike Kelzenberg for sharing such a useful software tool for free.  Keeping a library of scope shots while I am developing technology is exceedingly helpful, and this tool completely eliminates the floppy disk/sneakernet thing.  What a pleasure to use!

[T3sl4co1l]

Cool!  That should be helpful to those with NI adapters!

More directly, I forgot that I even started this thread -- the latest update is here:
https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg3569035/#msg3569035
I wrote a very simple, more of a script really, to capture from a TDS4xx scope.  The port name can be specified at the command line with any Windows path, so if NI-GPIB or Prologix works the same way and manifests as a virtual COM port or the like, and uses the same command set (which, I think my device is Prologix compatible, don't know about others), it should Just Work(tm).

A big shout-out to Mike Kelzenberg for sharing such a useful software tool for free.  Keeping a library of scope shots while I am developing technology is exceedingly helpful, and this tool completely eliminates the floppy disk/sneakernet thing.  What a pleasure to use!

Not to mention those of us with the non-A models that are otherwise forced to use photographnet!

Tim

[icezebra]

"photographnet" lol
Done that too because effing with the floppy is just such a pain, and "Office Lens" on iPhone is free, and pretty good at removing glare if you take shots at an angle and let Office Lens rubber sheet them. Android too...

https://support.microsoft.com/en-us/office/microsoft-lens-for-ios-fbdca5f4-1b1b-4391-a931-dc1c2582397b

https://apps.apple.com/us/app/microsoft-lens-pdf-scan/id975925059
https://play.google.com/store/apps/details?id=com.microsoft.office.officelens&hl=en_US&gl=US

[james_s]

I don't find the floppy to be a pain on the scopes that have it. I use the floppy all the time on my TDS3000, I keep a disk in the front cover and I have a little slimline USB floppy drive I use with my laptop.