Author Topic: New Keithley DMM6500 and now DAQ6510  (Read 296774 times)

0 Members and 2 Guests are viewing this topic.

Offline MegaVolt

  • Frequent Contributor
  • **
  • Posts: 909
  • Country: by
Re: New Keithley DMM6500 and now DAQ6510
« Reply #450 on: April 07, 2019, 03:42:21 pm »
Please detail. What is the maximum voltage between INPUT LO and SENSE LO?
Max (SENSE HI-SENSE LO) voltage is 10V.
INPUT LO - SENSE LO  I do not know
 

Offline MikeP

  • Regular Contributor
  • *
  • Posts: 160
  • Country: ua
Re: New Keithley DMM6500 and now DAQ6510
« Reply #451 on: April 08, 2019, 04:42:24 pm »
 I think it's 12 volts. Who will offer more?

 Page 10, spec-sheet.

 Note 35. See DC VOLTAGE ACCURACY. SHI and SLO: 10 V range only. SHI and SLO (sense) terminals referenced to LO input. Maximum voltage
referenced to LO 12 V.
 

Offline MegaVolt

  • Frequent Contributor
  • **
  • Posts: 909
  • Country: by
Re: New Keithley DMM6500 and now DAQ6510
« Reply #452 on: April 08, 2019, 04:57:21 pm »
I think it's 12 volts. Who will offer more?
:))))) 12V = 10V + 20% stock

Quote
Page 10, spec-sheet.

 Note 35. See DC VOLTAGE ACCURACY. SHI and SLO: 10 V range only. SHI and SLO (sense) terminals referenced to LO input. Maximum voltage
referenced to LO 12 V.
New datasheet?
 

Offline Brad O

  • Regular Contributor
  • *
  • Posts: 85
  • Country: us
  • Keithley Apps Engineer
    • Keithley homepage at Tektronix
Re: New Keithley DMM6500 and now DAQ6510
« Reply #453 on: April 08, 2019, 05:06:50 pm »
I think it's 12 volts. Who will offer more?
:))))) 12V = 10V + 20% stock

Quote
Page 10, spec-sheet.

 Note 35. See DC VOLTAGE ACCURACY. SHI and SLO: 10 V range only. SHI and SLO (sense) terminals referenced to LO input. Maximum voltage
referenced to LO 12 V.
New datasheet?
Indeed, it is 12V.  The page 10 reference is from the spec sheet (attached) which has the same information but is formatted differently from the datasheet
 

Offline cozdas

  • Contributor
  • Posts: 38
Re: New Keithley DMM6500 and now DAQ6510
« Reply #454 on: April 09, 2019, 10:18:54 am »
Which reminds me, unfortunately the release of the next firmware has been delayed until the end of May.  The team was really hoping to get it out by the end of March but it just wasn't ready with all the features we wanted in it.  In addition, we've been trying to incorporate the feedback everyone here on EEVBlog has given.  It's really quite hard to get direct feedback from people in this industry so your comments and problems have been extremely helpful in learning more about how people are using our instruments so thank you all!

Thanks again for listening to the users and providing excellent support here. Since you were talking about bugs already fixed in the development firmware for a while I was hoping that the new firmware would arrive soon thus I was holding my bug+wish list to avoid double posting. Since it's not coming anytime soon I decided to dump my bug/wish list here so that the other members can also chime in and correct me if my wishes are not good ideas for general/professional use. So here is my list of two cents:

HW and Main Features
  • Wish: Fan off functionality. :)
  • Wish: non-humming transformer. Also why soft button for power? I have to unplug the DMM in my office/lab when I'm not using it.
  • Wish: low open circuit voltage for connectivity test.?
  • Wish: Autorange delay: While observing quickly changing signals which are fluctuating across the range limits, autorange will engage relays in some situations. Being able to delay automatic range switches would be very useful in certain situations. One example: I was observing the sleep/wakeup power consumption profile of an embedded system which has a PWM display backlight. I needed fast sample rate and autorange to cover the sleep-awake dynamic range but when the device is awake, the autorange would engage 10+ Hz relay clicks due to backlight PWM. With user adjustable autorange delay option, it would stay in the high range for brief current drops, saving relay life.
