As far as UI features go, we have followed some systems and guidelines from "UX" design methodologies to develop interfaces that "most" people can work with right away and not have a frustrating experience (hopefully)
Hope it helps clarify how we ended up with what we got today
Keithley's TTI UI is the best in the industry in my humble opinion. I wish everyone making meters, power supplies, etc. would borrow from it.
...........
the intention is that the 65xx replaces Model2000, Model 2700, Model 2701 -
...........
I'd guess also the tek 4000 series?
Is there a dmm5050 in the works?
...........
the intention is that the 65xx replaces Model2000, Model 2700, Model 2701 -
...........
I'd guess also the tek 4000 series?
Is there a dmm5050 in the works?
I think 65xx probably replaced the Tek 4000 from a functional / specs standpoint, but I am not aware of it being on our list of intended replacements. Some of its driven by obsolete parts and the Tek 4000 was a different generation / design.
As far as a DMM5050.. who knows... we are always working on something next!
Hey guys, I am still here and willing to help anybody out (even hwj-d) because I am happy to do it and participate in all the cool projects, discussions and topics.
If anybody wants some help or support with KI or Tek products , I can work on it for you or at least get you connected to the right people.
Hello E-Design,
I recently (after upgrading the firmware) began experiencing some issues with the power button of the DMM6500. When I press the button to turn it off sometimes (maybe 30% of the times) it immediately turns on again, as if it was some kind of debouncing issue. Are you aware of any modification to the firmware that could have caused that or do you think the problem is not related to the firmware at all?
I'm getting a 2450, and I was checking the TSP-Link addon of the DMM6500, but then I found it apparently is possible to use the LAN to communicate between Keithley instruments (which of course would spare me some money). What are the differences between using TSP-NET and TSP-Link to communicate between Keithley instruments?
Thanks in advance
Regarding TSP-NET and TSP-Link some additional from apps eng...
In general, TSP-Link is the way to go. TSP-Link offers a number of advantages like the shared error queue, TSP-Link triggering (which is the preferred triggering method), and the simplicity of directly controlling other instruments or accessing their memory with the node[n] syntax.
The key thing to remember with TSP-Net is that it solely operates over LAN and is very close to a standard sockets connection. This gives it the advantage of being able to operate over long distances as you can connect through local networks (theoretically you could operate over the internet, but I haven’t tried that and I’m sure you’d have firewall problems). The interface of TSP-Net is largely limited to simple read() and write() commands, though you do have dedicated commands to execute scripts and a couple other key TSP features.
Another big driver was the longevity - a lot of the cool UI / displays today are connected to industry trends that are tied to cell phone and IOT markets - SUPER VOLATILE.. Here today, gone tomorrow. We just cant fathom designing a meter with a continuously going obsolete display so we demanded something that will be around for a long time (working with our vendors)
We had the same discussion at the office some years ago, the screen will always be old for devices that are supposed to have a long live time and take time to develop with limited resources. So we decided to go black box and let an industrial panel, PC or tablet be an added choice at that time. "You want a bigger nice screen? then buy one!".
That's why I like the browser interface you have, although the update rate is lower, speed is always increasing in the next designs.
TSP-NET and TSP-Link
Are there any good examples of using one and the two?
I have wasted a lot of time trying to get TSP-Link to work. I even bought an additional card for the DAQ6510.
I could not find any good docs on TSP: some basic illustrations showing daisy-chaining, telling me to use crossover Cat5 cables and set unique node numbers. Well, I've tried all that but must have missed something essential.
There is no marking for "in" or "out" on the TSP connectors. My best guess is that it is connector-xfmr-instrument-xfmr-connector, but I'm not sure.
Also, connecting >2 instruments always causes an error. I've used different cables and the strange thing is that identically connected cables give different results - some refuse to work. Any shielded (S/FTP) cable is a no-no. And, yes, I know how a crossover cable is wired, even from memory.
I know how a crossover cable is wired, even from memory.
You also know there are two different rj45 pinout standards?
You also know there are two different rj45 pinout standards?
Electrically these look the same, the orange and green markings are the only difference.
You also know there are two different rj45 pinout standards?
Electrically these look the same, the orange and green markings are the only difference.
Yes, but if he started out with a pre-made cable which uses 568A on one side and he wired the other side as (crossed) 568B
it would cause trouble, still something worth to check.
Yes, but if he started out with a pre-made cable which uses 568A on one side and he wired the other side as (crossed) 568B
it would cause trouble, still something worth to check.
I've so far only used pre-made molded cables. Checked electrically for 1-3, 2-6, 3-1, 6-2. Also optically; the wires can clearly be seen through the transparent connectors.
EDIT: Also, all cables work OK as GigE network cables.
Yes, but if he started out with a pre-made cable which uses 568A on one side and he wired the other side as (crossed) 568B
it would cause trouble, still something worth to check.
I've so far only used pre-made molded cables. Checked electrically for 1-3, 2-6, 3-1, 6-2. Also optically; the wires can clearly be seen through the transparent connectors.
EDIT: Also, all cables work OK as GigE network cables.
The cables supplied by Keithley for TSP are wired in the following config:
1-3
2-6
3-1
4-4
5-5
6-2
7-7
8-8
The cables supplied by Keithley for TSP are wired in the following config:
1-3
2-6
3-1
4-4
5-5
6-2
7-7
8-8
Interesting.
So a T-568A to T-568B cross-over cable?
Interesting.
So a T-568A to T-568B cross-over cable?
Yessir, that looks correct.
I can confirm 3 working TSP-Linked instruments with this cable config.
The nice thing about standards is that there are so many of them to choose from.
(Andrew S. Tanenbaum)
Hi Guys,
Has anyone used the Raw Socket communication over LAN with the DMM6500? With the instruments I've used in the past I would use Putty and just type in commands, but with the DMM6500 I cannot get it to even return a *IDN? command. Any tips? The manual says that raw socket communication is on port 5025, which is what I've used (with no luck). The TCP/IP connection does get established, but I cannot get the DMM to return anything.
Thanks for any tips,
Ivo
Hi Guys,
Has anyone used the Raw Socket communication over LAN with the DMM6500? With the instruments I've used in the past I would use Putty and just type in commands, but with the DMM6500 I cannot get it to even return a *IDN? command. Any tips? The manual says that raw socket communication is on port 5025, which is what I've used (with no luck). The TCP/IP connection does get established, but I cannot get the DMM to return anything.
I have not seen any problems with
TestController.
You can use TestController like Putty, its command line goes to the connected and selected device.
Hi,
I just made a short video to show a bug in the displayed values that I like to see fixed.
Thanks
Has anyone used the Raw Socket communication over LAN with the DMM6500?
I use Raw socket with lxi library at least 6-9 months, no problem.
I found only one issue with raw sockets - after each command need send "\n" control character to instrument.
a *IDN? command.
I'm not sure, but "*IDN?" it's SCPI command.
Try switch dmm's to SCPI command set.
Also - i think you can't talk with dmm's directly via Putty. When i use LXI i must set "instance" to "inst0", without that dmm no answer anything. Probably need some special to set that when you send data directly.
Try use telnet to talk with dmm directly(DMM6500-901-01 Rev. B / September 2019 page 2-20).
Thanks for this! I will try the Telnet option. May I ask which port you are using? My bet is that you are using 1024, which is ment for VXI-11 (LXI) communication.
I'm trying to use port 5025, which should be basically printf over TCP/IP. At least that's what I've been used to with other instruments I've used SCPI with. I'm a fairly old-style programmer and I write my scripts mostly in C and Linux. To communicate the raw socket way with a device, I don't need any libraries, just standard BSD sockets (which every programming language has built in).
I will try the same method, but with Port 23 and I'll report on how that went.
Regards,
Ivo
I'm trying to use port 5025, which should be basically printf over TCP/IP. At least that's what I've been used to with other instruments I've used SCPI with. I'm a fairly old-style programmer and I write my scripts mostly in C and Linux. To communicate the raw socket way with a device, I don't need any libraries, just standard BSD sockets (which every programming language has built in).
Don't act silly, the port is 5025 and it works nicely with standard raw socket ascii communications.
As I wrote TestController has no trouble using it. If you want to see exactly what bytes are send and received you can use debug mode.
If they make me Z540.1 w/Data calibration and provide official traceability Keithley certificate i use it.
I try... thanks.
I'm afraid they will calibrate it according to the Russian method in accordance with the type certificate. Those. relative to Russian standards. Not Fluke standards.
Here is the calibration instruction.
And forward me to unknown lab, i create request and waiting....