New Keithley DMM6500 and now DAQ6510

[KungFuJosh]

A study of the DMM7510 firmware revealed the entrance to a rather interesting secret menu used by the quality control department. This menu is accessed by pressing and holding the "HOME" and "MENU" buttons during startup.

Looks like that works on other models too.

[Salient666]

Can confirm it works on the DMM6500.

[wandering_traveler]

Hi Brad,
Thanks for your contributions here. Much appreciated.

Is it possible to remove the user swipe screens on the 6500 and 2450? The example you gave to remove the function screen works as expected, but the following command has no effect, whether the window is visible or not, has text or is clear.

display.delete(display.SCREEN_USER_SWIPE)

UPDATE: After trying the next day, the remove user swipe command works as expected, running the exact same program. Apparently, a reboot overnight fixed whatever was causing the issue. However, continuing to experiment- I have found the screen display/delete to be erratic. Both the SMU 2450 and DMM6500 show similar issues. Sometimes running the program won't display the user swipe screen, or it shows the screen but without text. And the swipe screen delete stops working. No error messages on either machine. Rebooting fixes things for a short time. So at this point, I think creating and updating a user swipe screen seems reliable, but closing and reopening a couple of times causes display issues. This is running VS Code on a Mac via ethernet.

Interesting idea for the enter key to move between swipes...  To remove the Functions swipe screen, you can use same command I gave to PTR_1275 earlier:
Code: [Select]
display.delete(display.SCREEN_FUNCTIONS_SWIPE)
to bring it back:
Code: [Select]
display.create(display.SCREEN_HOME, display.OBJ_SWIPE, display.SCREEN_FUNCTIONS_SWIPE)
You could add these to autoexec.tsp to have the swipe removed on start up.
In fact, here's the list of the swipe screens if anyone else wants to remove one of them. You could even remove all of them! If for some reason you wanted that...
Code: [Select]
display.SCREEN_FUNCTIONS_SWIPE
display.SCREEN_SETTINGS_SWIPE
display.SCREEN_SECONDARY_SWIPE
display.SCREEN_GRAPH_SWIPE
display.SCREEN_STATS_SWIPE

And a few related TSP questions,

• Is it possible to communicate to a 2450 from a 6500 using the ethernet link? It looks like it is possible to communicate to SCPI devices this way, though I haven't had a chance to try it out yet. If not, I suppose the KTTI-TSP is the only effective option.
• Can the VS code TSP extension be used to communicate to two TSP devices within the same program, running from a Mac? I can have two VS Code windows open and run separate programs for each device, but would like to be able to talk to multiple devices in the same program. Better yet if I can talk to SCPI devices too. If this isn't possible using TSP, I could always revert to PyVISA, but I do prefer TSP to SCPI
• Can a Python program be used to run TSP programs from the PC? (Mac) That would be the ideal solution, making it easier to run TSP on the PC or the test machine, and get the data back for analysis in Python.

I have to say that I am very impressed with both of these machines- the speed, accuracy, and user interface. There is an amazing amount of functionality, which for the most part is very well documented, though it would be nice to have some more details around the general mechanics of programming and communication. On the other hand, I haven't made it through all 2500+ pages of documentation yet...

[Brad O]

The User Swipe screen shouldn't appear by default. I would expect display.delete(display.SCREEN_USER_SWIPE) to work, but you might also use display.clear(display.SCREEN_USER_SWIPE). display.clear() by itself should just remove all the text from the user swipe. display.clear(display.SCREEN_HOME) should remove all swipes, then you can add whichever ones you want back.

Refer to the display API for more: https://github.com/tektronix/keithley/blob/main/TTI_Apps/TTI_Display_API/Display%20API%20Command%20Reference.md

Seeing your update, remember there's a reason the display API commands are documented here and on GitHub: they were never fully vetted by engineering. A few passionate engineers did a lot of work on the API and fixed many hidden issues, but most of these commands and capabilities specifically aren't in the manual because they never got the hard testing to discover all the weird bugs like what you seem to have found. What you're describing sounds a like a memory leak. It's possible display.delete() isn't interacting with the swipe properly and is leaving some remnants that build up. A reboot would be the go-to solution, or try using the display.clear() method above which would allow the swipe object to still exist, just not be displayed. That might prevent the memory problem, if that's what it is.

Is it possible to communicate to a 2450 from a 6500 using the ethernet link? It looks like it is possible to communicate to SCPI devices this way, though I haven't had a chance to try it out yet. If not, I suppose the KTTI-TSP is the only effective option.