Buffers
  • Bug/Wish: To access the parameters of the secondary measurement you need to swap primary with secondary, but this clears both buffers thus the previous measurements get lost. Instead, this should keep the buffers attached to the same functions but should just swap the displayed buffer, keeping the history intact.
  • Wish: quantities with interchangeable units (e.g. temperature) can be kept internally in a single unit in the buffers independent of the selected display unit. This way switching between units would not cause jumps in the data history/graph. During display and/or export, the internal values can be converted on the fly to the active/selected unit. Math operations may complicate implementing such behavior but it'd be really neat if switching between F and C doesn't spoil the hour-long collected trend line.
  • Bug: when you set scan to save to USB (at least in the "save after each scan" mode), restarting a scan will override the previous file. The new scan should create a new file timestamped with the new start time and should not override the existing file.
  • Bug: extra channels of the "full" buffers are not written to CSV file with enough precision, should be written with the same digit count as the main values.
General UI
  • Bug: swipe panels occasionally stuck in the middle while swiping.
  • Wish: display input voltage values in the voltage ratio mode somewhere with small fonts. Similarly RTD resistance values, thermocouple voltage values, original measurement in the math mode, period for freq, freq for period etc are welcome.
  • Wish: add ppm option in addition to percent: 92ppm instead of 9.2m% ?
Graph
  • Bug: if there are multiple samples per pixel in the graph, currently the "marker" and "both" modes become identical. In this situation, when "both" is selected averaged lines should be drawn on top of the peak-showing markers making both visible on the display.
  • Bug: sometimes graph show too coarse representation of the data, causing lots of data missing in the graph. Very confusing (manually selecting the X-axis range sometimes trigger this misbehavior).
  • Bug: Manually setting the X-axis time range shows partial data. Lets say you have been collecting data for a long time and you want to see the latest 10 seconds be displayed, you can do that with Graph/Scale, X-Axis method: "Show New", Scale: 10.00s. No problem here. But after this if you set "Scale" to 100.00s to see the latest 100 seconds, this will not show you the latest 100 seconds because the read-only "minimum position" set by the 10s step stays the same so you still see the last 10 seconds with 50sec worth of empty space. I think when the Method is "Show New", the data needs to be right-aligned in the graph after each Scale change if min position + scale is not enough to fill the screen.
  • Wish: Graph scale value entry dialog boxes should use the same numeric entry UI design that is used in other places. Current 3-value in a 7-line dialog box is not a very good UI/UX. The general numeric entry dialog box you already have in other parts in the UI is well designed why don't you just use that instead?
Web interface
  • Wish: Add mouse wheel support to the web interface: this may be used to scroll the long dialog boxes up/down, or swipe panels left/right. Mouse wheel can also be be used for graph zooming (currently there is no way to achieve any pinch zoom capability remotely with web interface)
  • Bug: when the cursors are turned on, moving the cursors with mouse in the web interface also pans the chart data.
  • Wish: keyboard entry and shortcuts in the web interface (cursor keys to scroll pages, numeric/text entry etc).
  • Wish: with the web interface, each swipe screen scroll takes 1-2 seconds and if you re-click to move one more page before the swipe animation ends, you go back to the previous page. This makes navigating through the swipe pages in the web interface painfully slow. Skip the animation if swiped via web interface maybe?
Other
  • More frequent firmware releases for tighter-faster feedback loop from the users. Beta program maybe?
« Last Edit: April 09, 2019, 11:33:56 am by cozdas »
 
The following users thanked this post: kado, msliva, hwj-d, Brad O, eplpwr

Offline hwj-d

  • Frequent Contributor
  • **
  • Posts: 676
  • Country: de
  • save the children - chase the cabal
Re: New Keithley DMM6500 and now DAQ6510
« Reply #455 on: April 09, 2019, 11:18:58 am »
Thanks cozdas for this compilation.
What i consider to be very worthy of improvement among the points presented here, is the "Graph scale value entry dialog", only in steps of 10 on the y-scala, which is much too rough for the display of measured values. All that remains is the imprecise touchscreen settings. The same applies to the much too imprecise positioning of the cursors. (Regarding the cursors: they should be also assignable to different colors.)

