Need help with KE5FX plotter emulator and Tek TDS540 Hardcopy

[dl6lr]

First I want to thank you for your efforts. I have built some AR488 with 32U pro micro boards (Artags design) and contributed the 3d printed case for it in EEVBlog. I used the version 0.49.12 from your site but as I ran into some issues, I compiled the latest with no change (besides having ++help). I can use basic communication with my instruments using a terminal software. Simple commands and queries like "++addr 29", "++auto 1" and "*IDN?" are working fine.

First I found out that the prologix configurator from John Miles sites checks the version string of the adapter. It scans for "ersion %d.%d" into major and minor and uses major*1000+minor (and an optional character at byte position 11). It seems to distinguish three versions: 3.12C, 4.40 and 6.102 to fine tune settings. So I changed the reported version with ++id verstr AR488 version 6.102 to the highest version. This solved the issue that the configurator was not able to use the AR488. Sending and receiving is working in the terminal window and settings control and device mode as well as autoread checkboxes and/or the manual read. Lower versions where tested but I found no obvious differences.

The 7470 plotter emulater is not working, neither in "request plot from supported device at address 29" (Tek in full control @29), which will "hang" at received bytes 0, nor with "wait for device initiated plot" in listen-only (Tek in talk-only), which will receive 0 bytes as well. Both functions work well using a Agilent 82357B with Agilent IOlibrary. The tdsdump.bat example from the KE5FX packages is not working either with the AR488.

Using the terminal, I can send the corresponding commands to the device and perform a "++read" after "HARDCOPY START" command. It reads the HPGL data from the device. Using 7470.exe with "request plot from supported device at address 29" and stopping the program, I can read the hardcopy with the terminal program just performing a "++read" after switching to "++mode 1", the KE5FX library seems to swich to listen. I can crash the 7470 program by performing two "request plot from supported device at address 29", the second being aborted with a message that the identification is invalid and stating parts of the HPGL plot, presumingly from the first initated hardcopy that was aborted by keypress.

Any help how to proceed in systematic testing is appreciated.

Experimenting further, I was not able to use the listen-only in success with the Tek. Sending "++lon 1", it keeps reading "1 bytes" in a loop with timeout. Initiating a hardcopy from the Tek does not produce any data. Furthermore I was not able to stop the polling loop with any ++ command, how is this expected to work?

As this is not a real problem report, any other method of communication (email, chat) is of course accepted to not fill the tracker with bloat. I can produce logs and dumps if needed. Haven't recompiled the KE5FX software yet as my VS2019 compiler spit out some errors.

[dl6lr]

Addendum: I was able to retrieve some device initiated plots. They have some issues in the data shown as glitches. More complex screens are interrupted in the middle, I assume this is some kind of timeout (I see KE5FXs library limits the read_tmo_ms to max 3000), as the remaining data is stored to a second plot. Currently I think this is a problem in the way the KE5FX program uses the AR488 as a Prologix clone. Have to dig deeper...

[Twilight-Logic]

Thank you for your report.

As you have observed, the ++id verstr command was introduced just for this purpose, to allow the version string to be set to whatever specific software is expecting. Generally setting it to version 6 should be sufficient.

I am uncertain about what the problem is with ++lon but this is now the second report of a problem although the previous report was specific to version 0.49.14. My understanding from that report is that version 0.49.12 works OK. Nevertheless, I do intend to have a closer look at the problem. I have just acquired a GPIB board for a my Tek 468 storage oscilloscope and am in the process of installing it. I need to improvise a missing switch but once I have it set up and have it working I will have an instrument I can a real world test instrument dumps with which will put me in a better position to have a closer look at the problem.

The problem could be down to timeout but could be some other factor such as serial handshaking (or rather the lack of it on cloned boards with the CH340 chip) but I am also interested in your further findings. I was going to suggest turning DEBUG7 on, but the results would have to be observed in a terminal, so that will not be practical.

[dl6lr]

Something more: I found that a lot of programs rely on the adapter being in a specific state. That might not be the case as programs may leave the adapter in an unknown state. I.e. the TDS Screen dump utility Niravk1997/Tektronix_TDS_HardCopy_AR488 relies on default settings of the AR488. This may not be the case if the adapter was used by a different program before. Especially if the 7470 works as a plotter emulator, it may leave the adapter in device mode. This made my testing more complicate as I was facing intermittant failures...

[Twilight-Logic]