Yes! But you can't use TSP-Link without the KTTI-TSP card, you need to use TSP-Net if you want to use the base ethernet port. Chapter 9 in the Reference Manual. TSP-Link is a dedicated bus for TSP instruments only, with niceties like dedicated trigger lines in PHY and generally simpler scripting once connected, but TSP-Net allows communication too. TSP-Net is just a wrapped TCP/IP interface, so you would wind up controlling the other TSP instrument as you would any SCPI instrument, but you can send TSP commands instead. The TSP-Net interface also allows you to interact with general servers. For example, I wrote a script for sending email via TSP-Net, but it had a lot of limitations and mainly serves as an low level example of how email works: https://github.com/tektronix/keithley/blob/main/TTI_Apps/email.tspa

Can the VS code TSP extension be used to communicate to two TSP devices within the same program, running from a Mac? I can have two VS Code windows open and run separate programs for each device, but would like to be able to talk to multiple devices in the same program. Better yet if I can talk to SCPI devices too. If this isn't possible using TSP, I could always revert to PyVISA, but I do prefer TSP to SCPI

An important concept is that TSP runs on the instrument, not on your computer. The VSCode extension simply facilitates sending the scripts to your instrument (and things like editing, etc.). So you can't use the same script to talk to two different instruments without using TSP-Link or TSP-Net to have the instrument you're running the script on talk to the other instrument itself. The instrument running a script has no concept of any other equipment without TSP-Link or TSP-Net.
TSP is both a programming language and a command set, so you can use TSP commands with Python just fine, you don't have to use SCPI.

Can a Python program be used to run TSP programs from the PC? (Mac) That would be the ideal solution, making it easier to run TSP on the PC or the test machine, and get the data back for analysis in Python.

Yep, calling a TSP function or script on an instrument from Python is very common. This app note covers this an many of the other things you're asking about: https://www.tek.com/en/documents/application-note/how-to-write-scripts-for-test-script-processing-(tsp)

[wandering_traveler]

Thanks Brad.

The user screens don't appear by default, I didn't mean to give that impression. I did find that writing text to them will cause them to display, so display.changescreen(display.SCREEN_GRAPH_SWIPE) is not needed, unless you need to go back to that screen later.

I did find the display API, along with a couple of useful GitHub sites. It's just challenging to navigate through all the various references in order to pick out what I am specifically looking for. But I'm getting there.

About the inability to remove the swipe screen- I found that creating the screen, workinging with it, and removing it worked fine. After that, I could re-create the screen and again work with it. But at that point, I could no longer remove that screen, unless I did a reboot or a system reset. And other screen navigation errors would occasionally show up at this point also. It won't keep me from doing what I want, just an interesting bug. This happens the same way on both the 6500 and 2450.

I'll try out tsp.net later, good to know that I should be able to communicate with other instruments this way directly from the DMM or SMU.

Yesterday I reached the conclusion that VS Code wouldn't be able to talk to two instruments at the same time, at least not in the same code window. In separate windows, of course, this is not a problem. But I appreciate your confirming this. Because of this, I decided to switch to Python, since I'm quite comfortable with that. After installing PyVISA and PyVISA-py, it was quite easy to talk to several instruments (TSP and SCPI) at the same time. So now I think I'll add in something like the Adafruit FT232H, which will allow me to talk to I2C devices from the same program. So I will have no trouble controlling digital and analog IO, specialized sensors and so on from the same test machine control program. Pretty impressive capability! I figure if I need some sections of the programs to run at higher speeds, I can offload those to the Keithley devices to run locally as TSPA scripts.

If anyone is wondering why I didn't go with the TestController route, I did give that a try. I found the interface to be a bit confusing, but I'm sure I would have easily figured it out with more time. (And this is not meant as criticism of the program- for a one person development effort, it's an amazing piece of software with a lot of functionality) I made the choice to go the Python route for several reasons:

• I'm comfortable with Python, and there is a lot of available functionality with add in modules for graphing, math, exporting etc.
• I wanted to be able to use TSP on the Keithley instruments
• I spot-checked communications with several instruments. My DC load and DC linear power supply worked fine over SCPI. But I tried the DMM6500, and found a lot of machine errors, and occasional lock-ups requiring a reset. And there is no driver for the 2450 SMU.
• The Python approach lets me easily talk to raspberry pi types of devices- sensors, IO, stepper motors, etc. Or I can run the whole thing on a raspberry pi to keep the computer free. I did see that TestController can connect to microcontrollers, but it wasn't clear how to do this, and I prefer programming Python to Arduino C.

I appreciate your comments on the API commands not be fully documented or supported. I'd rather have them as they are, instead of "locked away" as hidden calls. Again, I'm very impressed with the thought that has gone into these machines, from the user interface and general functionality, and the overall quality of the documentation.