Something I observed, with request for a countertest:it seems that screen switching in the web-interface affects the measurement result. At least I observe in irregular distances corresponding disturbing deflections on the Y-axis in the DC-µV range, which falsify the statistical result of my voltage references.

 

Offline hwj-d

  • Frequent Contributor
  • **
  • Posts: 676
  • Country: de
  • save the children - chase the cabal
Re: New Keithley DMM6500 and now DAQ6510
« Reply #456 on: April 09, 2019, 11:38:40 am »
Another GUI behaviour.
Scale menu:
The scale values of the x-y-axis should always be freely editable without having to not intuitively switch the method back and forth to off mode.
 
The following users thanked this post: kado

Offline Mike G

  • Regular Contributor
  • *
  • Posts: 83
Re: New Keithley DMM6500 and now DAQ6510
« Reply #457 on: April 11, 2019, 06:01:35 am »
Hi all, have read this forum for years but as this is my first post so please be gentle :)   I hope Brad picks this up as I have just received my DMM6500, a decision based almost entirely on his unbiassed information and support, plus the feedback from all other contributors on this topic, thanks to everyone!
I am a rather senior (ok old) tech and one of the reasons that made me choose this meter for the workshop was the flexible programming available, I need to start learning some sort of programming as the last serious effort was back in the 70s with the Acorn Atom.
So far I am really pleased with the 6500, seems as though every time I use it I uncover another useful feature that had previously gone unnoticed.
My question for Brad is to do with programming the OBJ_SCREEN, as in his probe hold app. I have learnt a lot from studying the text but wonder if there is any reference material that explains some of the details of this subject that are not covered in the standard 6500 reference download?
Thanks again to everyone, and of course Brad
P.S.  Can't seem to insert emojis, this is the thumbs up  :-+, any help please?
 

Offline Mike G

  • Regular Contributor
  • *
  • Posts: 83
Re: New Keithley DMM6500 and now DAQ6510
« Reply #458 on: April 11, 2019, 06:24:10 am »
Emojis seem ok when viewed in the thread, thanks.
 

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 646
  • Country: be
Re: New Keithley DMM6500 and now DAQ6510
« Reply #459 on: April 19, 2019, 08:12:44 am »
I need an array of numbers to do some FFT calculations:

What is the syntax to Write to a buffer?
outreal= buffer.make(n,buffer.STYLE_WRITABLE_FULL)
outimag= buffer.make(n,buffer.STYLE_WRITABLE_FULL)

outreal[k]=5.0 ??

There is also the type 'table' but I don't know how to initialize it for like 1024 items.
Not sure if this would be faster or slower.
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline Brad O

  • Regular Contributor
  • *
  • Posts: 85
  • Country: us
  • Keithley Apps Engineer
    • Keithley homepage at Tektronix
Re: New Keithley DMM6500 and now DAQ6510
« Reply #460 on: April 19, 2019, 05:45:37 pm »
My question for Brad is to do with programming the OBJ_SCREEN, as in his probe hold app. I have learnt a lot from studying the text but wonder if there is any reference material that explains some of the details of this subject that are not covered in the standard 6500 reference download?
I'm so glad I can I can be of help!  There is no official documentation for the apps API yet (so most of the display.* commands), but we are working on it! Believe me that you all expressing so much interest in TSP apps has made us want to get it right. The internal documentation we have is quite lacking, and there's a lot of changes and updates that need to made.

BUT, this seems like a good time to mention that we've started a GitHub repository Keithley example code, especially TSP code.  You can find it at https://github.com/tektronix/keithley, I've put some working TSP apps at https://github.com/tektronix/keithley/tree/master/TSP_Apps, including several you haven't seen before like one to control the Digital I/O port (for those of you with a communication card) and the ground work for an app that allows you to email buffers (this was has a ton of restrictions though, they're mentioned in comments in the code).  If you want to make pull requests against the repo, I (and another factory applications engineer, Josh) will review them.  This should make it easier for us to share code with you, and for you to share and get help on code from Keithley.

I need an array of numbers to do some FFT calculations:

What is the syntax to Write to a buffer?
outreal= buffer.make(n,buffer.STYLE_WRITABLE_FULL)
outimag= buffer.make(n,buffer.STYLE_WRITABLE_FULL)