Thank for reporting that back. If the adapter is left in an unknown state by a previous program then that certainly would make things difficult for the next program. Especially if In a situation where the adapter is left in an auto read mode, it should be possible to turn off the mode, but it does take time for the interface to respond while it is locked in a reading loop. It is probably quicker to just reset.

I saw your post on the thread and I am glad you got to a working configuration form now.

Unfortunately, the donor GPIB board for my Tek 468 is faulty. It shuts the storage computer down when connected. The switch and LEDs are wired in place, but alas, still no working GPIB! Its going to be a while before I can do any real-world testing from that instrument. If I had the necessary plotting software, I could probably test some printing to the KE5FX 7470 emulator using the 4051 computer instead. Will need to look into that.

I must find some time during December/January to get the new code thoroughly tested and released.

[dl6lr]

Some more findings: The KE5FX library uses the ++read_tmo_ms command to set the read timeout. The value is restricted to a maximum of 3000ms and defaults to 500ms, it can be configured in the configuration file 7470.ini. But the command is only performed, if auto-read is not enabled. As the library enables auto-read by default upon connection establishment, this command is effectively never used to set the read timeout in controller mode. This is the reason that the controller requested hardcopy does not work: It emits the HARDCOPY START command to the TDS, then waits a maximum of 1200ms (default read_tmo_ms) which is not long enough for the older Teks with slow processor boards. By setting ++read_tmo_ms to 8000 I was able to successfully request a hardcopy from the TDS540 (without glitches!). So I think the appropriate solution would be:

1. Enable setting of ++read_tmo_ms even in auto-read-mode
2. Introducing connect/disconnect command sequences to be sent to to the adapter after connect and prior to disconnect to force the adapter to a known state.

As I do not have a Prologix adapter, I can not verify behaviour to be consistent with it. I may contact John to discuss with him or ask for his permission to create a derivative on Github

[Twilight-Logic]

I finally got GPIB working on the Tek 468. I was able to get output at the terminal with default settings, just by setting the address to 17 (as set on the dip switches) and issuing a ++read. This yielded the scope id, firmware version and some channel and drawing data. However, it does not appear to be HPGL so would perhaps have not helped much with this particular problem. I now need to decode the format.

Have you tried NX-1997s TDS with ++eor 7, ++eoi 1, ++read_tmo_ms 8000, ++addr GPIB_Address, and everything else at default as discussed in the thread? It didn't work with my 468 because the format is different but might work with your TDS540.

Looking at your previous comment it seems that you have successfully resolved the problem anyway, so unless there is any further comment within the next week or so, I will close the issue. Sorry I could not be of much help in this case.

[dl6lr]

Thanks for your response. The NX-1997s TDS dump utility does work for me. It is using BMP dump file whereas the KE5FX tool uses HPGL. Wether the file formats are supported depends on the instrument used, my TDS540 supports both formats. I am still struggeling with some minor details but I did not have enough time to trace them down. I would like to share my results here but if you close this issue, I may gladly report in a new one. I haven't contacted John yet as I still feel I am not understanding everything in his library/tools. Maybe I will buy a Prologix to make sure the behaviour is similar or different.

Final goal is to have a raspberry pi as a plotter server and instrument control for some connected devices, so I can press the hardcopy button on the front of the instrument to have a plot saved that could be retrieved through the network or use the network to request a device plot, haven't made up my mind yet which solution is more comfortable.

[Twilight-Logic]

I will leave the issue open for now so that you can report back without opening another one.

Interesting idea with the Pi. Nx-1997 pointed me to a Python program to capture plots from my 468. Possibly it could be modified to do something similar and pull plots in waveform data format from the TDS series. I intend to have a look at it and maybe update it for Python3 at some point.

[dl6lr]

Currently I have no time to investigate further, so I close the issue. I was able to change the KE5FX-software to retrieve plots from my TDS-540 and capture device initiated plots, but this is not very stable. Currently using the Agilent 82357B for the TDS.

[Twilight-Logic]

Thank you. I did write a Python program to retrieve plots from my 468 and this works OK in both Controller and Talk Only modes. Based on my recent work with the Tek 768 (and a Tek 40501 computer), there have been a number of tweaks to the latest code, however, due to the smaller amount of output data and different file format of the 768, these may not be relevant to the issue with your TDS-540. Unfortunately, I do not have access to a TDS series scope to test with so am unable to replicate the issue. At least you have your Agilent 82357B to fall back on.