...
The update isn't accepted by my dmm6500:
Error 2310
Not enough memory to perform upgrade
Fresh fat32-stick's, two tested.
All reset, also without main-power for a while.
It installed for me. I upgraded from 1.0.03.c
Can you check via MENU -> Reading Buffers if there aren't big buffers stored on the system?
When you click on the defbuffer1 button, you see all the buffers stored on your meter. You can delete the non-standard ones.
...
It installed for me. I upgraded from 1.0.03.c
Can you check via MENU -> Reading Buffers if there aren't big buffers stored on the system?
When you click on the defbuffer1 button, you see all the buffers stored on your meter. You can delete the non-standard ones.
Thanks for your response. Yes, i emptied defbuffer1, deleted all other buffers manually.
Can you open the downloaded firmware file in an archive program like 7-ZIP? It's an archive that contains a mix of other archives and a txt file.
Can you open the downloaded firmware file in an archive program like 7-ZIP? It's an archive that contains a mix of other archives and a txt file.
Yes. Zip-File is original, "ki_DMM6500_v1_0_04b.upg" used.
I'm a slightly older IT-consultant and application-programmer since the beginning of the µP-aera in the heterogeneous environment.
I have no further hints and tricks then
.
my experience: I used a 1 GB USB, formatted as FAT. The .upg file is the only file on the drive.
I have no autostart or other scripts stored in the meter's persistent storage
That's a problem from the dmm itself.
Apparently, in my opinion there is actually no method to put the device into a cleaned ground state. For example, after all the reset methods described, there are still scripts in memory that you have created yourself (small, no autoexec). these are not causing the problem, but they show that the writable memory is actually not completely erased.
Finally, another quick firmware release went out, 1.0.04. I don't think it addresses anything that's been mentioned here but the release notes/downloads are at these links:
DMM6500: https://www.tek.com/digital-multimeter/dmm6500-software/dmm6500-firmware-v1004-and-release-notes
DAQ6510: https://www.tek.com/digital-multimeter/daq6510-software/daq6510-firmware-v1004-and-release-notes
The update isn't accepted by my dmm6500:
Error 2310
Not enough memory to perform upgrade
Fresh fat32-stick's, two tested.
All reset, also without main-power for a while.
Did you manually power cycle the box immediately before trying to upgrade? Manually deleting buffers and variables might not free up enough memory for an upgrade due to fragmentation of the memory space I've talked about before. Engineering is working on a solution to that for the next firmware, but currently, memory can still become fragmented and limit the maximum size of memory objects. Restarting the box is the way to completely reset the volatile memory.
Scripts are stored in non-volatile flash memory so they purposefully persist when you power cycle the instrument. When the box starts up, they're loaded into volatile memory so you can immediately access them from a remote interface or from the front panel. How many scripts do you have on your box? What does it say for available space at the bottom left of MENU > Manage (under Scripts)?
Finally, another quick firmware release went out, 1.0.04. I don't think it addresses anything that's been mentioned here but the release notes/downloads are at these links:
DMM6500: https://www.tek.com/digital-multimeter/dmm6500-software/dmm6500-firmware-v1004-and-release-notes
DAQ6510: https://www.tek.com/digital-multimeter/daq6510-software/daq6510-firmware-v1004-and-release-notes
The update isn't accepted by my dmm6500:
Error 2310
Not enough memory to perform upgrade
Fresh fat32-stick's, two tested.
All reset, also without main-power for a while.
Did you manually power cycle the box immediately before trying to upgrade? Manually deleting buffers and variables might not free up enough memory for an upgrade due to fragmentation of the memory space I've talked about before. Engineering is working on a solution to that for the next firmware, but currently, memory can still become fragmented and limit the maximum size of memory objects. Restarting the box is the way to completely reset the volatile memory.
That's the first what I do, yes.
Scripts are stored in non-volatile flash memory so they purposefully persist when you power cycle the instrument. When the box starts up, they're loaded into volatile memory so you can immediately access them from a remote interface or from the front panel. How many scripts do you have on your box? What does it say for available space at the bottom left of MENU > Manage (under Scripts)?
At last only autoexec, without something i wrote in to that.
92% memory free.
Should I delete autoexec?
Ok. I got it.
Upgrading successed.
In the autoexec are something like this:
-- set up reading buffers
KSBuffer = buffer.make(5000000,buffer.STYLE_STANDARD)
KSBuffer.fillmode = buffer.FILL_CONTINUOUS
That was something to much.
But: i deleted and emptied all buffers before upgrading, after powecycling, several times, except buffer defbuffer1, which i only emtied. The memory free shows always 92% as now after upgrading too.
But problem solved after deleting that autoexec.
Ok. I got it.
Upgrading successed.
In the autoexec are something like this:
-- set up reading buffers
KSBuffer = buffer.make(5000000,buffer.STYLE_STANDARD)
KSBuffer.fillmode = buffer.FILL_CONTINUOUS
That was something to much.
But: i deleted and emptied all buffers before upgrading, after powecycling, several times, except buffer defbuffer1, which i only emtied. The memory free shows always 92% as now after upgrading too.
But problem solved after deleting that autoexec.
Aha! So as soon as you start up the instrument, ~75% of your memory was taken up by a reading buffer. So, yes, deleting that buffer
should've freed up all that space again, except for the memory fragmentation. Like I said, that's something we're working on so now engineering can use your autoexec code as an usage example, thank you! Glad you were able to upgrade!
I have a DMM6500 now on my desk, a colleague of mine bought one to the company. This is a seriously confusing and disappointing bit of gear. First of all, I had a BSOD on it. And the entire digitize and trigger model is just complicated as hell. With some settings, the screen just start blinking, showing random data. With some other settings it takes measurement every now and then, and it just extrapolates the data between it? Or it shows me that the maximum number of samples can only be 7870020 samples, and then doesnt fill in this number into the input field?
It feels like this was made by robots, who wanted to tick all the boxes, but no real though put into how to use a meter.
Update the firmware to the latest version and RTFM. This is a very complex and powerful meter. I think they did a great job implementing all those features on a limited UI (screen-size, mainly).
BR,
Michael
My experience is different. I found it easy to get started.
I have a DMM6500 now on my desk, a colleague of mine bought one to the company. This is a seriously confusing and disappointing bit of gear. First of all, I had a BSOD on it. And the entire digitize and trigger model is just complicated as hell. With some settings, the screen just start blinking, showing random data. With some other settings it takes measurement every now and then, and it just extrapolates the data between it? Or it shows me that the maximum number of samples can only be 7870020 samples, and then doesnt fill in this number into the input field?
It feels like this was made by robots, who wanted to tick all the boxes, but no real though put into how to use a meter.
This dmm has a whole new approach as we know of the previous conventional type with measuring instruments of this type and offers far more possibilities. This gives rise to the problem of the gui developers of casting these into a mould which, on the one hand, must be consistent in terms of its technical possibilities and, on the other hand, must be as conclusive as possible from the user's point of view.
This results in two learning curves
- for the developers to integrate these comprehensive new possibilities into the matching gui and api,
- for the user to discover this new concept to make it usable for oneself by sorting out this mistakes despite the imperfect previous named path.
That is the compromise to be entered into, which we have to go together with such kind of measuring instruments.
We remember that gui and programming interfaces of measuring instruments of the previous conventional type have undergone decades of development on both sides.
Another compromise is the much cheaper technical implementation compared to his bigger brother DMM7510.
NANDBlog
I had the DMM7510 before already and therefore the DMM6500 was easy to use for me!
May be you should watch a few videos online to get you started.
After a little learning curve, this instrument is easy to use.
I have a DMM6500 now on my desk, a colleague of mine bought one to the company. This is a seriously confusing and disappointing bit of gear. First of all, I had a BSOD on it. And the entire digitize and trigger model is just complicated as hell. With some settings, the screen just start blinking, showing random data. With some other settings it takes measurement every now and then, and it just extrapolates the data between it? Or it shows me that the maximum number of samples can only be 7870020 samples, and then doesnt fill in this number into the input field?
It feels like this was made by robots, who wanted to tick all the boxes, but no real though put into how to use a meter.
Well, digitizing and the trigger model are the most complicated topics so that's pretty understandable you'd have trouble with them. I gave a small walkthrough of a basic trigger model
back in this post, it might help you feel more comfortable with how the blocks work. There are also a few videos on the digitize functions if you search YouTube.
This video on the DMM6500's webpage explains most of the common settings while performing a short demo.
If you think there's some explanation lacking in our documentation though I can try explaining it here or put out a new video that goes over it if it's complicated enough.
EDIT: Oh! A little preview feature I think you all will like: The latest dev firmware is much stricter about what values are allowed for the graph divisions. It now snaps to whole numbers like 4uV/div or 200mV/div rather than things like 2.448uV/div or 406.3mV/div.
Cool, looking forward to it!
While you're on it, can you also please make sure that the graph Y axis numbers show the informative, distinct digits rather than the common thus non-informative ones? Check the attached images: here the Y range is less than 100uV though in the current implementation Y axis numbers show the 10mv, 1mv and 100uV digits, totally missing the important part. Something like the second image is what I'd expect to see.
EDIT: Oh! A little preview feature I think you all will like: The latest dev firmware is much stricter about what values are allowed for the graph divisions. It now snaps to whole numbers like 4uV/div or 200mV/div rather than things like 2.448uV/div or 406.3mV/div.
Cool, looking forward to it!
While you're on it, can you also please make sure that the graph Y axis numbers show the informative, distinct digits rather than the common thus non-informative ones? Check the attached images: here the Y range is less than 100uV though in the current implementation Y axis numbers show the 10mv, 1mv and 100uV digits, totally missing the important part. Something like the second image is what I'd expect to see.
Right. It has been pointed out for some time that the y-axis is hardly meaningful in this form.
A little tip, with many measuring points, the image becomes a little bit clearer (edit: but without peaks) if someone only lets it be displayed as line.
A little tip, with many measuring points, the image becomes a little bit clearer (edit: but without peaks) if someone only lets it be displayed as line.
While I was preparing an image for the reply, you already edited your message to mention the gotcha with the line mode (missing peaks)
.
I'm guessing that currently the markers are drawn on top of the lines so that when the samples per pixel count is less than one, you get lines connecting the sparse dots. But when the number of samples per pixels is greater than one, I think the averaged line should be drawn on top of the peak showing markers so that you can get more information in a single graph and the "both" mode becomes different than the "marker" mode. Something like this:
cozdasI wonder how you can get these pictures, which the dmm is hardly capable of without scripting.
ps and ot: my R&S RTB2002 is generating such traces in real.
...With some settings, the screen just start blinking, showing random data. With some other settings it takes measurement every now and then, and it just extrapolates the data between it? ...
I know what you mean, some parts are not really intuitive and there are many rough edges for sure, especially with the graphing part. AFAIK this is their first graphing line after all.
"Group of readings" part is not very well explained in the documents, and I was confused by that part too (user's manual doesn't mention it at all, reference manual has a brief mention). Also probably for handling the large data efficiently on the screen, they seem to have a hierarchical visual representation of the data; when zoomed out, the min, max and averaged values of "many samples" are displayed as a single line. Sometimes this "Level Of Detail" part gets confused and shows a coarser view. This happens very often with the fast digitize setups in my experience but can happen anytime if you play with the axis scale options (See the images). Pinch-zoom is usually enough to unconfuse it
Many rough edges, true, but still a very versatile device. I'm hoping that Keithley keeps resources dedicated for fixing the bugs.