outreal[k]=5.0 ??

There is also the type 'table' but I don't know how to initialize it for like 1024 items.
Not sure if this would be faster or slower.

The command to write to a writable buffer is buffer.write.reading().  Generally, the only reason you would need to use a buffer is if you want to display the data on the front panel of the instrument, otherwise, it's probably easier to work with tables.  Initializing variables is actually discouraged in TSP/Lua, but of course some times it's just easier to initialize than append everything.  The way you do it is tableVar= {n=25}, that makes a table of size 25, you can then access those items how you'd like, with tableVar[k].  Speed wise, they should be about same, but I haven't done any timing testing to verify that.

Also since it's come up again, we are working on an FFT app, but it doesn't work on the currently released firmware.  Plus we'll see how it compares to all the FFT work everyone else has been doing!

« Last Edit: April 19, 2019, 05:47:55 pm by Brad O »
 
The following users thanked this post: TiN, kado

Offline MikeP

  • Regular Contributor
  • *
  • Posts: 160
  • Country: ua
Re: New Keithley DMM6500 and now DAQ6510
« Reply #461 on: April 19, 2019, 08:00:21 pm »
we've started a GitHub repository Keithley example code

 GREAT!  :-+

 And official page:
https://www.tek.com/keithley/tsp-applications-for-touch-test-invent-models

 Thanks.
 

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 646
  • Country: be
Re: New Keithley DMM6500 and now DAQ6510
« Reply #462 on: April 20, 2019, 03:28:51 pm »
About provide syntax:
Thanks, I will try when I'm at work.

About github: nice one!!
I'm thinking about using standard deviation in the sample and hold script and less fine tune settings, the script should figure it out on its own, should avoid the false 'holds' that I got when tested.
But may require a higher sample rate, idea for later.

About 10Gohm:
is there a way to force it to 10Gohm instead of Auto?
When I want to use it I don't want it to change its mind for a few second and then go back to 10Gohm
I need to be able to count on it that it's not 10Mohm.

Quote
Also since it's come up again, we are working on an FFT app, but it doesn't work on the currently released firmware.  Plus we'll see how it compares to all the FFT work everyone else has been doing!
Nice, you do know that it's not fair competition since you have more doc. and you can optimize the firmware for it ;)

about the kickstart license:
At Farrnell.be, .uk also involved, they are still trying to figure out what to do...
If only Tektronix had a website platform to register your device and redeem your copy without having to email anyone to get it. Oh wait, they do, they just didn't use it (correctly), would have made it so much easier for everyone.
But everyone is friendly trying to help.
I also contacted conrad.be to know what their procedure is because the software isn't on their website....

It's becoming more likely that I will buy a DMM6500 for myself :) (I still have a DM3068 now)
At home I'm living by the rule don't pay for calibration, buy a new DMM ;)

edit reply of conrad.be in Dutch:
Basically they have no knowledge of it and advice to contact tektronix with your proof of purchase to get your license.
Their supply is from Germany.
Code: [Select]
Ons is niet bekend hoe de door u genoemde licentiecode verzonden wordt en/of dat deze al bij het apparaat meegeleverd wordt.
Wij leveren vanuit ons magazijn in Wernberg, Zuid-Duitsland en betrekken de artikelen via ons Duits moederbedrijf.
Het kan dus zijn dat als deze actie landgebonden is er bij de "Duitse" versie geen licentie wordt verstrekt.

Ons advies is dan ook even contact op te nemen met Tectronics via het in de link gepubliceerde telefoonnummer: 00800 2255 4835

Het lijkt er echter op dat als je de meter aanschaft en een bewijs van aankoop kunt overleggen aan Tectronics deze u dan de genoemde licentiecode zal mailen.
De software is sowieso al op voorhand te downloaden via de website van Tektronics.
« Last Edit: April 23, 2019, 11:59:53 am by KedasProbe »
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 
The following users thanked this post: kado

Offline cozdas

  • Contributor
  • Posts: 38
Re: New Keithley DMM6500 and now DAQ6510
« Reply #463 on: May 03, 2019, 08:57:17 am »
... the spec sheet (attached) ...

Hi Brad,
One quick question: in the spec sheet you attached there is this statement:
Quote
Limited compatibility with 2001-SCAN and 2000-SCAN-20; see the DMM6500 Firmware Release Notes for additional information

I could not find any additional information anywhere though, including the firmware notes. Can you please clarify the support and limitations for the 2000-SCAN-20 card?

One quick bug report:
Resolution of the stats in the graph page is not consistent, when the cursors are turned on you get the stats for the area between cursors (very useful, thanks for this feature), but the number of digits reduced compared to whole buffer stats which is visible in the same location when the cursors are off. See the attached example.
 

Offline hwj-d

  • Frequent Contributor
  • **
  • Posts: 676
  • Country: de
  • save the children - chase the cabal
Re: New Keithley DMM6500 and now DAQ6510
« Reply #464 on: May 03, 2019, 01:27:54 pm »
cozdas
Yes, but isn't the specification of decimal places in the Femtovolt range a bit unrealistic anyway?  ;D
 

Offline cozdas

  • Contributor
  • Posts: 38
Re: New Keithley DMM6500 and now DAQ6510
« Reply #465 on: May 03, 2019, 07:18:34 pm »
cozdas
Yes, but isn't the specification of decimal places in the Femtovolt range a bit unrealistic anyway?  ;D

Hehe. Well apparently it's not unrealistic when it comes to the full buffer statistics. Also we don't want those picovolts hang around there alone do we?   ;D

(note to self: connect something to inputs next time you take a screenshot)
« Last Edit: May 04, 2019, 11:02:38 pm by cozdas »
 

Offline hwj-d

  • Frequent Contributor
  • **
  • Posts: 676
  • Country: de
  • save the children - chase the cabal
Re: New Keithley DMM6500 and now DAQ6510
« Reply #466 on: May 03, 2019, 08:30:43 pm »


(note so self: connect something to inputs next time you take a screenshot)


As we can see, this meter can detect even fractions of nothing  :)
 

Offline TiN

  • Super Contributor
  • ***
  • Posts: 4543
  • Country: ua
    • xDevs.com
Re: New Keithley DMM6500 and now DAQ6510
« Reply #467 on: May 04, 2019, 01:59:57 pm »
Quote from: Brad O
we've started a GitHub repository Keithley example code
Now I wish there would be similar repository for oldie goldie series DMMs too, like 200x series :).
All this contribution to forum from Brad and Keithley team is real gold, make me want to buy one of these DMM6500 to use develop some TSP app for using Keithley 1801.

Wondering if scanner port in DMM6500 also have I2C and SPI bus to communicate with Keithley 1801? If interfaces are there and somewhat accessible, that would be perfect example when TSP saves the world day.
I know it's very very niche application, but it's the best amplifier there is for nanovolt-level measurements, but I was already impressed by amount of interested people in this niche equipment.
YouTube | Metrology IRC Chat room | Let's share T&M documentation? Upload! No upload limits for firmwares, photos, files.
 

Offline Brad O

  • Regular Contributor
  • *
  • Posts: 85
  • Country: us
  • Keithley Apps Engineer
    • Keithley homepage at Tektronix
Re: New Keithley DMM6500 and now DAQ6510
« Reply #468 on: May 06, 2019, 05:19:54 pm »
Hi Brad,
One quick question: in the spec sheet you attached there is this statement:
Quote
Limited compatibility with 2001-SCAN and 2000-SCAN-20; see the DMM6500 Firmware Release Notes for additional information

I could not find any additional information anywhere though, including the firmware notes. Can you please clarify the support and limitations for the 2000-SCAN-20 card?
For the 2001-SCAN card, the only limited compatibility is the lack of the "high speed" scan mode on channels 5 & 10.  The high speed channels work the same as all the other relays.  For the 2000-SCAN-20 card, we didn't do thorough testing with it as the idea to include support was added only a little before release.  If you plan on using the SCAN-20 card, let me know and we can complete the testing, but those cards aren't very common and we haven't received any questions about it so far.  Actually, it may work perfectly well, but we can't guarantee that right now.

One quick bug report:
Resolution of the stats in the graph page is not consistent, when the cursors are turned on you get the stats for the area between cursors (very useful, thanks for this feature), but the number of digits reduced compared to whole buffer stats which is visible in the same location when the cursors are off. See the attached example.
Noted, thanks!

(note so self: connect something to inputs next time you take a screenshot)
As we can see, this meter can detect even fractions of nothing  :)
According to Wolfram Alpha, that voltage level is about the same as a neuron firing.  Hold on, I just got an idea for a neuro-surgery App note...

Quote from: Brad O
we've started a GitHub repository Keithley example code
Now I wish there would be similar repository for oldie goldie series DMMs too, like 200x series :).
All this contribution to forum from Brad and Keithley team is real gold, make me want to buy one of these DMM6500 to use develop some TSP app for using Keithley 1801.
I'm open to hosting code for any Keithley products (or just Keithley related code), it will just take time to add them (and I suppose a lot of the older examples we have are in BASIC...).  I and some other Keithley engineers will keep adding examples we have, it just takes time to sort through everything.  If any of you have code you'd like to add, please file a pull request against the dev branch (or just send me your code if you don't want to learn how to use GitHub). 

I've also started putting together a TSP tutorial for the 2600B Series of our Source Measure Units (https://github.com/tektronix/keithley/tree/master/Instrument_Examples/26xx-SMU/Tutorials, if any of you have a 26xx SMU and want to try) that teaches TSP on the instruments via examples.  Once I get it a but more complete I will duplicate it for the DMM6500/DAQ6510. 

Wondering if scanner port in DMM6500 also have I2C and SPI bus to communicate with Keithley 1801? If interfaces are there and somewhat accessible, that would be perfect example when TSP saves the world day.
I know it's very very niche application, but it's the best amplifier there is for nanovolt-level measurements, but I was already impressed by amount of interested people in this niche equipment.
Ah yes, I know your love for the 1801.  The DMM6500 scan port has the same basic communication as the 2000 scan port (which is to say, almost none) and what's there is buried pretty far in firmware.  The 1801 always worked a little different compared to the other scan cards and I think the 2001/2 used a fair number of tricks to control it.  It would take a fair amount of resources to figure out how to get an 1801 working with the DMM6500, if it's possible at all.

 
The following users thanked this post: cozdas, hwj-d

Offline TiN

  • Super Contributor
  • ***
  • Posts: 4543
  • Country: ua
    • xDevs.com
Re: New Keithley DMM6500 and now DAQ6510
« Reply #469 on: May 06, 2019, 05:40:57 pm »
99.99% of my equipment-related code/apps is in Python with GPIB comms. I'll think about what would be useful, and can tidy stuff up and upload to GitHub. Just not sure how that will align with your TSP instrument-related work, as older meters are not TSP-compatible. Hence my question, if you indeed want to mix everything into one bucket.

Quote
It would take a fair amount of resources to figure out how to get an 1801 working with the DMM6500, if it's possible at all.
Sounds like a challenge :) Only problem is that there are no broken DMM6500 on ebay to buy, for trying :D. I actually restarted my old project of 1801 card, adding MCU to attempt fixing 2002 firmware issues.
Writing TSP script for DMM6500 to rescale functions/ranges should be relatively easy, but writing to EEPROM on 1801 card and selecting gain/filtering thru 4094 register need I2C and SPI access to scan-card port. I'd think simple API to read/write byte and manage CS might be enough, if that is possible.
YouTube | Metrology IRC Chat room | Let's share T&M documentation? Upload! No upload limits for firmwares, photos, files.
 

Offline Brad O

  • Regular Contributor
  • *
  • Posts: 85
  • Country: us
  • Keithley Apps Engineer
    • Keithley homepage at Tektronix
Re: New Keithley DMM6500 and now DAQ6510
« Reply #470 on: May 06, 2019, 06:05:58 pm »
99.99% of my equipment-related code/apps is in Python with GPIB comms. I'll think about what would be useful, and can tidy stuff up and upload to GitHub. Just not sure how that will align with your TSP instrument-related work, as older meters are not TSP-compatible. Hence my question, if you indeed want to mix everything into one bucket.
Yeah!  We specifically didn't want to make it a TSP-centric repo, that just happens to be what most of my code is in since I work with mostly the TSP products.  There's already some C# and python up there though.  And the Drivers sections is explicitly for non-TSP code (which reminds me I've got a bunch of LabVIEW drivers to put up there...)

Quote
It would take a fair amount of resources to figure out how to get an 1801 working with the DMM6500, if it's possible at all.
Sounds like a challenge :) Only problem is that there are no broken DMM6500 on ebay to buy, for trying :D. I actually restarted my old project of 1801 card, adding MCU to attempt fixing 2002 firmware issues.
Writing TSP script for DMM6500 to rescale functions/ranges should be relatively easy, but writing to EEPROM on 1801 card and selecting gain/filtering thru 4094 register need I2C and SPI access to scan-card port. I'd think simple API to read/write byte and manage CS might be enough, if that is possible.
Yeah altering readings isn't hard, doing anything with the scanning port that isn't controlling a 2000-SCAN card is though  :-\
 
The following users thanked this post: TiN

Offline cozdas

  • Contributor
  • Posts: 38
Re: New Keithley DMM6500 and now DAQ6510
« Reply #471 on: May 06, 2019, 09:07:18 pm »
For the 2001-SCAN card, the only limited compatibility is the lack of the "high speed" scan mode on channels 5 & 10.  The high speed channels work the same as all the other relays.  For the 2000-SCAN-20 card, we didn't do thorough testing with it as the idea to include support was added only a little before release.  If you plan on using the SCAN-20 card, let me know and we can complete the testing, but those cards aren't very common and we haven't received any questions about it so far.  Actually, it may work perfectly well, but we can't guarantee that right now.

Thanks for the information. Last week I've spoofed the port and as far as my tests go DMM6500 communicates properly with the scan-20 chard. I don't have the card but all bits that DMM6500 sends make total sense with the schematic of the card. I was planning to build a DIY Solid state, 10-chan SCAN card (so that I can collect data during the night at home without the dripping tap simulation), but since DMM6500 seems to drive the 20-chan card I changed my design to double the channels (the more the merrier).

I'll let you know if I hit a problem with the DMM6500 behavior,
 
The following users thanked this post: thm_w, exe, hwj-d, Brad O

Offline hwj-d

  • Frequent Contributor
  • **
  • Posts: 676
  • Country: de
  • save the children - chase the cabal
Re: New Keithley DMM6500 and now DAQ6510
« Reply #472 on: May 07, 2019, 12:58:02 pm »
In combination with Brad O's neuro-surgery App, this would also open up completely new possibilities for the selfmade ambitious hobby craftsman.  ;D
 
The following users thanked this post: Brad O

Offline cozdas

  • Contributor
  • Posts: 38
Re: New Keithley DMM6500 and now DAQ6510
« Reply #473 on: May 10, 2019, 05:29:11 am »
I was planning to build a DIY Solid state, 10-chan SCAN card (so that I can collect data during the night at home without the dripping tap simulation), but since DMM6500 seems to drive the 20-chan card I changed my design to double the channels (the more the merrier).

I'll let you know if I hit a problem with the DMM6500 behavior,

It's alive!!!!

I still need to buy more solid-state relays to populate the rest of the board but what's there seems to work flawlessly (so far), silent and fast. Since I was trying to keep the cost as low as possible (you can tell from the all DIY PCB board), the relays are not the best, the on state resistance of each channel is around 2 Ohm. But it's not a big deal as I have plenty of channels to use kelvin connections if needed. A $12 Atmega32u4 based board is handling all the logic.

(top board: Keithley 2000-Scan with wires attached for protocol sniffing)
(bottom board: DIY 20-chan solid state scan card)
« Last Edit: May 10, 2019, 05:35:42 am by cozdas »
 
The following users thanked this post: TiN, thm_w, exe, shodan@micron, hwj-d, alm, Brad O, eplpwr

Offline kado

  • Regular Contributor
  • *
  • Posts: 51
  • Country: de
New Keithley DMM6500 and now DAQ6510
« Reply #474 on: May 10, 2019, 07:03:10 am »
cozdas

[emoji106]amazing! That’s an interesting project. Please keep us informed.

Karsten


Gesendet von iPhone mit Tapatalk
 
The following users thanked this post: cozdas


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf