I believe there is something missing from your post.
Firmware and instructions is available here (http://riglol.3owl.com/firmware/DP832.zip). (Note, from the US and using TimeWarnerCable, I had to go through a EU proxy to load the Riglol page...)Try EEVblog member Avotronics (https://www.eevblog.com/forum/profile/?u=89989)' mirror site here instead then: http://rigol.avotronics.co.uk/mirrors/riglol/firmware/DP832.zip (http://rigol.avotronics.co.uk/mirrors/riglol/firmware/DP832.zip)
Firmware and instructions is available here (http://riglol.3owl.com/firmware/DP832.zip). (Note, from the US and using TimeWarnerCable, I had to go through a EU proxy to load the Riglol page...)Try EEVblog member Avotronics (https://www.eevblog.com/forum/profile/?u=89989)' mirror site here instead then: http://rigol.avotronics.co.uk/mirrors/riglol/firmware/DP832.zip (http://rigol.avotronics.co.uk/mirrors/riglol/firmware/DP832.zip)
You can add this info to your original post.
Are you sure problem #2 wasnt resolved in firmware 1.06 already? I got mine two weeks ago and it came with v1.06 and the new heatsink, but doesn't have issue #2.
I have discovered an other bug a week or two ago, but I wasn't sure if it actually was a bug. With FW 08 you can turn on a mode where CH1 and CH2 are enabled at the same time in tracking mode, which is pretty handy i think. But the problem was that if you reboot the thing it would reset that option...
Updated DP832A from
Dig: 00.01.04.00.02 to 00.01.08.00.02
An: 01.01.05.01.01.05 to 01.02.00.01.02.00
The licenses are unchanged, all still shown as "official".
ADC cal works in that it outputs expected value, did not try saving.
Did anyone get the SCPI commands to work as in the "DP800 Calibration Guide"?
Mine don't! (V1.08.00.02)
I have discovered an other bug a week or two ago, but I wasn't sure if it actually was a bug. With FW 08 you can turn on a mode where CH1 and CH2 are enabled at the same time in tracking mode, which is pretty handy i think. But the problem was that if you reboot the thing it would reset that option...
I just tested this on my unit which is running FW 01.03 and this bug is not present. It seems this issue has appeared in FW 01.08. For anyone who tests this, make sure the "Power On" option is set to "Last" and not "Default".
I upgraded my DP832 from FW 06 to 08 with the following results:
I (only) lost the 'Trigger' Option, but everything else is Ok, including the fact that Calibration was NOT altered. So I call this a big success, with the loss of Trigger considered a secondary or worthy sacrifice for the other benefits. All other options are still OK!
I tried reinstalling Trigger in FW 08, but I got an 'invalid key' response. It worked in FW 06, so apparently there is an issue with the Trigger key, the Trigger option changing, or otherwise having been disabled in FW 08(?).
So from what I have experienced the Trigger option is the only issue, and this should probably be reported to Rigol as a bug (by whoever is collecting and reporting the bugs).
The Firmware Installation Instructions are attached below: Although there is a serious flaw in the form of missing information. Change Step 4. as follows: --> Step 4. Power on the DP800 'and when you see the RIGOL logo (icon) press the Help key to place the unit into Upgrade Mode. This is indicated on the display.'
Delete Step 5, and go directly to Step 6.
ted572,
Did you do a downgrade 1.06 / upgrade 1.08?
mine came with v1.08.
After the downgrade to 1.06, options installed fine, but calibration was off,
and options lost on upgrade to 1.08, calibration still off and ADC doesn't work :(
ted572,
Did you do a downgrade 1.06 / upgrade 1.08?
mine came with v1.08.
After the downgrade to 1.06, options installed fine, but calibration was off,
and options lost on upgrade to 1.08, calibration still off and ADC doesn't work :(
Did you follow the calibration procedure? See first post for instructions in attachment.
ted572,I have an older unit that was still at FW 06. I waited until today to upgrade because of the issues I read about with others upgrading.
Did you do a downgrade 1.06 / upgrade 1.08?
mine came with v1.08.
After the downgrade to 1.06, options installed fine, but calibration was off,
and options lost on upgrade to 1.08, calibration still off and ADC doesn't work :(
ted572,
Did you do a downgrade 1.06 / upgrade 1.08?
mine came with v1.08.
After the downgrade to 1.06, options installed fine, but calibration was off,
and options lost on upgrade to 1.08, calibration still off and ADC doesn't work :(
Did you follow the calibration procedure? See first post for instructions in attachment.
Ok, I have to ask this question.
Did anyone sucessfully DOWNGRADE from v1.08 to v1.06, install options, and retain them (and
calibration) on upgrading back to to v1.08 (with working ADC) I wonder?
Can any one direct me to a list of bugs that were fixed in 1.08? I'd like to determine if its worth the upgrade effort from 1.06 and I can't seem to find firmware revision history on Rigol's website.That is a very good question, and I would also like to know what has been changed. My primary concern was to know that I could update the FW to 08 without loosing the options. As it turned out I (and recently a few others) have only lost the Triggering option. Hey that's Ok. Now at least I can feel relatively confident that my DP800 won't be dead in the water the next time a FW update comes out of Rigol.
"After DP800 installs the file, and the DP800 automatically reboots. Remove the USB Flash Drive with the .GEL file."Automatically reboots was my description in the simplified process I listed for you, to give you an idea what the steps are involved. Perhaps this was wrong, it may actually be simply a quick restart without going through the normal boot screen, etc.
No automatic reboot with mine!
3. Current sense between channels 2 and 3I think you should attach this document:
Issue documented here (https://www.eevblog.com/forum/testgear/another-issue-with-the-rigol-dp832-power-supply-sense-wires-carrying-3-amps!/) and see Dave's post here (https://www.eevblog.com/forum/blog/eevblog-512-rigol-dp832-bad-design-investigation/msg320900/#msg320900) for the Rigol response: DIY fix with heavy duty wire between GND terminals of channel 2 and 3!
I think you should attach this document:
Recommended Connections: DP832 CH2 and CH3 COM Terminals
http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-034c/1/-/-/-/-/DP832%20Proper%20Connections.pdf (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-034c/1/-/-/-/-/DP832%20Proper%20Connections.pdf)
Thanks! I have attached this new version document. The formulas still look messed up for me, but perhaps I don't have a necessary font installed... Oh well, hopefully it will work for others!Yes you are right, the formulas are actually messed up in both version, I didn't pay attention to what the formulas actually said, just noticed the symbols are not overlapping each other anymore. But instead it's now wrong math symbols.
Thanks! I have attached this new version document. The formulas still look messed up for me, but perhaps I don't have a necessary font installed... Oh well, hopefully it will work for others!Yes you are right, the formulas are actually messed up in both version, I didn't pay attention to what the formulas actually said, just noticed the symbols are not overlapping each other anymore. But instead it's now wrong math symbols.
See attached screenshots.
Ok, I have to ask this question.
Did anyone sucessfully DOWNGRADE from v1.08 to v1.06, install options, and retain them (and
calibration) on upgrading back to to v1.08 (with working ADC) I wonder?
What seems strange to me is that the only option that I lost going from FW 06 to 08 was Trigger. And BTW others that did the upgrade in the past couple of days also only lost Trigger. Granted I didn't go from 08 back down to 06, install options, and then go back up to 08 again. But, so many people have said they lost all of their options, that I started to think that those people may simply had not followed the Rigol upgrade instructions precisely. There are three (3) different installations that must be done in the Firmware installation. Are you sure that you covered all three (3) situations?
The three situations are as follows:
1. Turn ON DP800, Press Help when RIGOL icon comes up up. Install USB Flash Drive with the .GEL upgrade file when prompted.
After DP800 installs the file, and the DP800 automatically reboots. Remove the USB Flash Drive with the .GEL file.
2. Press Help twice. Press M4, M2, M1 to update Analog Board 1.
3. Press M4, M2, M2 to update Analog Board 2.
Last: Reboot, press Utility > SysInfo > M1, M3, M2 to verify installed FW version.
Did you do all of this? This is MUCH more than your typical Rigol FW update requires. If after reading this, if you have any doubt about it, don't understand something, etc, please let me know and I will try to help.
Today I received a newly bought DP832 after nearly a months wait. Luckily it came with 1.08 firmware, I was a bit afraid it should be delivered with 1.09, preventing me from generating a key.Thank you, it is nice to have 'Trigger' verified as being a Bug in version .08.
As far as I have understood there isn't really any improvements between 1.06 and 1.08, so I'm planning for a downgrade making it ready for a key the day I need it.
Today I received a newly bought DP832 after nearly a months wait. Luckily it came with 1.08 firmware, I was a bit afraid it should be delivered with 1.09, preventing me from generating a key.Thank you, it is nice to have 'Trigger' verified as being a Bug in version .08.
As far as I have understood there isn't really any improvements between 1.06 and 1.08, so I'm planning for a downgrade making it ready for a key the day I need it.
...
Today I received a newly bought DP832 after nearly a months wait. Luckily it came with 1.08 firmware, I was a bit afraid it should be delivered with 1.09, preventing me from generating a key.
Partial quote: The reason I did edit it was that I realized that I was potentially wrong in my conclusion that all options except trigger was enabled as time trials. The reason I thought so was because when i looked at the sys info menu all options on that screen had TRIAL on them, except the trigger option that was marked disabled. But when I later looked at the option menu I realized that there was more options available than what was displayed at the sys info page, and at that page there was more options besides trigger that was marked as disabled.carpelux:
Just remembered one more thing.Re. carpelux's Reply #41: So from your experience this verifies that there is a Bug in firmware .08 that disables the 'Trigger' option of the Digital I/O. Nothing else new that we know of at this time anyway.
The accuracy option wasn't listed at all on the "Sys info" page from the beginning, neither as Trial or disabled.
I have just received my DP832A with the shiny silver heat sink. It shipped with 1.08
I upgraded to 1.09.00.01, as I wanted the classic color screen.
Analog board: 01.02.00.01.02.00
Boot 1.06
before the upgrade my temp on startup was 29.6, now its at 10.26 :-//
I have a DP832 which I updated to 01.08 following the three step instructions and everything went well but I now see that "Sparky's" complete list of firmware and bugs recommends having 01.06 on a DP832.
My question is when going back to 01.06 from 01.08 will I have to update the analogue boards as when going from .06 to .08 the same way or just load the firmware?
I see lots of reference to keys or hacks to unlock features on the DP832 but can't find any info explaining how etcIt's all in this very long topic: https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/ (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/)
- it also looks like the latest firmware closes these advantages but wondering if someone has found a way round this yet?No.
What is the latest on Rigol DP832?
I noticed the first post: Last Edit: March 15, 2014, 08:59:02 AM by Sparky
Have there been any further fixes by Rigol, or if I go and get a new one now, will I still come across these issues?
The spike only happens when the physical rocker switch is moved from the 'off' position to the 'on' position. NOT when the individual channel power soft buttons are used. That is just something that i keep in mind when I power it on. It is essentially fixed, for me, because I know about the limitation and I account for it.
00.01.03.00.02 (installed at manufacture)Why do you only recommend 00.01.06.00.00 for DP832, when 00.01.09.00.01 is recommended for DP832A?
00.01.04.00.02 (installed at manufacture; possibly DP832A only)
00.01.06.00.00 (date 07/09/2013) << recommended for DP832
00.01.08.00.02 (date 10/30/2013)
00.01.09.00.01 (date 12/27/2013) and bootloader 01.06 (date 12/27/2013) << recommended for DP832A: see here (https://www.eevblog.com/forum/testgear/rigol-dp832-power-supply-firmware-upgrade/msg371677/#msg371677) and here (https://www.eevblog.com/forum/testgear/rigol-dp832-power-supply-firmware-upgrade/msg371748/#msg371748) and here (https://www.eevblog.com/forum/testgear/new-rigol-dc-psu's/msg405860/#msg405860)
00.01.10.xx.xx (reportedly released, but no details yet available)
00.01.03.00.02 (installed at manufacture)Why do you only recommend 00.01.06.00.00 for DP832, when 00.01.09.00.01 is recommended for DP832A?
00.01.04.00.02 (installed at manufacture; possibly DP832A only)
00.01.06.00.00 (date 07/09/2013) << recommended for DP832
00.01.08.00.02 (date 10/30/2013)
00.01.09.00.01 (date 12/27/2013) and bootloader 01.06 (date 12/27/2013) << recommended for DP832A: see here (https://www.eevblog.com/forum/testgear/rigol-dp832-power-supply-firmware-upgrade/msg371677/#msg371677) and here (https://www.eevblog.com/forum/testgear/rigol-dp832-power-supply-firmware-upgrade/msg371748/#msg371748) and here (https://www.eevblog.com/forum/testgear/new-rigol-dc-psu's/msg405860/#msg405860)
00.01.10.xx.xx (reportedly released, but no details yet available)
Is it because 00.01.09.00.01 couldn't be hacked with a keygen? Because it can now thanks to aurel's post above.
studio25's http://riglol.3owl.com (http://riglol.3owl.com) has also been updated from ver. 1.03c to ver. 1.03d to include aurel's hack for DP832 FW v1.09
Hi Andrew kindly confirm if you have been able to hack the DP 832 version 1.10 if so how did you do it as i tried but it did not work or may be i did something wrongRemember to use the new option keys for versions >= 1.09, they are different form the option keys for earlier versions:
thanks
shailesh
DP832 starting from v1.09 device options:
first character: F = official, B = trial
F3PT - Accuracy
F6PT - Analyzer and Monitor
F6LT - LAN
FALT - RS232
FLLT - Trigger
DP832 up to v1.06 device options:
first character: M = official, 5 = trial
MWSS - Trigger
MWTB - Accuracy
MWTC - LAN and RS232
MWTE - Analyzer and Monitor - Analyzer and Monitor
A license generator is now available for firmware 1.09.
Short version: download new riglol version riglol-20140717.zip (https://mega.co.nz/#!KM9mXBiT!0EwuvQY7hOcZyTOQx53wDiWKwg4PkVT8D7oqDcCRbA8)
For more details, see this post: https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg480687/#msg480687 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg480687/#msg480687)
Rigol's FW update request page, http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm?id=0012, (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm?id=0012,) says that rev 00.01.11 is available for the DP832. Has anyone received 1.11 (or 1.10) as an update from Rigol? I asked for an update saying I was currently at 1.09 and they sent me 1.09 :(
Thanks for the info! It would be nice to get these firmwares: 01.10 and 01.11 for evaluation and see what has been changed/fixed. I put in a request for 01.10 a couple of weeks ago (before 01.11 mentioned publicly) but did not get a reply.
I suspect that Rigol's FW request form is only processed by a script - if you want any response at all, you have to enter the data EXACTLY as they specify it...
Don't put anything else in that text box or Rigol's script will toss the whole request into the bit bucket.
Yes, I specified the requested fields on seperate lines and left a little note to ensure I got 1.11 and not 1.09 as some people seem to be getting.I suspect that Rigol's FW request form is only processed by a script - if you want any response at all, you have to enter the data EXACTLY as they specify it...
Don't put anything else in that text box or Rigol's script will toss the whole request into the bit bucket.
I don't think this is the case. I've generally specified all the required items, often not in the exact format requested, yet I've received email responses from actual people with firmware updates... Unfortunately not the last time, however...
Today, I have just busy with my DP832-on version 00.01.11.00.00 (bootloader 01.09 ) turned up, but not a single key from Riglol 1.03d fit. What am I doing wrong? |O
Yes, I specified the requested fields on seperate lines and left a little note to ensure I got 1.11 and not 1.09 as some people seem to be getting.
I got it today. I think the confusion is that all the documentation and bootloader are for 1.09 while the firmware is 1.11
These are the dropbox links Rigol supplied me with:Yes, I specified the requested fields on seperate lines and left a little note to ensure I got 1.11 and not 1.09 as some people seem to be getting.
I got it today. I think the confusion is that all the documentation and bootloader are for 1.09 while the firmware is 1.11
@Macbeth: Could you please upload the 01.11 firmware to a filehost (e.g. wikisend.com) for others? I would like to try it out, check against the bug list, and update the post.
Thanks!
Today, I have just busy with my DP832-on version 00.01.11.00.00 (bootloader 01.09 ) turned up, but not a single key from Riglol 1.03d fit. What am I doing wrong? |ODid you have all the options installed on 1.09 and then upgraded to 1.11 and lost them all? or did you only try putting the keys into 1.11?
There doesn't seem to be much information floating around this thread regarding changes in the recent DP800-firmwares. As Rigol unfortunately quite often doesn't seem to provide release notes with firmware updates, maybe some excerpts from the most recent v1.11 release notes will help others to decide, whether to upgrade or not:
These are the dropbox links Rigol supplied me with:
Bootloader 1.09: https://www.dropbox.com/s/y2teclo95ebqvgo/DP800%28Software%29Update%28Bootloader%29.rar?dl=0 (https://www.dropbox.com/s/y2teclo95ebqvgo/DP800%28Software%29Update%28Bootloader%29.rar?dl=0)
Firmware 1.11: https://www.dropbox.com/s/k3ydhnssk8opp24/DP800%28Software%29Update%28Normal%29.rar?dl=0 (https://www.dropbox.com/s/k3ydhnssk8opp24/DP800%28Software%29Update%28Normal%29.rar?dl=0)
These are the dropbox links Rigol supplied me with:
Bootloader 1.09: https://www.dropbox.com/s/y2teclo95ebqvgo/DP800%28Software%29Update%28Bootloader%29.rar?dl=0 (https://www.dropbox.com/s/y2teclo95ebqvgo/DP800%28Software%29Update%28Bootloader%29.rar?dl=0)
Firmware 1.11: https://www.dropbox.com/s/k3ydhnssk8opp24/DP800%28Software%29Update%28Normal%29.rar?dl=0 (https://www.dropbox.com/s/k3ydhnssk8opp24/DP800%28Software%29Update%28Normal%29.rar?dl=0)
Unfortunately, the links are "dead" now!Just ask for them from Rigol (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm?id=0012,)
Can someone to upload them, again?
Unfortunately, the links are "dead" now!Just ask for them from Rigol (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm?id=0012,)
Can someone to upload them, again?
I got mine by email within 24 hours.
I got mine by email within 24 hours.
Unfortunately, the links are "dead" now!https://www.sendspace.com/file/66f4is (https://www.sendspace.com/file/66f4is) http://www51.zippyshare.com/v/1061420/file.html (http://www51.zippyshare.com/v/1061420/file.html)
Can someone to upload them, again?
Unfortunately, the links are "dead" now!https://www.sendspace.com/file/66f4is (https://www.sendspace.com/file/66f4is) http://www51.zippyshare.com/v/1061420/file.html (http://www51.zippyshare.com/v/1061420/file.html)
Can someone to upload them, again?
Hi,
BTW, does anyone already tried this new FW on a DP832 ? If so, does the keys remain ?
Cheers.
---
Daniel
Great, I updated my bootloader from 1.06 to 1.09 and my firmware from 1.09 to 1.11 and I still have all my Riglol options :-DD
Great, I updated my bootloader from 1.06 to 1.09 and my firmware from 1.09 to 1.11 and I still have all my Riglol options :-DD
Looks like you didn't go through the procedure to update your analog 1 & 2 boards.
Looks like you didn't go through the procedure to update your analog 1 & 2 boards.
What's exactly that makes you laugh so loud?
You humourless assburger. Do you not understand that RigLOL is a funny name for the software? LOL = Laughing Out Loud. I'm happy to be amused by the provider of Riglol 1.3 :palm:
What bothers me is to see keygen users who enjoy the results of the unlock with loud laughs and pride as if they were somehow part of the hack, as if they themselves were able to outwit Rigol. While they are only consumers. This was my point.Dude, you are reading far more into this "consumers" posts. It's unfortunate that you wind yourself up over it too so your fantasy of my intentions even *bothers* you. Take a chill pill and relax. You will end up with high blood pressure or something otherwise. I laughed at RigLOL is all, and I have no pride or think I am part of the hack whatsoever. :phew:
As you probably see, english is not my native language, so probably I've abused of the word "bother". However, it's only my opinion :-// Never mind.Me too, high blood pressure that is :( You have infinitely better English than my Italian that is for sure! :-+
p.s. high pressure? I have it, thanks! ^-^
Thank you very much for the new firmware link! :DUnfortunately, the links are "dead" now!https://www.sendspace.com/file/66f4is (https://www.sendspace.com/file/66f4is) http://www51.zippyshare.com/v/1061420/file.html (http://www51.zippyshare.com/v/1061420/file.html)
Can someone to upload them, again?
There is a bug in firmware 00.01.11.00.00 relating to manual calibration. If you have installed this firmware then don't perform manual calibration on either V DAC or I DAC. Calibration of V ADC and I ADC appears to work properly though.Are you saying calibration of "V DAC" and "I DAC" via a PC works correctly? Please clarify and elaborate.
Calibration via a PC works fine.
Are you saying calibration of "V DAC" and "I DAC" via a PC works correctly? Please clarify and elaborate.
If you try and calibrate V DAC or I DAC via the GUI then the corresponding channel on your DP832/A will not work properly.
There is a bug in firmware 00.01.11.00.00 relating to manual calibration. If you have installed this firmware then don't perform manual calibration on either V DAC or I DAC. Calibration of V ADC and I ADC appears to work properly though.
Calibration via a PC works fine.
QuoteIf you try and calibrate V DAC or I DAC via the GUI then the corresponding channel on your DP832/A will not work properly.
That's an understatement. I tried to calibrate one channel of a DP832 (rev 1.11) and created a total mess. I've retried half a dozen times. No luck.
QuoteIf you try and calibrate V DAC or I DAC via the GUI then the corresponding channel on your DP832/A will not work properly.
That's an understatement. I tried to calibrate one channel of a DP832 (rev 1.11) and created a total mess. I've retried half a dozen times. No luck.
Sounds like we had a similar experience. I wasted far too much time on this myself. |O
I totally screwed up the calibration to the point where it would output an overvoltage and trip OVP, when the output was turned off! Got it closer once I realised how the values were getting screwed up. All good now fortunately.
Ahhh... I understand now. Thank you very much for that clarification. :)Are you saying calibration of "V DAC" and "I DAC" via a PC works correctly? Please clarify and elaborate.
Yes. The bug appears to affect manual calibration via the GUI only. If you try and calibrate V DAC or I DAC via the GUI then the corresponding channel on your DP832/A will not work properly.
Like à continuous OVP alarms ? On channel 1 only ?
Have you tried to flash back to 1.10 ?
Like à continuous OVP alarms ? On channel 1 only ?
Yes. Turned on DP832A and, after powering-up, an immediate OVP alarm. The control panel buttons were almost unusable due to the constant alarm as well. I could only stop the OVP alarm under software control.QuoteHave you tried to flash back to 1.10 ?
I was unable to reflash to an older firmware version.
WHY are people upgrading firmware in cases where the existing firmware is not causing issues?
Can anyone explain? One has a device that works as it is just fine, then chooses to apply firmware right after it is made available?
Tell me I'm missing something.
If it isn't broke... I'm on 1.06 and I've not had a single issue. And I don't ever plan on upgrading. There's no need to, the thing works just fine.
WHY are people upgrading firmware in cases where the existing firmware is not causing issues?
Can anyone explain? One has a device that works as it is just fine, then chooses to apply firmware right after it is made available?
Tell me I'm missing something.
If it isn't broke... I'm on 1.06 and I've not had a single issue. And I don't ever plan on upgrading. There's no need to, the thing works just fine.
Can a DP832 be flashed to become a DP832A? If yes, can the model change be made without sacrificing the ability to enable upgrade options (http://riglol.3owl.com/)?
Thank you very much for your prompt reply and toleration of my ignorance.Can a DP832 be flashed to become a DP832A? If yes, can the model change be made without sacrificing the ability to enable upgrade options (http://riglol.3owl.com/)?
Technically yes, but I am not aware of it being done outside of the Rigol factory. Aside from cosmetic differences they are the same hardware.
If you were able to modify the model to a DP832A then you wouldn't be sacrificing any options, since the A model has all options already enabled. ;D
WHY are people upgrading firmware in cases where the existing firmware is not causing issues?
Can anyone explain? One has a device that works as it is just fine, then chooses to apply firmware right after it is made available?
Tell me I'm missing something.
If it isn't broke... I'm on 1.06 and I've not had a single issue. And I don't ever plan on upgrading. There's no need to, the thing works just fine.
I appreciate the time and the effort that you made to dispense your wisdom here. However, no one is forcing you, or anyone else for that matter, to upgrade. We're just sharing our experiences here.
Did you happened to read the OP or even the subject line?
In any case, this particular issue with 1.11 is really a non-issue unless you intend to calibrate your PSU. The reason I posted here about it was to make others aware of the issue in order to avoid potential problems.
And since you asked... I upgraded my DP832A specifically in order to add the 'Classic' GUI. I don't really like the standard triangle GUI that is on the DP832A. However, I would have upgraded anyhow, unless any major issues were first raised. I like to have the latest firmware, to be on the cutting edge. But that's just me. :D
Yes, I ended up wasting time with calibration issues, but in the end things worked out better than I expected. The calibration is now perfect, where previously it was out by a couple of mV on both indication and set-point.
WHY are people upgrading firmware in cases where the existing firmware is not causing issues?
And if none of us try firmware updates, how could we know if bugs are fixed or introduced ? Doesn't the point of this thread ?
Read (or ASK for) the changelog and carefully examine what fixes/improvements has been made with the new firmware.
NEW 2014 > DP800 Calibration Guide attached:
NEW 2014 > DP800 Calibration Guide attached:Wow! ;D
NEW 2014 > DP800 Calibration Guide attached:The main difference between this Jan '14 manual and the previous one is that they no longer tell you to use the SCPI interface to enter the commands “:Cal:Start 2012,CH1" and "Cal:Clear CH1,ALL" as the first step of calibration.
Actually, it does. On page 2-2 it says:QuoteNEW 2014 > DP800 Calibration Guide attached:The 'new' manual still still doesn't tell you to use the On/Off buttons to enable the channel you want to calibrate. You get a whole lot of nothing if you don't turn on the channel before starting calibration.
Carpelux, I think you misunderstood TooOldForThis.Actually, it does. On page 2-2 it says:QuoteNEW 2014 > DP800 Calibration Guide attached:The 'new' manual still still doesn't tell you to use the On/Off buttons to enable the channel you want to calibrate. You get a whole lot of nothing if you don't turn on the channel before starting calibration.
3. Turn on DP800 and press the channel selecting key at the front panel to select
CH1 as the channel to be tested. Set the voltage and current of the channel
under test according to Table 2-1. Then, press the On/Off key corresponding to
the channel under test to enable the output of the channel.
2. Press the On/Off softkey corresponding to CH1 at the front panel of DP800 to
enable the channel output
Yes, You seems to be right. It looks like I messed up the documents.You are correct, carpelux.
But if You look in the "new" manual, on page 2-3 (page 11 in the pdf) it says:Quote2. Press the On/Off softkey corresponding to CH1 at the front panel of DP800 to
enable the channel output
I just got a brand new top PCB card from Rigol.eu... I will take some pictures because it's a modified design, rev is 02.20 from 2013-11-05, with an IRFP260N.I'm very curious to see your top PCB photos.
I just got a brand new top PCB card from Rigol.eu... I will take some pictures because it's a modified design, rev is 02.20 from 2013-11-05, with an IRFP260N.I'm very curious to see your top PCB photos.
I very recently bought a new DP832, so I am wondering if my new unit also has the version 2.20 TopBoard (top PCB). Is there any way I can discover the hardware version of the TopBoard in my new DP832 without opening the case?
How do i fix "analog board self fail" . Please Help
Hi,
Could you give us a bit more informations?
Cheers.
---
Daniel.
Hi,
Could you give us a bit more informations?
Cheers.
---
Daniel.
Digital version :00.01.09.00.01
Analog Version :00:00:00:00:00:00
boot Version :01.06
Keyboard Version :01.01
Should I try upgrading the firmware first ?
It does not detect the USB stick. Do you have any pictures which connection I sould be looking for
You don't need anything for updating analog boards.
First, press "Help, Help, M4, M2, M1" to update the board1.
Then, press this sequence twice: "M4, M2, M2" to update the board2.
But I'm far from sure that will fix your problem.
Cheers.
---
Daniel.
You don't need anything for updating analog boards.
First, press "Help, Help, M4, M2, M1" to update the board1.
Then, press this sequence twice: "M4, M2, M2" to update the board2.
But I'm far from sure that will fix your problem.
Cheers.
---
Daniel.
Its Fixed. I was just a loose ribbon cable between the analog board and the digital display board.
Thanks for your help Daniel
DEAR GROUP
just unboxed my dp832 it has firmware version 1.10 i tryied using the rigol keygen and it says invalid serial number. Has any body else have this problem. i tryied typing in the generated key several times and used the hi res option and the analiser monitor option. is this version FW locked? do i need to downgrade? any advise or further information I can give you folks please chime in. I will do more research tonight from work thanks in advance
yes used the same link you psted tryied the versions as you suggested starting with F |OHow many digits in the code which you are trying to type?
do u think i may have to try to downgrade the FW? How would one go about that on the dp832? Hopefully the bootloader will support that :(
DEAR GROUP
just unboxed my dp832 it has firmware version 1.10 i tryied using the rigol keygen and it says invalid serial number. Has any body else have this problem. i tryied typing in the generated key several times and used the hi res option and the analiser monitor option. is this version FW locked? do i need to downgrade? any advise or further information I can give you folks please chime in. I will do more research tonight from work thanks in advance
yes used the same link you psted tryied the versions as you suggested starting with F |O
do u think i may have to try to downgrade the FW? How would one go about that on the dp832? Hopefully the bootloader will support that :(
just unboxed my dp832 it has firmware version 1.10 i tryied using the rigol keygen and it says invalid serial number. Has any body else have this problem. i tryied typing in the generated key several times and used the hi res option and the analiser monitor option. is this version FW locked? do i need to downgrade? any advise or further information I can give you folks please chime in. I will do more research tonight from work thanks in advance
There is a bug in firmware 00.01.11.00.00 relating to manual calibration. If you have installed this firmware then don't perform manual calibration on either V DAC or I DAC. Calibration of V ADC and I ADC appears to work properly though.
Calibration via a PC works fine.
I wonder why I don't see "Analog Version", "Boot Version" or "Keyboard version"
QuoteI wonder why I don't see "Analog Version", "Boot Version" or "Keyboard version"
You have to press extra buttons to get extended information.
Press Utility > SysInfo > M1, M3, M2
where "M1" is is the left-most button on the bottom of the display.
- Analog Version: 02.02.02.02.02.02
Quote- Analog Version: 02.02.02.02.02.02
Did you mean "01.02.02.01.02.02"?
Quote- Analog Version: 02.02.02.02.02.02
Did you mean "01.02.02.01.02.02"?
A few months ago I ran Rigol's published instructions for manually calibrating a DP800 and wound up with a broken power supply. DP832 rev 1.11 has a serious bug in its manual calibration software. Any channel manually calibrated while running 1.11 becomes unusable.
Rigol obviously doesn't use the manual calibration process on their production line, they must use SCPI commands in an automated process. Unfortunately, Rigol left the calibration commands out of their DP800 Programming Guide. I set out to remedy that.
In the attached document I've documented the remote calibration commands and how to use them. I was able to fix my broken DP832 using this stuff.
In the attached document I've documented the remote calibration commands and how to use them. I was able to fix my broken DP832 using this stuff.Wow! Great stuff - very much appreciated. :-+
A few months ago I ran Rigol's published instructions for manually calibrating a DP800 and wound up with a broken power supply. DP832 rev 1.11 has a serious bug in its manual calibration software. Any channel manually calibrated while running 1.11 becomes unusable.
Rigol obviously doesn't use the manual calibration process on their production line, they must use SCPI commands in an automated process. Unfortunately, Rigol left the calibration commands out of their DP800 Programming Guide. I set out to remedy that.
In the attached document I've documented the remote calibration commands and how to use them. I was able to fix my broken DP832 using this stuff.
A few months ago I ran Rigol's published instructions for manually calibrating a DP800 and wound up with a broken power supply. DP832 rev 1.11 has a serious bug in its manual calibration software. Any channel manually calibrated while running 1.11 becomes unusable.
Rigol obviously doesn't use the manual calibration process on their production line, they must use SCPI commands in an automated process. Unfortunately, Rigol left the calibration commands out of their DP800 Programming Guide. I set out to remedy that.
In the attached document I've documented the remote calibration commands and how to use them. I was able to fix my broken DP832 using this stuff.
Thank you very much for providing information on how to calibrate the DP832 Power Supplies. I for one appreciate this very much, and I'm sure everyone else here does also.
It is sometimes hard for me to keep track of everything required when carrying out an involved alignment/calibration procedure, where a single mistake can result in having to start over again, and sometimes again. . . If you know what I mean. So I put together a quick draft summation for my use. This has proven very helpful to me. And a friend of mine suggested posting it here in the event someone else could possibly benefit from it. Please if you, or anyone else, sees something as being incorrect, please let me know and I will correct and re-post if significant.
I received the Update 00.01.13.00.01 today. Anyone else too?Any idea what the update has improved? Do the "naughty" Riglol hacks still work?
I wonder if someone can check if the calibration bug has been resolved??
QuoteI wonder if someone can check if the calibration bug has been resolved??
I loaded 1.13 and tried manual cal of CH1, DAC-V. It worked. It appears that 1.13 fixed the manual cal bug introduced in 1.11. The manual cal process is so colossally boring that I didn't try the other devices or the other channels.
When in calibration mode, they should never correct the output using the cal data tables. They try to achieve this by clearing out the tables when you enter calibration for the first time. That is not good enough. If you restart calibration or go back and repeat a cal step you've already done, the previous cal data is not blank and it will throw off the results.
I fear that it's absolutely hopeless trying to explain that to Rigol.
Noticing odd artifacts in the linearity of the DP832 DAC (see https://www.eevblog.com/forum/testgear/noob-dac-linearity-in-the-dp832/msg586741/#msg586741 (https://www.eevblog.com/forum/testgear/noob-dac-linearity-in-the-dp832/msg586741/#msg586741)), I decided to write a script to calibrate the DP832 using TooOldForThis and ted572's instructions from this thread.
The script is written in Matlab. Be gentle, this is my first Matlab script :-[
I decided to use Matlab because a) I had never tried Matlab, b) I wanted easy graphing (not relevant to this script) and c) I wanted to get going quickly with SCPI and Agilent had several nice examples for the 34461A in Matlab.
Porting to C or Python should be reasonably straightforward. This is straight SCPI and there is no weird Matlab-ism except for one-dimensional arrays being multi-dimensional and starting at 1 |O
The script is meant to be used with a DP832 and a 34461A. Other DMMs should be easy to add, but the current measurements require a step at 3.2A which can be challenging for many (like a plain 34401A). The 34461A has a 10A input, which turns out to be handy for this purpose.
Please read the notes carefully before using.
Regarding Agilent 34461A and MATLAB scripts, you may be interested in a simple data logging script I posted here (https://www.eevblog.com/forum/testgear/new-agilent-34461a-6-5-digit-bench-multimeter/msg497829/#msg497829); it is based on some Agilent examples.
The script is written in Matlab. Be gentle, this is my first Matlab script :-[
I decided to use Matlab because a) I had never tried Matlab, b) I wanted easy graphing (not relevant to this script) and c) I wanted to get going quickly with SCPI and Agilent had several nice examples for the 34461A in Matlab.
datestr(datetime('today'),'mm/dd/yyyy')todatestr(now,'mm/dd/yyyy')LaurentR: I tried your calibration script this afternoon (with DP832 and DMM was a 34461A) and it worked great! I did have to make a couple of changes for my setup, but there were no problems with your script that I found.
The changes I made are:
1. To use Agilent VISA drivers instead of NI, so I changed 'ni' to 'agilent' where you define the VISA driver name.
2. I am using MATLAB R2012a, which does not have 'datetime' function so I had to changeCode: [Select]datestr(datetime('today'),'mm/dd/yyyy')toCode: [Select]datestr(now,'mm/dd/yyyy')
Thank you very much, it makes calibration of DP832 a relatively quick and painless task. My DP832 is now in better agreement with measured values and definitely worth my time to do the calibration.
Thanks!
I'll modify that and I'll streamline some of the code based on what you did in your datalogging code.
No problem, and sounds good! I hope you will post the update :)
as a beginner, and who else can write a script for Rigol dm3058 (3068) ??
I installed the 01.13 firmware release onto my DP832 and updated the first post. Here are some notes:
- All installed options (accuracy, etc.) remain enabled.
- Temperature measurement/display bug is fixed. In addition, the temperature is displayed on the detailed system info screen (Utility > SysInfo > M1 > M3 > M2), rather than the "Test/Cal" screen.
- Analog board version updated to: 01.02.03.01.02.03
- Keyboard version still at 01.01
- Bootloader version still at 01.09. If you already have bootloader 01.09 from a prior firmware release (e.g. 01.11) then no need to update the bootloader again.
I wonder if someone can check if the calibration bug has been resolved??
Firmware: Download here (http://wikisend.com/download/412166/00.01.13.zip)
I installed the 01.13 firmware release onto my DP832 and updated the first post. Here are some notes:
- All installed options (accuracy, etc.) remain enabled.
- Temperature measurement/display bug is fixed. In addition, the temperature is displayed on the detailed system info screen (Utility > SysInfo > M1 > M3 > M2), rather than the "Test/Cal" screen.
- Analog board version updated to: 01.02.03.01.02.03
- Keyboard version still at 01.01
- Bootloader version still at 01.09. If you already have bootloader 01.09 from a prior firmware release (e.g. 01.11) then no need to update the bootloader again.
I wonder if someone can check if the calibration bug has been resolved??
Firmware: Download here (http://wikisend.com/download/412166/00.01.13.zip)
I just applied the 01.13 update (was on 01.11) to the DP832 I received about a month ago. Was already on 01.09 bootloader, but applied the .13 main update and analog board 1 and board 2.
I now read:
Digital Version: 00.01.13.00.01
Analog Version: 02.02.03.02.02.03
Boot Version: 01.09
Keyboard Version: 01.01
The analog version shows .03 segments in it, which seems higher than I've seen anyone else list? Before I applied the update, the analog version was all .02s.
as a beginner, and who else can write a script for Rigol dm3058 (3068) ??
as a beginner, and who else can write a script for Rigol dm3058 (3068) ??
You can actually put the DM30x8 Rigols into Agilent mode and they recognize a good number of the agilent commands
the Programming guide tells you what it does not recognize and from a quick look this script should run on the DM30x8 when put into Agilent mode. you can find it in the Utilities menu
LaurentR: I tried your calibration script this afternoon (with DP832 and DMM was a 34461A) and it worked great! I did have to make a couple of changes for my setup, but there were no problems with your script that I found.
The changes I made are:
1. To use Agilent VISA drivers instead of NI, so I changed 'ni' to 'agilent' where you define the VISA driver name.
2. I am using MATLAB R2012a, which does not have 'datetime' function so I had to changeCode: [Select]datestr(datetime('today'),'mm/dd/yyyy')toCode: [Select]datestr(now,'mm/dd/yyyy')
Thank you very much, it makes calibration of DP832 a relatively quick and painless task. My DP832 is now in better agreement with measured values and definitely worth my time to do the calibration.
You can actually put the DM30x8 Rigols into Agilent mode and they recognize a good number of the agilent commands
the Programming guide tells you what it does not recognize and from a quick look this script should run on the DM30x8 when put into Agilent mode. you can find it in the Utilities menu
LaurentR: I tried your calibration script this afternoon (with DP832 and DMM was a 34461A) and it worked great! I did have to make a couple of changes for my setup, but there were no problems with your script that I found.
The changes I made are:
1. To use Agilent VISA drivers instead of NI, so I changed 'ni' to 'agilent' where you define the VISA driver name.
2. I am using MATLAB R2012a, which does not have 'datetime' function so I had to changeCode: [Select]datestr(datetime('today'),'mm/dd/yyyy')toCode: [Select]datestr(now,'mm/dd/yyyy')
Thank you very much, it makes calibration of DP832 a relatively quick and painless task. My DP832 is now in better agreement with measured values and definitely worth my time to do the calibration.You can actually put the DM30x8 Rigols into Agilent mode and they recognize a good number of the agilent commands
the Programming guide tells you what it does not recognize and from a quick look this script should run on the DM30x8 when put into Agilent mode. you can find it in the Utilities menu
Some cleanup, Sparky's mods added and tentative DM3068 support (untested). See original post:
Totally brilliant solution by the looks of it, I have spent lots of hours trying
to calibrate this thing!
All I need now is a dummies guide on how to get matlab going with my
34401a + 34430a shunt.
I know it's a dumb question, and the info is out there somewhere, but I am
really old now!
Thanks for the valued input LaurentR also TooOldForThis and ted572
and Sparky of course!!
I was going to try RS232.
Maybe it'll all end in tears!
I installed the 01.13 firmware release onto my DP832 and updated the first post. Here are some notes:
- All installed options (accuracy, etc.) remain enabled.
- Temperature measurement/display bug is fixed. In addition, the temperature is displayed on the detailed system info screen (Utility > SysInfo > M1 > M3 > M2), rather than the "Test/Cal" screen.
- Analog board version updated to: 01.02.03.01.02.03
- Keyboard version still at 01.01
- Bootloader version still at 01.09. If you already have bootloader 01.09 from a prior firmware release (e.g. 01.11) then no need to update the bootloader again.
I wonder if someone can check if the calibration bug has been resolved??
Firmware: Download here (http://wikisend.com/download/412166/00.01.13.zip)
I installed the 01.13 firmware release onto my DP832 and updated the first post. Here are some notes:
- All installed options (accuracy, etc.) remain enabled.
- Temperature measurement/display bug is fixed. In addition, the temperature is displayed on the detailed system info screen (Utility > SysInfo > M1 > M3 > M2), rather than the "Test/Cal" screen.
- Analog board version updated to: 01.02.03.01.02.03
- Keyboard version still at 01.01
- Bootloader version still at 01.09. If you already have bootloader 01.09 from a prior firmware release (e.g. 01.11) then no need to update the bootloader again.
I wonder if someone can check if the calibration bug has been resolved??
Firmware: Download here (http://wikisend.com/download/412166/00.01.13.zip)
I tried to download the 00.01.13 firmware update from Sparky's link, but it got blocked as malicious. Is anyone else hosting this?
Can you check it Sparky?
I also went to request it direct from Rigol, but found the form was already filled in with some ones information. I would prefer to not have the same thing happen to me.
Any help is appreciated.
Thanks.
Hi,
just came across this thread (because it popped back up to the top). I haven't read the entire thread, because I assume all issues are listed in the first post, but you don't mention the rather annoying hardware bug that the positive connection posts are too small for standard 4mm banana connectors.
McBryce.
Hi,
just came across this thread (because it popped back up to the top). I haven't read the entire thread, because I assume all issues are listed in the first post, but you don't mention the rather annoying hardware bug that the positive connection posts are too small for standard 4mm banana connectors.
McBryce.
DP832 - Firmware versions and bugs/issues
Hi,
just came across this thread (because it popped back up to the top). I haven't read the entire thread, because I assume all issues are listed in the first post, but you don't mention the rather annoying hardware bug that the positive connection posts are too small for standard 4mm banana connectors.
McBryce.
I don't have the issue myself, but I assume you're talking about this:
https://www.eevblog.com/forum/testgear/banana-plugs-don't-fit-in-positive-sockets-rigol-dp832/ (https://www.eevblog.com/forum/testgear/banana-plugs-don't-fit-in-positive-sockets-rigol-dp832/)
Let me quote Sparky below, so that he adds this to the listDP832 - Firmware versions and bugs/issues
After the first OC trip, turn the channel back on, then try to trip it again. Instead of tripping, it current limits (it doesn't trip) using the OCP setting for current limiting, not the current limit setting.
Is this behaviour just me????
Hi,
just came across this thread (because it popped back up to the top). I haven't read the entire thread, because I assume all issues are listed in the first post, but you don't mention the rather annoying hardware bug that the positive connection posts are too small for standard 4mm banana connectors.
McBryce.
I don't have the issue myself, but I assume you're talking about this:
https://www.eevblog.com/forum/testgear/banana-plugs-don't-fit-in-positive-sockets-rigol-dp832/ (https://www.eevblog.com/forum/testgear/banana-plugs-don't-fit-in-positive-sockets-rigol-dp832/)
Let me quote Sparky below, so that he adds this to the listDP832 - Firmware versions and bugs/issues
After the first OC trip, turn the channel back on, then try to trip it again. Instead of tripping, it current limits (it doesn't trip) using the OCP setting for current limiting, not the current limit setting.
Is this behaviour just me????
01.09 here and no OCP issue as you described
Hi,
If anyone can confirm that, this is a serious bug ! It can realy destroy circuits under test ! So we have to find a quickly solution.
For your list of bugs and design flaws in the DP832: Youtuber Jason Li investigated that Rigol's DP832 seems not to be isolated to earth. There's an AC coupling between earth and ground (exceed 32 Vac). Here's the video:
https://www.youtube.com/watch?v=Er8fZJbYfZ4 (https://www.youtube.com/watch?v=Er8fZJbYfZ4)
For your list of bugs and design flaws in the DP832: Youtuber Jason Li investigated that Rigol's DP832 seems not to be isolated to earth. There's an AC coupling between earth and ground (exceed 32 Vac). Here's the video:
https://www.youtube.com/watch?v=Er8fZJbYfZ4 (https://www.youtube.com/watch?v=Er8fZJbYfZ4)
With the DP832 on but all channels off:
I see ~7.5VAC@60Hz between channel1+ and mains earth. The other channels show 7.5-8.5VAC. The current is .022uA according to my 34465a, >20Hz filter mode.
So voltage, but almost nil current. Much ado about nothing?
As my point of view, just a voltage(without any current) will be enough to blow up the ICs, as stated in the specification.
Hi , In some bench power supplies you will find any floating output's (at both +,- sides) are ac coupled to mains earth at the output's by capacitors ~ 47n-100n, the job of these is to provide a low impedance path for any earth referred mains noise back to earth (so they form a Voltage divider with the source impedance and thus attenuate this noise) . From what was said by Howard in earlier post sounds like these are missing/not fitted here. If your not satisfied and you want to reduced this then you could fit some yourself ( 47nF caps would reduce it to ~1V). Maybe ask Rigol first why they did not fit them.
20VAC 26uA on CH1 and 22VAC 28uA on CH2+3 here. UK mains so I know all my earths are good :-+For the video I made in YouTube, I am in Hong Kong and also using British standard plug. The main ground is so damn good and I have always no doubt with that 8)
With the DP832 on but all channels off:
I see ~7.5VAC@60Hz between channel1+ and mains earth. The other channels show 7.5-8.5VAC. The current is .022uA according to my 34465a, >20Hz filter mode.
So voltage, but almost nil current. Much ado about nothing?
So these days I have to review why all my design prototypes fail.
This confirm my idea. This "issue" is not an issue. And I bet that similar readings can be found on other brands too. I will check on my Aim-TTi.Can you explain more about you idea? Better with examples showing other supplies did this reading too.
Probably you should check your designs, lunxg. They are not failing because of the DP832. This model has its bugs, but it's not a circuit killer.
Can you explain more about you idea?As I stated in a previous post, I'm confident that those small currents are not an issue for a circuit, and this is confirmed also by the last two posts.
Better with examples showing other supplies did this reading too.
And I guess that even if we were dealing with higher current values, we should consider that probably your circuits are not connected to mains ground, so no AC current can flow thru your components. Am I wrong?
As I stated in a previous post, I'm confident that those small currents are not an issue for a circuit, and this is confirmed also by the last two posts.
And I guess that even if we were dealing with higher current values, we should consider that probably your circuits are not connected to mains ground, so no AC current can flow thru your components. Am I wrong?
I've checked our 4 DP832As and 2 DP832s: all show similar measurements as posted here by others already.
We use these Rigol PSUs on a daily basis for more than one year, now (replacing Agilent E3649A PSUs) to power our own custom designs, as well as off-the-shelf eval-boards; sometimes powering the devices "only" through their on-board regulators, sometimes powering chips directly from the Rigols, e.g. in cases where on-board regulators of the designs are not yet working properly or are not present at all in the first place. This also includes powering 32-bit SoCs or PMICs directly from the Rigol, sometimes.
So far not a single device (of the probably hundreds or thousands we have used) has ever suffered any damage from the Rigol PSUs; no matter if the devices are only connected to the PSU alone or also to Ethernet-Switches, USB-, RS232-, CAN- or other ports of different PCs at the same time or whether somebody uses oscilloscopes or logic analyzers from various different brands on "life" devices.
hmm... you're damn right. Just connecting any DSO ground clip you're making voltage flow thru the components.Well, no, voltage doesn't flow thru anything but never mind....
Also note there is a 12 hour (run-time) lock out period if an invalid code is entered too many times. Also, no dashes. Your code doesn't look long enough either, mine on the DP832 were 28 characters long.
My Chinese is terrible but I think they are saying that they send a command over the LXI interface... Maybe the MON command? They are definitely saying you should be able to replicate it on other units.
I prefer the monochrome look actually. The colours are a bit too "Hallo Kitty" for my liking.Depends on color combination. Sometimes colors is just more readable the mono
McBryce.
The code is somewhat short on comments... Anyway, it's a first stab at creating a generic Python library for VISA instrument support.
I ported over LaurentR's script to Python and thought I'd share it here.Thanks for this. I have a Rigol DM3058E but never got around to using LaurentR's code because I don't have Matlab. I don't believe any Rigol owner has tested it yet?
I ported over LaurentR's script to Python and thought I'd share it here.
I refactored it a bit, so there's an LxiInstr base class, a KeysightTrueVolDmm class for measurements, and a Dp832PowerSupply to talk to the PSU. I wanted to move the DMM support into a separate file to make it easier to use it for other purposes, such as data logging, or to implement the same interface for other DMM's. (I kept LaurentR's DM3068 switch to Agilent mode, but not sure if it works. It would be better to add a native implementation for it.) calib.py is a generic wrapper pretty much, and all of the calibration guts are in Dp832PowerSupply. They're DP832 specific anyway, and not easily reusable.
I tested this on OS X 10.10, NI-VISA, PyVISA, LAN devices, 34465A DMM. Python2.7 is required.
But it should work fine with GPIB, USB also. (<= famous last words!)
The code is somewhat short on comments... Anyway, it's a first stab at creating a generic Python library for VISA instrument support.
Anyway, I'm using Windows 7 and have never used Python before, but what the hell - lets see what this snakey thing is. It wasn't as simple as just download python and run, there are a few dependencies as well:The Windows install is not straightforward for us GUI people, but it works :)
...
17 known_list = ["34461A", "34465A", "34470A", "DM3068"]
known_list = ["34461A", "34465A", "34470A", "DM3068", "DM3058", "DM3058E"]
18 init_cmds = { 'DM3068' : 'CMDSet AGILENT' }
init_cmds = { 'DM3068' : 'CMDSet AGILENT', 'DM3058' : 'CMDSet AGILENT', 'DM3058E' : 'CMDSet AGILENT' } # (Yuck!)44 if r != '+0':
if r not in ['+0', '0']:57 insert if self.model() in self.have_temp_check:
61 insert return [None, None, None, None]
... ahh, now thats better, getting somewhere... things seem to be working :)
or maybe not...
The only issue I had with your code was that early on, you check for the presence of ":" in the device Visa addresses, but Visa supports aliases , which typically don't have ":" in the name. For instance, my 2 devices are aliased (rather imaginatively) "DP832" and "34461A".
Oh cool, had no idea such a thing existed!
Edit: it doesn't seem to know how to calibrate or do much of anything else device specific...
I've just found this by case. Small unboxing of DP832 on chines website. Nothing special except... full color display on non-A model. It looks like some early firmware.
Color display is not a big deal but I'm curious if you know something about this ?
(http://hostthenpost.org/uploads/5218d67cdfe26446029fdec828ddf394.jpg)
Source:
http://www.hkepc.com/forum/viewthread.php?tid=1953803 (http://www.hkepc.com/forum/viewthread.php?tid=1953803)
Here is a list of Rigol DP832 firmware versions and summary of known firmware bugs and hardware issues...
If anyone discovers additional bugs, or has corrections to the summary above, please post in the thread and I'll try to keep this post updated.
| (http://i.imgur.com/9oLqinw.png) | (http://i.imgur.com/qhc9HZD.png) |
| (http://i.imgur.com/89QrHFZ.png) | CH3 in CC mode set to 100mA. My Fluke 87V confirms output is bang on at 100.1mA. Readback is 2mA low but well within tolerance. |
| (http://i.imgur.com/ZCDR7li.png) | I increase CH3 set current until it exceeds set/enabled OCP limit of 110mA. However, CH3 remains ON. I continue increasing set current to 1A. My Fluke 87V confirms output stops increasing after I pass 110mA on set current and remains at a max of 110.1mA. Readback is again 2mA low but confirms actual output is at the set OCP limit. |
| (http://i.imgur.com/VpstGYr.png) | I turn CH3 OCP OFF. V/A/W readback remains unchanged and again, my Fluke 87V confirms an actual output of 110.1mA. |
| (http://i.imgur.com/AB3zAB1.png) | I increase CH3 set current by 1mA to 1.001A. My Fluke 87V immediately registers an output current increase to 1.0011A. V/A/W readback immediately updates to correctly reflect the new output level. |
| (http://i.imgur.com/RcQYHsP.png) | I turn CH3 OCP ON. CH3 immediately registers an OCP event, displays a popup warning window and turns CH3 OFF. |
| (http://i.imgur.com/n8NuEXr.png) | I turn CH3 ON. CH3 remains ON regardless of the set current level which exceeds OCP limit. My Fluke 87V confirms an output of 110.1mA. Readback is again 2mA low but confirms actual output is at the set OCP limit. |
Here is a list of Rigol DP832 firmware versions and summary of known firmware bugs and hardware issues...
If anyone discovers additional bugs, or has corrections to the summary above, please post in the thread and I'll try to keep this post updated.
| (http://i.imgur.com/9oLqinw.png) | (http://i.imgur.com/qhc9HZD.png) |
So I went to the bother of ordering a 3.8mm drill bit as suggested by Rigol (as far as I know) to repair the positive posts that don't take a standard 4mm banana plug. The bit slides effortlessly into the Earth and GND posts with some play, but it also slides (if somewhat slightly tighter) into the positive posts. So is 3.8mm the wrong size? How big should these holes really be? The positive post holes are definitely 3.8mm, but a banana plug doesn't fit into them. Should they be actually 3.9mm?0.166 inch or 4.22mm
McBryce.
I've discovered ...
-Kris
I've discovered ...
-Kris
Did you report these to Rigol?
I've discovered ...
-Kris
Did you report these to Rigol?
I plan to in the near future. I was going to give it a few days to see what type of response/insight/confirmation I might receive from my postings.
-Kris
Hi Kris,
Thanks for your contribution regarding bug(s) with DP800 series! That's just the kind of news relevant to this thread! The detail and screenshots to illustrate and reproduce the problem area great.
I'm on travel as of tomorrow so busy right now, but let's see how this plays out (has anyone reproduced the errors?) and I will add it to the bugs list (post #1) when I am back (end of the month).
Best,
Sparky
So I went to the bother of ordering a 3.8mm drill bit as suggested by Rigol (as far as I know) to repair the positive posts that don't take a standard 4mm banana plug. The bit slides effortlessly into the Earth and GND posts with some play, but it also slides (if somewhat slightly tighter) into the positive posts. So is 3.8mm the wrong size? How big should these holes really be? The positive post holes are definitely 3.8mm, but a banana plug doesn't fit into them. Should they be actually 3.9mm?0.166 inch or 4.22mm
McBryce.
according to these manufacturers:
https://cinchconnectivity.com/OA_MEDIA/drawings/dr-1080902001.pdf (https://cinchconnectivity.com/OA_MEDIA/drawings/dr-1080902001.pdf)
http://muellerelectric.com/wp-content/uploads/BU-P2854-2.pdf (http://muellerelectric.com/wp-content/uploads/BU-P2854-2.pdf)
I can't get the firmware update to work (DP832). I got the files from rigol (1.13). I have boot version 1.09 and firmware version 1.11 . I tried two different flash drives. One is USB 2.0, 2gb, and I formatted it as fat32 using disk part and rufus. The other is a 16gb USB 3. Both are recognized by the unit in normal mode. When I boot it up and press help, it says please insert usb stick with the file on it. I do it but it just stays there.
Any help?
I can't get the firmware update to work (DP832). I got the files from rigol (1.13). I have boot version 1.09 and firmware version 1.11 . I tried two different flash drives. One is USB 2.0, 2gb, and I formatted it as fat32 using disk part and rufus. The other is a 16gb USB 3. Both are recognized by the unit in normal mode. When I boot it up and press help, it says please insert usb stick with the file on it. I do it but it just stays there.
Any help?
I can't get the firmware update to work (DP832). I got the files from rigol (1.13). I have boot version 1.09 and firmware version 1.11 . I tried two different flash drives. One is USB 2.0, 2gb, and I formatted it as fat32 using disk part and rufus. The other is a 16gb USB 3. Both are recognized by the unit in normal mode. When I boot it up and press help, it says please insert usb stick with the file on it. I do it but it just stays there.
Any help?
You're good to go on the bootloader (no need to update) so just place "DP800Update.GEL" from "DP800(Software)Update(Normal)_00.01.13.00.01\" on to your FAT32 formatted USB flash drive root directory.
Complete instructions are attached to post #1 of this thread (DP832 Firmware Upgrade 00.01.13.pdf (https://www.eevblog.com/forum/testgear/rigol-dp832-firmware-updates-and-bug-list/?action=dlattach;attach=128673)).
-Kris
I can't get the firmware update to work (DP832). I got the files from rigol (1.13). I have boot version 1.09 and firmware version 1.11 . I tried two different flash drives. One is USB 2.0, 2gb, and I formatted it as fat32 using disk part and rufus. The other is a 16gb USB 3. Both are recognized by the unit in normal mode. When I boot it up and press help, it says please insert usb stick with the file on it. I do it but it just stays there.
Any help?
BTW: Don't forget to update analog boards 1 & 2. People sometimes forget this step since it's separate from the main firmware update.
-Kris
Yup that worked, thanks :-+. My Analog Version is 02.02.03.02.02.03 instead of 01.02.03.01.02.03 like on the guide. To anyone wondering, a 16GB USB 3.0 flash drive works for updating the firmware.Excellent! More than happy to help. Analog Version: 02.02.03.02.02.03 should indicate your unit is equipped with the new TopBoard_V02.20 (as pictured here (https://www.eevblog.com/forum/testgear/rigol-dp832-firmware-updates-and-bug-list/msg518139/#msg518139)) and new BottomBoard_V02.20 (my unit also has both new revisions).
Just to add to the discussion, my Pomona banana to alligator cables fit nicely. It was a tight fit at first but they loosened up after a few uses.Glad to see your binding posts are trouble free. My red binding posts are a tight fit with banana plug connections but not too tight. The black and green are a looser fit but still form a trustworthy connection.
There doesn't seem to be much information floating around this thread regarding changes in the recent DP800-firmwares. As Rigol unfortunately quite often doesn't seem to provide release notes with firmware updates, maybe some excerpts from the most recent v1.11 release notes will help others to decide, whether to upgrade or not:
Version:00.01.11.00.00 Date:2014-7-8
- Add the traditional language menu.
- Expand the point of recorder to 614400.
- The display mode will not be changed by setting preset.
Version:00.01.10.00.03 Date:2014-5-09
- Fixed the bug of the display of high resolution option.
- Add internal ovp/ocp function.
Cut short for ease of viewing
What has changed with the 00.01.13.00 update? Any news on this? Worth the update from 00.01.11??
It's quite annoying that the big displays is higher, makes it a bit useless.If they were to display the exact same value all the time it would either have to actually BE the same value (ie either the set value OR the actual value) and THEN it would be useless and a waste of screen real estate or the internal circuitry would have to be extremely accurate so that the actual output voltage always matched the set output voltage down to the least significant digit. A 4mV difference between the set value and the readback value is well within its specifications (which is 0.05%+20mV on the set voltage and 0.05%+10mV on the readback).
You understood correctly, and all your points are true in regards to the hardware. I just thought it was some weird software bug that offset the reading by +4mV since it was present on almost every setting, even with the output set at 0. But further testing today confirms other values, like +2,3,4,5,6mV at different settings, so everything is functioning correctly.
Anyone else have the bigger display read higher than the smaller display? Mine reads 4mV higher than what is set for many voltages. Even set at 0v, the big displays shows .004. Some voltages like 11v show the same reading. My multimeter shows I'm getting what I set it to. It's quite annoying that the big displays is higher, makes it a bit useless. I'm on the latest version and have the higher resolution enabled.
Everything is ok. Check the specification of DP832.
Power supply is not a high accuracy voltmeter :)
So the readout is not always more accurate than the set voltageThey don't claim it to be. Actually the set voltage has a tighter specification than the readback voltage. <---EDIT: No it doesn't.
QuoteSo the readout is not always more accurate than the set voltageThey don't claim it to be. Actually the set voltage has a tighter specification than the readback voltage.
The specs on the rigol product page and data sheet give different values. I would trust those values over the manual.
I adore my DP832 but since I used the OCP option, even when it's set to off, switching on the channel sometimes causes the OCP message to appear with the power being turned off. Anyone else seen this ? I've not upgraded he firmware since I bought it in November.
Don't you have to re-calibrate after updating the firmware ? If it needs some extra kit, that's not something that I could do. Also, as mentioned above, it looks like Rigol don't say what the updates fix and so there's no guarantee that I'd be better off.No recalibration required. I've performed several firmware updates on two different Rigol DP832 units and they have never affected calibration. It's true we don't know exactly what was added/changed/addressed in the most recent firmware update. However, the issue you describe sounds like a firmware issue so I would update the firmware as a troubleshooting step. Just carefully follow the instructions HERE (pdf) (https://www.eevblog.com/forum/testgear/rigol-dp832-firmware-updates-and-bug-list/?action=dlattach;attach=128673). Naturally, there are risks anytime you update firmware so you have to make that decision.
Don't you have to re-calibrate after updating the firmware ? If it needs some extra kit, that's not something that I could do. Also, as mentioned above, it looks like Rigol don't say what the updates fix and so there's no guarantee that I'd be better off.
Don't you have to re-calibrate after updating the firmware ? If it needs some extra kit, that's not something that I could do. Also, as mentioned above, it looks like Rigol don't say what the updates fix and so there's no guarantee that I'd be better off.I asked this as well as the response I got from RIGOL was:
"We have high confidence in our updates, but there are always risks. We leave it to users to weigh what the update helps them do vs the potential risks. I see no reason it should need calibrated after the fact.
Regards, Chris Armstrong
I've just got the new firmware 01.14 by automatic email. It includes the existing bootloader 1.09.
Interestingly it also includes an 18 page document mostly in chinese detailing all the firmware releases and their changes to date :-+ :clap:
The changes from 01.13 are:
1. Change the USB Device library. (Mod)
2. Change the LXI and SCPI library. (Mod)
3. Add the Series-parallel help info in the main help. (Enchancement)
So, clear as mud then. I'm yet to install it...
I think they finally implemented the excellent suggestion made by Shahriar (the signal path) were he correctly suggested to have the readout voltage should always be enabled, even when the channels are turned off. This way, if you connect your power leads to some "unexpected" voltage, you already see this before you enable then channel of your DP832 and prevent a possibly destroy of the DP832...
I ported over LaurentR's script to Python and thought I'd share it here.
I refactored it a bit, so there's an LxiInstr base class, a KeysightTrueVolDmm class for measurements, and a Dp832PowerSupply to talk to the PSU. I wanted to move the DMM support into a separate file to make it easier to use it for other purposes, such as data logging, or to implement the same interface for other DMM's. (I kept LaurentR's DM3068 switch to Agilent mode, but not sure if it works. It would be better to add a native implementation for it.) calib.py is a generic wrapper pretty much, and all of the calibration guts are in Dp832PowerSupply. They're DP832 specific anyway, and not easily reusable.
I tested this on OS X 10.10, NI-VISA, PyVISA, LAN devices, 34465A DMM. Python2.7 is required.
But it should work fine with GPIB, USB also. (<= famous last words!)
The code is somewhat short on comments... Anyway, it's a first stab at creating a generic Python library for VISA instrument support.
MAC:dp832 user$ python calib.py TCPIP0::10.0.0.4::INSTR TCPIP0::10.0.0.5::INSTR
Error initializing: string index out of range
MAC:dp832 user$ python calib.py -t USB0::0x1AB1::0x0E11::DP8C164758888::INSTR USB0::6833::3220::DM3O163358888::0::INSTR
* DM3068 >>> 'SYST:ERR?'
* DM3068 <<< '0,"No error"'
* DM3068 >>> 'SYST:ERR?'
* DM3068 <<< '0,"No error"'
* DP832 >>> 'SYST:ERR?'
* DP832 <<< '0,"No error"'
* DP832 >>> 'SYST:ERR?'
* DP832 <<< '0,"No error"'
Using:
DMM : Rigol Technologies DM3068 (FW 01.01.00.01.08.00) @ USB0::6833::3220::DM3O163358888::0::INSTR
DP832 : RIGOL TECHNOLOGIES DP832 (FW 00.01.14) @ USB0::0x1AB1::0x0E11::DP8C164758888::INSTR
Calibration data will NOT be updated -- this is only a check
* DP832 >>> 'SYST:ERR?'
* DP832 <<< '0,"No error"'
* DP832 >>> '*RST'
* DP832 >>> 'SYST:ERR?'
* DP832 <<< '0,"No error"'
* DM3068 >>> 'SYST:ERR?'
* DM3068 <<< '0,"No error"'
* DM3068 >>> '*RST'
* DM3068 >>> 'SYST:ERR?'
* DM3068 <<< '0,"No error"'
* DM3068 >>> 'CMDSet AGILENT'
* DM3068 >>> 'SYST:ERR?'
* DM3068 <<< '0,"No error"'
Remove all leads to perform self test
Press enter to continue
Running DP832 board self-test...
* DP832 >>> 'SYSTem:SELF:TEST:BOARD?'
* DP832 <<< 'PASS,PASS'
DP832 self-test passed
* DP832 >>> 'SYSTem:SELF:TEST:TEMP?'
* DP832 <<< '[37.89]'
DP832 internal temp: 37.89C (100.202F)
Running DM3068 board self-test...
* DM3068 >>> '*TST?'
* DM3068 <<< ''
Shutting off PSU outputs
* DP832 >>> 'OUTPUT CH1,OFF'
* DP832 >>> 'OUTPUT CH2,OFF'
* DP832 >>> 'OUTPUT CH3,OFF'
ERROR: Self-test failed for DM3068
Calibration failed. Terminating.
It looks like the DM3068 does not like the *TST command. I've tried running manually via Ultra Sigma and it also errors out. Reviewing the DM3000 programming guide does not show that there are any official test commands that are supported for any command-set. Is this true?
Update: They tried the same command with a DM3068 running the same firmware version and it provided the expected +0 response. We are now trying to figure out if this is a bad unit or if it's a firmware bug.Omikron, I've been there, seen it, done it. The Rigol is returning the correct response of '0' to *TST?. The calib.py script expects a '+0' which I can only assume the Agilent returns. Or else it is a typo in the code. Anyway, it's an easy one to fix, but there are plenty more to come :palm:
What is particularly troubling is the fact that the self-test passes when started from the Utility menu, but fails via *TST?.
Update: They tried the same command with a DM3068 running the same firmware version and it provided the expected +0 response. We are now trying to figure out if this is a bad unit or if it's a firmware bug.Omikron, I've been there, seen it, done it. The Rigol is returning the correct response of '0' to *TST?. The calib.py script expects a '+0' which I can only assume the Agilent returns. Or else it is a typo in the code. Anyway, it's an easy one to fix, but there are plenty more to come :palm:
What is particularly troubling is the fact that the self-test passes when started from the Utility menu, but fails via *TST?.
I kind of gave up on calib.py when I did find a proper firmware bug on the DM3058 in Agilent mode which renders the Agilent mode utterly useless |O I reported this one to Rigol and left the ball in their court (though I did hack a workaround, it is not something to be proud of). However, the DM3068 does not have this bug as far as I am aware.
So, you can call your attack dogs off Rigol re: *TST? but I would appreciate it if you give them a kick up the arse for me. See here. (https://www.eevblog.com/forum/testgear/rigol-dm3058-agilent-scpi-mode-bug-(possibly-affects-dm3068-too)/msg652122/#msg652122)
I did have calib.py sort of working, at least on its dry runs, but am still waiting for Rigol to sort out the DM3058 bug. Actually I've been meaning to write my own calibrator in C#.NET instead and use the Rigol command set rather than try and emulate an Agilent.
* Connected to: TCPIP::10.10.10.23::INSTR
-> SYST:ERR?
<- (Return Count:53)
-330,"Self-test failed; 604 - OHM Common Drive Test"
-> SYST:ERR?
<- (Return Count:53)
-330,"Self-test failed; 605 - DCV Common Drive Test"
-> SYST:ERR?
<- (Return Count:13)
0,"No error"
Here is a list of Rigol DP832 firmware versions and summary of known firmware bugs and hardware issues...
If anyone discovers additional bugs, or has corrections to the summary above, please post in the thread and I'll try to keep this post updated.
I've discovered a CH3 OCP firmware related bug. OCP functions as expected on CH1/CH2 and OVP functions as expected on CH1/CH2/CH3.
Particulars for my Rigol DP832 unit:
(http://i.imgur.com/9oLqinw.png) (http://i.imgur.com/qhc9HZD.png)
NOTE: My unit is equipped with TopBoard_V02.20 / BottomBoard_V02.20.
Recreating firmware bug:
(http://i.imgur.com/89QrHFZ.png) CH3 in CC mode set to 100mA. My Fluke 87V confirms output is bang on at 100.1mA. Readback is 2mA low but well within tolerance.
(http://i.imgur.com/ZCDR7li.png) I increase CH3 set current until it exceeds set/enabled OCP limit of 110mA. However, CH3 remains ON. I continue increasing set current to 1A. My Fluke 87V confirms output stops increasing after I pass 110mA on set current and remains at a max of 110.1mA. Readback is again 2mA low but confirms actual output is at the set OCP limit.
(http://i.imgur.com/VpstGYr.png) I turn CH3 OCP OFF. V/A/W readback remains unchanged and again, my Fluke 87V confirms an actual output of 110.1mA.
(http://i.imgur.com/AB3zAB1.png) I increase CH3 set current by 1mA to 1.001A. My Fluke 87V immediately registers an output current increase to 1.0011A. V/A/W readback immediately updates to correctly reflect the new output level.
(http://i.imgur.com/RcQYHsP.png) I turn CH3 OCP ON. CH3 immediately registers an OCP event, displays a popup warning window and turns CH3 OFF.
(http://i.imgur.com/n8NuEXr.png) I turn CH3 ON. CH3 remains ON regardless of the set current level which exceeds OCP limit. My Fluke 87V confirms an output of 110.1mA. Readback is again 2mA low but confirms actual output is at the set OCP limit.
NOTE: The 110mA CH3 OCP limit I chose to demonstrate this bug at doesn't matter. I've recreated this bug with CH3 OCP limit set to 10mA, 510mA, 1.010A, 1.510A, 2.010A and 2.510A.
-Kris
Here is a list of Rigol DP832 firmware versions and summary of known firmware bugs and hardware issues...
If anyone discovers additional bugs, or has corrections to the summary above, please post in the thread and I'll try to keep this post updated.
I've discovered a CH3 OCP firmware related bug...
-Kris
Hi! Just wanted to confirm this bug on my new DP832 received recently from batronix.com with firmware 1.13. Firmware 1.14 seem to fix this at least for me.
Regards, Vlad.
Has anyone tried to hack the DP832's ANALOG board? Any luck with JTAG and full memory dump of the controller?
Hack it to what end? What else would you imagine could be achieved?Well you can up the bandwidth of a 60MHz Oscilloscope to 200MHz easily with a software hack. That means a 195W PSU could be turned into a 650W with a firmware tweak or a keygen obviously. I mean these are modern digital PSU's with Arduinos inside. Not some old rubbish like Power Designs or Lambda. You have to change all the valves and transformers in them, innit? :palm:
Hack it to what end? What else would you imagine could be achieved?Well you can up the bandwidth of a 60MHz Oscilloscope to 200MHz easily with a software hack. That means a 195W PSU could be turned into a 650W with a firmware tweak or a keygen obviously. I mean these are modern digital PSU's with Arduinos inside. Not some old rubbish like Power Designs or Lambda. You have to change all the valves and transformers in them, innit? :palm:
Hack it to what end? What else would you imagine could be achieved?Well you can up the bandwidth of a 60MHz Oscilloscope to 200MHz easily with a software hack. That means a 195W PSU could be turned into a 650W with a firmware tweak or a keygen obviously. I mean these are modern digital PSU's with Arduinos inside. Not some old rubbish like Power Designs or Lambda. You have to change all the valves and transformers in them, innit? :palm:
This was precisely my point, but I was trying to tease out what shrek had in mind in the first place.
15-Feb-2015: Updated to v1.1 with some cleanup and tentative DM3068 support.
isDM3068 = ~isempty(strfind(psuIdn, 'DM3068'));No doubt it should be 'dmmIdn' instead.15-Feb-2015: Updated to v1.1 with some cleanup and tentative DM3068 support.
LaurentR: I looked quickly at your updated DP832 calibration script and noticed a little problem with it. On line 135 you reference the variable 'psuIdn' when detecting attached DMM type:Code: [Select]isDM3068 = ~isempty(strfind(psuIdn, 'DM3068'));No doubt it should be 'dmmIdn' instead.
Sparky
Warning: USB Device broken in 01.14
After updating to 01.14 I wanted to re-calibrate the unit using LaurentR's MATLAB script (old version :) ) and discovered that my Windows PC would not recognize the DP832 as a USB Device! As a result Keysight "Connection Expert" (Part of Keysight IO Libraries 17.1) could not find the DP832, and I could not perform any calibration!
I was able to downgrade to 01.13 (thankfully USB Host function is not wrecked!) and USB Device capability came back -- DP832 appeared in Connection Expert and all good.
Interestingly the version notes (posted above) mention USB device library (and LXI + SCPI library) updates in 01.14 release. In fact, 01.13 also included USB device, LXI and SCPI changes...
Side note: DP832 did not appear in Connection Expert with either firmwares 01.13 or 01.14, although DP832 does get IP address... Does anyone's DP832(A) using LAN appear in Agilent/Keysight Connection Expert, or the equivalent National Instruments explorer?
Would other people be able to confirm the above findings? If this is a confirmed problem I will add it to the bug list. For the moment, it seems must use 01.13 and USB for calibration.
My DP832, firmware 01.14 is still recognized trough USB and LAN under Keysight Connection Expert.
My DP832, firmware 01.14 is still recognized trough USB and LAN under Keysight Connection Expert.
Thanks, OldNeurons!. Following your positive feedback I re-flashed the 01.14 firmware, and this time no problems for Keysight Connection Expert to detect the DP832 via USB! A mystery whatever happened the first time... I have updated my post above.
I tried LAN connection but Connection Expert still does not see it. Rigol UltraSigma does find it, though, and DP832 responds to SCPI commands that way.
Does anyone control DP832 via LAN connection and have any news about doing so?
Sparky
My DP832, firmware 01.14 is still recognized trough USB and LAN under Keysight Connection Expert.
Thanks, OldNeurons!. Following your positive feedback I re-flashed the 01.14 firmware, and this time no problems for Keysight Connection Expert to detect the DP832 via USB! A mystery whatever happened the first time... I have updated my post above.
I tried LAN connection but Connection Expert still does not see it. Rigol UltraSigma does find it, though, and DP832 responds to SCPI commands that way.
Does anyone control DP832 via LAN connection and have any news about doing so?
Sparky
I have also lost the auto-find on the LAN with I/O Libraries, but adding the IP address manually works fine. Go figure.
My DP832, firmware 01.14 is still recognized trough USB and LAN under Keysight Connection Expert.
Thanks, OldNeurons!. Following your positive feedback I re-flashed the 01.14 firmware, and this time no problems for Keysight Connection Expert to detect the DP832 via USB! A mystery whatever happened the first time... I have updated my post above.
I tried LAN connection but Connection Expert still does not see it. Rigol UltraSigma does find it, though, and DP832 responds to SCPI commands that way.
Does anyone control DP832 via LAN connection and have any news about doing so?
Sparky
I have also lost the auto-find on the LAN with I/O Libraries, but adding the IP address manually works fine. Go figure.
Would someone kindly point me to where I can download 1.14 firmware from please? I have an OCP problem on my unit I'd like to remedy.PM sent with link to firmware 1.14.
Many thanks!
Would someone kindly point me to where I can download 1.14 firmware from please? I have an OCP problem on my unit I'd like to remedy.PM sent with link to firmware 1.14.
Many thanks!
To all owners of DP8xxx. :-+
I would like to ask those who have a DPxxx Rigol it may do a test to compare if it's a problem of my power unit, or if there is a firmware bug general.
The test is the following: :-DMM
by any value set at the output (for example 1 Volt) increase the voltage of 1 mV at a time, measure the output with a DMM :-DMM external if indeed the intention output rises to 1 mV at each step, or as in my case increases 0.6 mV and the next step in a 1.4 mV (total actual doing of the two steps 2 mV). :bullshit:
So every 2 steps it the 2mV correct but to every single-step one is from 0.6 mV and the other from 1.4 mV. This is repeated alternately 0.6 /1.4 ~ 0.6 /1.4 etc.
Thanks
| DP832 set value (channel 1) | Measured on DMM |
| 1.000V | 1.001295V |
| 1.001V | 1.002326V |
| 1.002V | 1.003329V |
| 1.003V | 1.004366V |
| 1.004V | 1.005366V |
| 1.005V | 1.006410V |
| DP832 set value (channel 3) | Measured on DMM |
| 1.000V | 1.000869V |
| 1.001V | 1.001894V |
| 1.002V | 1.002943V |
| 1.003V | 1.003981V |
| 1.004V | 1.005005V |
| 1.005V | 1.006063V |
To all owners of DP8xxx. :-+
I would like to ask those who have a DPxxx Rigol it may do a test to compare if it's a problem of my power unit, or if there is a firmware bug general.
The test is the following: :-DMM
by any value set at the output (for example 1 Volt) increase the voltage of 1 mV at a time, measure the output with a DMM :-DMM external if indeed the intention output rises to 1 mV at each step, or as in my case increases 0.6 mV and the next step in a 1.4 mV (total actual doing of the two steps 2 mV). :bullshit:
So every 2 steps it the 2mV correct but to every single-step one is from 0.6 mV and the other from 1.4 mV. This is repeated alternately 0.6 /1.4 ~ 0.6 /1.4 etc.
Thanks
Nice to see some actual data!
I agree on absolute accuracy - it's good but not down to 1mV. It probably varies from unit to unit; on mine (also DIY calibrated) CH3 is ridiculously precise and always accurate to 1mV. Today though I needed 14.5V and dialed in CH1, and ended up reading 14.498. (Which is pretty damn good in itself.) Put a DMM (34465A) on it, which also read 14.498. So ticked it up 2mV to 14.502V and got 14.500V out. Nice! :-DMM
I was using one of these below to compare an Agilent 34401A (scored for $350!) to the 34465A. According to the seller, my 10V reference is 0.37ppm low. The 34465A reads it 6.7ppm high; the 34401A 24ppm high. All good enough for government work! Didn't try null measuring -- really should get myself a cheap microammeter, and maybe better leads than my $6 Pomonas, so it's not as super accurate as it could be, but I just wanted a quick ballpark check of the 34401A, relative to the 34465A... Here's the reference - highly recommend it. http://www.ebay.com/itm/10-VDC-2ppm-Precision-Voltage-Reference-Standard-Nulled-to-Fluke-732A-or-732B-/251756273626?pt=LH_DefaultDomain_0&hash=item3a9dd7dfda (http://www.ebay.com/itm/10-VDC-2ppm-Precision-Voltage-Reference-Standard-Nulled-to-Fluke-732A-or-732B-/251756273626?pt=LH_DefaultDomain_0&hash=item3a9dd7dfda)
Thank you for your quick and accurate response.To all owners of DP8xxx. :-+
I would like to ask those who have a DPxxx Rigol it may do a test to compare if it's a problem of my power unit, or if there is a firmware bug general.
The test is the following: :-DMM
by any value set at the output (for example 1 Volt) increase the voltage of 1 mV at a time, measure the output with a DMM :-DMM external if indeed the intention output rises to 1 mV at each step, or as in my case increases 0.6 mV and the next step in a 1.4 mV (total actual doing of the two steps 2 mV). :bullshit:
So every 2 steps it the 2mV correct but to every single-step one is from 0.6 mV and the other from 1.4 mV. This is repeated alternately 0.6 /1.4 ~ 0.6 /1.4 etc.
Thanks
These are my results:
DP832 set value (channel 1) Measured on DMM 1.000V 1.001295V 1.001V 1.002326V 1.002V 1.003329V 1.003V 1.004366V 1.004V 1.005366V 1.005V 1.006410V
DP832 set value (channel 3) Measured on DMM 1.000V 1.000869V 1.001V 1.001894V 1.002V 1.002943V 1.003V 1.003981V 1.004V 1.005005V 1.005V 1.006063V
Thank you for your quick and accurate response.
Ok, your Log on measured voltages in steps of 1 mV, seems to be perfect.
So I hom a problem it seems, because as explained initially each time increment of 1 mV ago the first increase 1.3mV and 0.7mV per second increase.
I calibrated DAC and ADC repeatedly my DP but the error is always the same.
I noticed, however, that when the output is turned off (or if you set the output voltage to 0V.) Offset output terminals is 0.550mV ~. Someone can do this check, please?
Thanks.
Here's the reference - highly recommend it. http://www.ebay.com/itm/10-VDC-2ppm-Precision-Voltage-Reference-Standard-Nulled-to-Fluke-732A-or-732B-/251756273626?pt=LH_DefaultDomain_0&hash=item3a9dd7dfda (http://www.ebay.com/itm/10-VDC-2ppm-Precision-Voltage-Reference-Standard-Nulled-to-Fluke-732A-or-732B-/251756273626?pt=LH_DefaultDomain_0&hash=item3a9dd7dfda)
Was it the wall of text in the ebay advert or the presentation of testimonials that impressed you so much?I'm not really interested in a bunch of children's pissing matches. There's no need to be rude. It's a rinky-dink $100 toy device (I think that's what I paid for it) and it has drifted absolutely none at all the last four months relative to my instruments. Of course, it may all have drifted together, and no matter how unlikely or implausible, the only way to achieve mathematical certainty is by testing against an proper standard. However, under the assumption that all my instruments of a variety of ages aren't all drifting in unison, it's perfectly fine what it does and I wouldn't hesitate to recommend it. If this affronts you hoity-toity ivory-tower sense of superiority, so be it. I couldn't give a damn.
Here's the reference - highly recommend it. http://www.ebay.com/itm/10-VDC-2ppm-Precision-Voltage-Reference-Standard-Nulled-to-Fluke-732A-or-732B-/251756273626?pt=LH_DefaultDomain_0&hash=item3a9dd7dfda (http://www.ebay.com/itm/10-VDC-2ppm-Precision-Voltage-Reference-Standard-Nulled-to-Fluke-732A-or-732B-/251756273626?pt=LH_DefaultDomain_0&hash=item3a9dd7dfda)
Oh wow, the Calibratory D-105 is back! (https://www.eevblog.com/forum/testgear/calibratory-d-105-dc-precision-voltage-reference-standard/) It looks like our Awesome friend has upped his prices too.
Have you opened it to check if the build quality has improved at all?
(https://www.eevblog.com/forum/testgear/calibratory-d-105-dc-precision-voltage-reference-standard/?action=dlattach;attach=134400;image)(https://www.eevblog.com/forum/testgear/calibratory-d-105-dc-precision-voltage-reference-standard/?action=dlattach;attach=134390;image)
That flakey piece of foil is all part of the magic apparently. Oh, don't open it as apparently that ruins the calibration. I think it's something to do with Schrodinger's cat and quantum entanglement. Don't worry, apparently GOD gave the inventor the inspiration to develop this standard, so you can be guaranteed that 2ppm accuracy. No need to open it or question how it works. Faith is all you need.
Was it the wall of text in the ebay advert or the presentation of testimonials that impressed you so much?
For your list of bugs and design flaws in the DP832: Youtuber Jason Li investigated that Rigol's DP832 seems not to be isolated to earth. There's an AC coupling between earth and ground (exceed 32 Vac). Here's the video:Is this problem fixed in the mean time?
https://www.youtube.com/watch?v=Er8fZJbYfZ4 (https://www.youtube.com/watch?v=Er8fZJbYfZ4)
...
I don't see the issue, you'll get this with almost any supply, capacitive coupling between output and mains earth is quite normal.
...
If for some reason this is an issue with your system, mains output reference your supply, that is what the earth terminal is on the front panel for.
Is it a problem? Unless there is a significant current flowing I would say that it is not a problem, it is typical "pick up" that you will find in any environment where mains AC fields are present. Quality power supplies employ a transformer with an electrostatic screen to reduce mains coupling, but it is still possible for capacitive coupling to occur on the internal wiring.For your list of bugs and design flaws in the DP832: Youtuber Jason Li investigated that Rigol's DP832 seems not to be isolated to earth. There's an AC coupling between earth and ground (exceed 32 Vac). Here's the video:Is this problem fixed in the mean time?
https://www.youtube.com/watch?v=Er8fZJbYfZ4 (https://www.youtube.com/watch?v=Er8fZJbYfZ4)
Hello
which could put the links to download the latest firmware, please
The links from the first page are dead.
Thank You
That's what I did one week ago and I still have no answer ....
That's what I did one week ago and I still have no answer ....
Me too, I am losing confidence in Rigol
Cheers
Commie
Hi Guys,
That's what I did one week ago and I still have no answer ....
Me too, I am losing confidence in Rigol
Cheers
Commie
That's what I did one week ago and I still have no answer ....
Me too, I am losing confidence in Rigol
Cheers
Commie
I sent email ...
I would have preferred a link is faster :) :=\
That's wierd, it should do the exact opposite. Mine starts on full blast (expected as the software hasn't started fully yet) and then slows back down when it has fully booted and being regulated.
McBryce.
Does your unit have the 3 phases of fan speed (low while booting, fast for a few seconds, low again)?
I just updated my DP832 to 1.14 (file above) from 1.11. My bootloader was already 1.09 so I assume I didn't need to update that. All went well including updating the two analogue boards. However after all was finished and I had restarted, the DP832 had a spontaneous reboot about 10 minutes later (I wasn't pressing any buttons at the time, CH1 was ON but nothing connected to it). It hasn't happened since then (been using it for 30 minutes since then). Has anyone else experienced this? Or noticed any reduced stability since upgrading? I've never had this happen with 1.11
McBryce.
P.s. All "liberated" options are still present after the update.
You have to "ask" rigol for the firmware. To do this, you need to fill in this form: http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm)
@RustyCaliper
Link was posted in post #385 of this thread and still seems to be working. I used that one with no problems.
I'm in the market for a programmable PSU and the Rigol DP832 was on my shortlist; But having seen all the problems listed in this thread, I may have to revise my list :-\
Hello
I need your help
someone has a working script for calibration DP832 in bundles in DM3050 (DM3068) ?
that here I could not get to work
:(
apparently it through not completed and have tested
and I did not have enough knowledge to finish it
Actually neither of them worked on the Rigol. I ran across an issue with the DM3058 when in Agilent command mode that Rigol still haven't resolved. This bug is not an issue with the DM3068 AFAIK. There were some more bugs in the code which I fixed but never published.
I think I will revisit and make it work using Rigol command mode instead of Agilent, and also do a Keithley script as well. Watch this space.
(This was with bsons Python version.)
Is there any way to get such "classic" GUI on the 832 (non A)? I find the numbers on the 832A "classic" far easier to read than the 7 segment imitation of the 832.
I have to agree. Does anyone know of a way to do this without trying to get a whole firmware dump from another 832A?I think we're pretty sure the firmware is identical in these. Has anyone had a look for simple config jumpers? Mine isn't accessible at the moment or I'd look myself.
Kazam, you don't say what cal program you are using or what your equipment is?
I had similar results when using my (modified) version of bsons python script. I put the issue down to the script not waiting long enough for the PSU to settle after changing its settings, but I didn't investigate as I gave up after encountering the DM3058E bugs (which Rigol have still not fixed).
I just chose not to commit the calibration when I had obviously faulty results.
Kazam,
every time I have run the script, it has been like this or worse for the DAC.
I have no definitive insight, but my theory is that the DAC is just outputting uncalibrated values (vs. values calibrated with the current calibration), which makes sense.
Having run the script many times during development, I have anecdotal evidence that this is what happened. I have more than once written totally erroneous calibration data and the supply was then totally unusable, but, even after that, the calibration script turned up similar results. So I assume it is indeed just ignoring current calibration values altogether while running the script. And in my experience, the DAC is off by similar (noticeable) amounts during calibration, with the ADC being very close.
Laurent
Kazam,Indeed, during calibration it disables the calibration corrections, or it wouldn't be able to calibrate. After calibration and installing new calibration data it's important to power cycle the PSU or it will continue operating without calibration data. If I were to guess I'd say it loads calibration tables during power-up.
every time I have run the script, it has been like this or worse for the DAC.
I have no definitive insight, but my theory is that the DAC is just outputting uncalibrated values (vs. values calibrated with the current calibration), which makes sense.
Having run the script many times during development, I have anecdotal evidence that this is what happened. I have more than once written totally erroneous calibration data and the supply was then totally unusable, but, even after that, the calibration script turned up similar results. So I assume it is indeed just ignoring current calibration values altogether while running the script. And in my experience, the DAC is off by similar (noticeable) amounts during calibration, with the ADC being very close.
Laurent
Running DAC-V for channel 1
DACV Ch:1 - Step:0 - Nom:0.200000V - DMM:-0.110548V
DACV Ch:1 - Step:1 - Nom:0.500000V - DMM:0.189599V
DACV Ch:1 - Step:2 - Nom:1.200000V - DMM:0.883774V
DACV Ch:1 - Step:3 - Nom:2.000000V - DMM:1.677662V
DACV Ch:1 - Step:4 - Nom:3.200000V - DMM:2.875726V
DACV Ch:1 - Step:5 - Nom:4.100000V - DMM:3.772613V
DACV Ch:1 - Step:6 - Nom:5.200000V - DMM:4.859532V
DACV Ch:1 - Step:7 - Nom:6.900000V - DMM:6.556295V
DACV Ch:1 - Step:8 - Nom:7.500000V - DMM:7.156451V
DACV Ch:1 - Step:9 - Nom:8.700000V - DMM:8.348862V
DACV Ch:1 - Step:10 - Nom:10.100000V - DMM:9.744890V
DACV Ch:1 - Step:11 - Nom:11.800000V - DMM:11.444056V
DACV Ch:1 - Step:12 - Nom:12.600000V - DMM:12.240194V
DACV Ch:1 - Step:13 - Nom:13.500000V - DMM:13.133796V
DACV Ch:1 - Step:14 - Nom:15.000000V - DMM:14.624108V
DACV Ch:1 - Step:15 - Nom:15.800000V - DMM:15.419533V
DACV Ch:1 - Step:16 - Nom:16.500000V - DMM:16.115537V
DACV Ch:1 - Step:17 - Nom:17.300000V - DMM:16.911583V
DACV Ch:1 - Step:18 - Nom:18.500000V - DMM:18.105339V
DACV Ch:1 - Step:19 - Nom:19.100000V - DMM:18.707224V
DACV Ch:1 - Step:20 - Nom:19.900000V - DMM:19.505043V
DACV Ch:1 - Step:21 - Nom:20.200000V - DMM:19.800305V
DACV Ch:1 - Step:22 - Nom:20.800000V - DMM:20.398841V
DACV Ch:1 - Step:23 - Nom:21.800000V - DMM:21.389631V
DACV Ch:1 - Step:24 - Nom:22.400000V - DMM:21.989582V
DACV Ch:1 - Step:25 - Nom:22.700000V - DMM:22.289575V
DACV Ch:1 - Step:26 - Nom:23.900000V - DMM:23.482165V
DACV Ch:1 - Step:27 - Nom:24.300000V - DMM:23.879192V
DACV Ch:1 - Step:28 - Nom:25.700000V - DMM:25.280637V
DACV Ch:1 - Step:29 - Nom:26.900000V - DMM:26.476796V
DACV Ch:1 - Step:30 - Nom:27.900000V - DMM:27.470796V
DACV Ch:1 - Step:31 - Nom:28.500000V - DMM:28.067346V
DACV Ch:1 - Step:32 - Nom:28.900000V - DMM:28.462864V
DACV Ch:1 - Step:33 - Nom:29.800000V - DMM:29.346933V
DACV Ch:1 - Step:34 - Nom:30.200000V - DMM:29.744620V
DACV Ch:1 - Step:35 - Nom:32.000000V - DMM:31.525673V
Running ADC-V for channel 1
ADCV Ch:1 - Step:0 - Nom:0.000000V - DMM:-0.000376V
ADCV Ch:1 - Step:1 - Nom:0.050000V - DMM:0.049855V
ADCV Ch:1 - Step:2 - Nom:0.100000V - DMM:0.100064V
ADCV Ch:1 - Step:3 - Nom:0.500000V - DMM:0.500868V
ADCV Ch:1 - Step:4 - Nom:1.000000V - DMM:0.999522V
ADCV Ch:1 - Step:5 - Nom:5.000000V - DMM:4.998767V
ADCV Ch:1 - Step:6 - Nom:10.000000V - DMM:9.999298V
ADCV Ch:1 - Step:7 - Nom:12.800000V - DMM:12.799996V
ADCV Ch:1 - Step:8 - Nom:20.000000V - DMM:19.999685V
ADCV Ch:1 - Step:9 - Nom:30.000000V - DMM:30.002926V
ADCV Ch:1 - Step:10 - Nom:32.000000V - DMM:31.999284V
I just ran the calibration program on my setup. Looks different, but not better :-)A negative voltage... How is that even possible?Code: [Select]Running DAC-V for channel 1
DACV Ch:1 - Step:0 - Nom:0.200000V - DMM:-0.110548V
I just ran the calibration program on my setup. Looks different, but not better :-)A negative voltage... How is that even possible?Code: [Select]Running DAC-V for channel 1
DACV Ch:1 - Step:0 - Nom:0.200000V - DMM:-0.110548V
Looks great (making me have Keithley envy)!
Note that for the "readings within 1mV", if you do a full sweep, you'll discover the DAC is a bit all over the place in some spots. See this thread for more background:
https://www.eevblog.com/forum/testgear/noob-dac-linearity-in-the-dp832/ (https://www.eevblog.com/forum/testgear/noob-dac-linearity-in-the-dp832/)
So across the sweep, it's actually much closer to the quoted 10mV accuracy.
10mV sweep included for completeness. There's some positive bias. Overall well within spec.Thanks for sharing - very informative!
I'll stop spamming the thread with plots now... :blah: :)
Thanks for sharing - very informative!
If you got the "Installation Fails" message then you've probably put the wrong key in more than 3 times. As far as I can remember, the DP832 will block all license keys now for the next 24 hours, so you'll have to leave it running for a day before you can try the correct key.Leave it running as in leave power on for a good 24hrs or so?
McBryce.
Yes, if you put a wrong key in 3 times then you need to leave it running for 24 hours. It doesn't have an RTC, so the timer is only ticking when it's powered up.DOH...and I was just thinking changing the date/time might work.
McBryce.
I've had this happen once as well. In my case: Latest Firmware with all options enabled. Nothing connected at all - ie: The power cable was the only cable coming from the unit. No channels were turned on. The PSU had been running for about 3 Minutes at the time from a completely cold start. That was about a 6 Months ago and has never happened since.
McBryce.
I haven't had my DP832 powered on and under observation enough to be at all sure, but seeing a random LXI splash message out of the corner of my eye sounds a bit familiar.I suppose that is good news in that it looks like a software thing then.
I haven't had my DP832 powered on and under observation enough to be at all sure, but seeing a random LXI splash message out of the corner of my eye sounds a bit familiar.I suppose that is good news in that it looks like a software thing then.
I have been pondering changing it for a.n.other 2 or 3 channel PSU to get 0-60v and a high current, might have a look around and see what will fit the bill. Defeats the point of scripting tests if you have to keep stopping to reset the PSU to get the comms back.
I haven't had my DP832 powered on and under observation enough to be at all sure, but seeing a random LXI splash message out of the corner of my eye sounds a bit familiar.I suppose that is good news in that it looks like a software thing then.
I have been pondering changing it for a.n.other 2 or 3 channel PSU to get 0-60v and a high current, might have a look around and see what will fit the bill. Defeats the point of scripting tests if you have to keep stopping to reset the PSU to get the comms back.
I have never seen any issue with my DP832 resetting or getting on/off the network.
Several of us have scripted this PSU, e.g. to analyze the acuracy of the DAC and ADC and have had no issue. In one of my tests, I did a full 1mV sweep of the whole 30V range, which is almost 24hrs of runtime, with no issue.
Obviously, some people have issues with their DP832, but I wouldn't panic and automatically assume this is wide spread and broken on all units. I am not sure what alternative PSU there is that will give you more perceived stability and specs in this price range.
Have you excluded all other possibilities? ie: swapped computers / routers etc to make sure it's not some other part of the setup that's causing the issue?
McBryce.
Have you tried it with USB instead of Ethernet? I'm ashamed to say I haven't even tried the Ethernet option myself, but haven't had issues with USB.I have to admit I haven't, I tend to do everything via ethernet as it's just easier in my setup.
Not a lot of DP832A threads on EEVblog.
I was wondering if these issues have been fixed in the latest PCB/design/firmware revisions?
1. Easy to overload pass mossfet
2. Do people still prefer the DP832 instead of DP832A? Does DP832 have all the updates PCB/design wise?
3. Where's the DP832A hack thread to unlock more resolution? I saw the "Sniffing Rigol's Internal I2C Bus" thread, but that's like >160 pages, not realistic to go through that.
3. Where's the DP832A hack thread to unlock more resolution? I saw the "Sniffing Rigol's Internal I2C Bus" thread, but that's like >160 pages, not realistic to go through that.
Thanks for letting me know. Just out of curiosity - is the firmware between the 832 and 832A the same or different?
Looks great (making me have Keithley envy)!
Note that for the "readings within 1mV", if you do a full sweep, you'll discover the DAC is a bit all over the place in some spots. See this thread for more background:
https://www.eevblog.com/forum/testgear/noob-dac-linearity-in-the-dp832/ (https://www.eevblog.com/forum/testgear/noob-dac-linearity-in-the-dp832/)
So across the sweep, it's actually much closer to the quoted 10mV accuracy.
Hi Laurent, it looks like you are the creator of the cal script and I appreciate your work and sharing this.
I'm just got a new DP832 that is showing different reading and tolerates, it's said it was calibrated 6 months ago. So I plan to try your script since I have a 3 month old calibrated hp 34401A.
One of the factors for buying this was that I could see the current being used on my DUT without adding burden voltage inline.
So one fothe downfall of most bench meters is the high burden voltage when measuring current draw. I still need to learn more on SCPICOMMNADS and install the computer needed libraries So for calibrating the current side (I) I was wondering if you think it's possible that I could modify the script to read voltage for the current reading. What I'm looking at doing is getting the Agilent current shunt that shows 1mV per 1mA for more accurate measurements with the 34401A. So my thought was to modify the script to pull e mV measurements and apply the difference to the current calibration factors on the DP832.
What are the chances of this working after I do the needed research and learn more on this method of communication to my Equiptment? Are the needed command available for such a change to the script, or would I be waisting my time trying to get this to work?
After reading reviews I expected that even my new unit might be out of calibration to what I'm looking to use it for. So I'm happy to say your script was a big part of my decision in buying the DP832. I like the fact that I can have my 34401A calibrated and then use that to calibrate the DP832 without having to spend on getting a second device calibrated. I'm also banking in the age of the 34401A and that it's done drifting, I'll find out if that's true when I send it out in 8 months for my next yearly calibration and compare the data from the original calibration. If it has stopped drifting then a yearly cal may not be needed for someone like me who is just a hobbiest. If the 34401A starts disagreeing with my Fluke 289 then I will have to figure out what meter went off, but for now as long as they both agree within the tolerance expected then I can trust the meter to use for calibrating other Equiptment like the DP832 and save money not having to pay for calibrations.
Thanks,
ScottLooks great (making me have Keithley envy)!
Note that for the "readings within 1mV", if you do a full sweep, you'll discover the DAC is a bit all over the place in some spots. See this thread for more background:
https://www.eevblog.com/forum/testgear/noob-dac-linearity-in-the-dp832/ (https://www.eevblog.com/forum/testgear/noob-dac-linearity-in-the-dp832/)
So across the sweep, it's actually much closer to the quoted 10mV accuracy.
Hi Laurent, it looks like you are the creator of the cal script and I appreciate your work and sharing this.
I'm just got a new DP832 that is showing different reading and tolerates, it's said it was calibrated 6 months ago. So I plan to try your script since I have a 3 month old calibrated hp 34401A.
One of the factors for buying this was that I could see the current being used on my DUT without adding burden voltage inline.
So one fothe downfall of most bench meters is the high burden voltage when measuring current draw. I still need to learn more on SCPICOMMNADS and install the computer needed libraries So for calibrating the current side (I) I was wondering if you think it's possible that I could modify the script to read voltage for the current reading. What I'm looking at doing is getting the Agilent current shunt that shows 1mV per 1mA for more accurate measurements with the 34401A. So my thought was to modify the script to pull e mV measurements and apply the difference to the current calibration factors on the DP832.
What are the chances of this working after I do the needed research and learn more on this method of communication to my Equiptment? Are the needed command available for such a change to the script, or would I be waisting my time trying to get this to work?
After reading reviews I expected that even my new unit might be out of calibration to what I'm looking to use it for. So I'm happy to say your script was a big part of my decision in buying the DP832. I like the fact that I can have my 34401A calibrated and then use that to calibrate the DP832 without having to spend on getting a second device calibrated. I'm also banking in the age of the 34401A and that it's done drifting, I'll find out if that's true when I send it out in 8 months for my next yearly calibration and compare the data from the original calibration. If it has stopped drifting then a yearly cal may not be needed for someone like me who is just a hobbiest. If the 34401A starts disagreeing with my Fluke 289 then I will have to figure out what meter went off, but for now as long as they both agree within the tolerance expected then I can trust the meter to use for calibrating other Equiptment like the DP832 and save money not having to pay for calibrations.
Thanks,
ScottLooks great (making me have Keithley envy)!
Note that for the "readings within 1mV", if you do a full sweep, you'll discover the DAC is a bit all over the place in some spots. See this thread for more background:
https://www.eevblog.com/forum/testgear/noob-dac-linearity-in-the-dp832/ (https://www.eevblog.com/forum/testgear/noob-dac-linearity-in-the-dp832/)
So across the sweep, it's actually much closer to the quoted 10mV accuracy.
Scottjd, what you are trying to do is not complicated, and everything you'll need is already in the script, so you'll just need a bit of Matlab editing to get it to work.
* First, you should install Matlab, the Keysight IO Libraries and make sure you can run the script and go through the first IDN calls. I used to have a 34401A and the script ran on it in draft form. Note that I was using the serial port and had all kinds of issues with that setup.
* Second, the current script probably doesn't work out of the box on the 34401A anymore, but it should be easy to make it do so. You just have to recognize the 34401A IDN and skip the is34461A section, which uses 34461A-only commands (temperature, uptime... which are not critical to the test).
* Finally, for the 3.2A reading, you have to modify a bit of code. When you detect that the current step is >3A, do the voltage init and reading as done during the voltage stepping and do the math.
Note that at 3.2A, you are unlikely to blow the fuse and the 34401A should be able to measure it properly. I believe one of the users in this thread has done it.
I don't really have time to experiment at home, but I can try to help if you bump into any issue.
Laurent
Thanks for the responce,
As for blowing a fuse with the > 3.2A current measurement with the 34401A it won't be an issue if I'm using the more acurate current shut, hence the 34401A will be measuring mV, voltage and not amperage.
But yes, I've done short times of 3.2A current measurements with the 34401A, but this is were its the most inaccurate and can apply 2V of burden voltage, it's why I'm looking at using the shut in the voltage side instead for calibration and it more acurate over the 3.2A range.
I won't be using the serial cominication, I have a keysight GBIP to USB adapter so I shouldn't see these cominication errors.
Thanks for the heads up in these potential issues.
Scott
Thanks for the responce,
As for blowing a fuse with the > 3.2A current measurement with the 34401A it won't be an issue if I'm using the more acurate current shut, hence the 34401A will be measuring mV, voltage and not amperage.
But yes, I've done short times of 3.2A current measurements with the 34401A, but this is were its the most inaccurate and can apply 2V of burden voltage, it's why I'm looking at using the shut in the voltage side instead for calibration and it more acurate over the 3.2A range.
I won't be using the serial cominication, I have a keysight GBIP to USB adapter so I shouldn't see these cominication errors.
Thanks for the heads up in these potential issues.
Scott
I have a weird issue with a DP832A and it's ethernet port and would be interesting if anyone else has issues?I have been experiencing same. Mine is a DP831, 00.01.14 Tried different cables different switch, Static IP, DHCP. (Not really sure what AutoIP is but turn it off when I use ManualIP) etc, but sometimes after time has passed it stops responding but not always.
When in DHCP mode, regardless of the lease duration set on the server, the DP832A requests a new IP every 5 minutes. So it seems to be ignoring the lease duration, although this could be linked to...
Every so often the supply will drop off the network, either a reboot or a reset of the IP parameters via the front panel will fix this. Also the display will display the LAN connected message at power up OK, than also randomly display this again from time to time. Even with a static IP address assigned this will happen too.
I have swapped the ethernet leads, different port on the switch etc. and the problem persists. The unit is running 1.14 but I think it did it with 1.13 too.
It's a real pain as I control the PSU via ethernet for some semi-automated testing of items and it's *really* annoying when it happens as it means I have to restart the tests. The DP832A will complain it is under remote control, but not respond to commands or even a ping when it drops off. You need to 'release' it using the Back key when this happens before you can talk to it again. Even when not talking to the unit via IP and just using the front panel the unit will stop responding on the LAN side too.
Anyone else seen anything strange with the ethernet port or is this a developing issue with my DP832A?
I have a weird issue with a DP832A and it's ethernet port and would be interesting if anyone else has issues?I have been experiencing same. Mine is a DP831, 00.01.14 Tried different cables different switch, Static IP, DHCP. (Not really sure what AutoIP is but turn it off when I use ManualIP) etc, but sometimes after time has passed it stops responding but not always.
When in DHCP mode, regardless of the lease duration set on the server, the DP832A requests a new IP every 5 minutes. So it seems to be ignoring the lease duration, although this could be linked to...
Every so often the supply will drop off the network, either a reboot or a reset of the IP parameters via the front panel will fix this. Also the display will display the LAN connected message at power up OK, than also randomly display this again from time to time. Even with a static IP address assigned this will happen too.
I have swapped the ethernet leads, different port on the switch etc. and the problem persists. The unit is running 1.14 but I think it did it with 1.13 too.
It's a real pain as I control the PSU via ethernet for some semi-automated testing of items and it's *really* annoying when it happens as it means I have to restart the tests. The DP832A will complain it is under remote control, but not respond to commands or even a ping when it drops off. You need to 'release' it using the Back key when this happens before you can talk to it again. Even when not talking to the unit via IP and just using the front panel the unit will stop responding on the LAN side too.
Anyone else seen anything strange with the ethernet port or is this a developing issue with my DP832A?
Very annoying
Its a terrible work around but if you need to be able to get it back on the network remotely I found shut/no shut on the switchport gets it back online.I have a weird issue with a DP832A and it's ethernet port and would be interesting if anyone else has issues?I have been experiencing same. Mine is a DP831, 00.01.14 Tried different cables different switch, Static IP, DHCP. (Not really sure what AutoIP is but turn it off when I use ManualIP) etc, but sometimes after time has passed it stops responding but not always.
When in DHCP mode, regardless of the lease duration set on the server, the DP832A requests a new IP every 5 minutes. So it seems to be ignoring the lease duration, although this could be linked to...
Every so often the supply will drop off the network, either a reboot or a reset of the IP parameters via the front panel will fix this. Also the display will display the LAN connected message at power up OK, than also randomly display this again from time to time. Even with a static IP address assigned this will happen too.
I have swapped the ethernet leads, different port on the switch etc. and the problem persists. The unit is running 1.14 but I think it did it with 1.13 too.
It's a real pain as I control the PSU via ethernet for some semi-automated testing of items and it's *really* annoying when it happens as it means I have to restart the tests. The DP832A will complain it is under remote control, but not respond to commands or even a ping when it drops off. You need to 'release' it using the Back key when this happens before you can talk to it again. Even when not talking to the unit via IP and just using the front panel the unit will stop responding on the LAN side too.
Anyone else seen anything strange with the ethernet port or is this a developing issue with my DP832A?
Very annoying
Glad it not just me!
I have tried all sorts to keep the IP side going, nothing seems to work for long. I have been looking at getting a different PSU, partly because of the IP issue and partly as I could do with a wider voltage range from time to time.
Same problem, when device controlled by matlab trough ethernet DP832A time to time self reboot. Fixed IP.
I have one 3 years ago, with firmware 1.09.00.01 it happens maybe one time per months.
Second tool new one with latest firmware, self reboot almost 1 time per 1-2 day.
My software just in the cycle one time per second fetch current and voltage from CH1 and CH2.
Even it one time happens on my eyes, CH1 and CH2 self OFF, over 0.5 seconds disappear image on the display, over 2-3 seconds tool again ready to work. But connection with computer terminated, program stopped, output is OFF. 1-2 days of work lost.
after self reboot possible immediately restart program and enable output, but need close port and open again.
Maybe somebody know how fix it, or how to see error log from device?
Also wondering if part of the IP related circuitry is exceeding temperature limits as it would not be the first time temperature has been an issue for some of Rigols designs.
And may explain why it is intermittent for me as my gear is in the garage (sadly) which is at the mercy of ambient temperatures.
The same page that generates the option codes seems to have an choice to generate a trial key as well. It may be possible to install the trial key and then just let the time run out. I've never tried it - might be risky as I doubt many people have.
.
.
* DM3068 <<< '[30.0002061]'
* DP832 >>> 'CALibration:MEAS CH1,V,9,30.0002V,0'
* DP832 >>> 'SYST:ERR?'
* DP832 <<< '0,"No error"'
ADC-V 9 : Point: +30V - DMM: +30.000206V - Err:0.000687%
* DP832 >>> 'CALibration:Set CH1,V,10,32V,0'
* DP832 >>> 'SYST:ERR?'
* DP832 <<< '0,"No error"'
* DM3068 >>> 'READ?'
* DM3068 <<< '[32.0024431]'
* DP832 >>> 'CALibration:MEAS CH1,V,10,32.0024V,0'
* DP832 >>> 'SYST:ERR?'
* DP832 <<< '0,"No error"'
ADC-V 10 : Point: +32V - DMM: +32.002443V - Err:0.00763469%
* DP832 >>> 'OUTPUT CH1,OFF'
* DP832 >>> 'SYST:ERR?'
* DP832 <<< '0,"No error"'
Connect the DM3068 10A CURRENT inputs to DP832 channel 1
Press enter to continue
* DM3068 >>> 'CONF:CURR:DC 10A'
* DM3068 >>> 'SYST:ERR?'
* DM3068 <<< '0,"No error"'
* DM3068 >>> 'VOLT:DC:NPLC 100'
* DM3068 >>> 'SYST:ERR?'
* DM3068 <<< '0,"No error"'
* DP832 >>> 'OUTPUT CH1,ON'
* DP832 >>> 'SYST:ERR?'
* DP832 <<< '0,"No error"'
Shutting off PSU outputs
* DP832 >>> 'OUTPUT CH1,OFF'
* DP832 >>> 'OUTPUT CH2,OFF'
* DP832 >>> 'OUTPUT CH3,OFF'
ERROR: global name 'calib_single' is not defined
Calibration failed. Terminating.
d:\Incoming\Drivers\Rigol\DP800\DP832_Cal>
someone use the rigol ultra power app for use the power supply?I think you have to change your regional settings (see https://www.eevblog.com/forum/testgear/rigol-dp832-and-ultrapower-(ultra-sigma)/msg1147413/#msg1147413 (https://www.eevblog.com/forum/testgear/rigol-dp832-and-ultrapower-(ultra-sigma)/msg1147413/#msg1147413))
i tryed it via USB but i have some problems.. i can see the voltage and current levels but i can't modify the values. i can only switch the channels on or off.
also the graph on the right side is useless if i work with low voltage and low current because i cant modify the y axis maximum level that is always 33V..
is there another software for using DP832 on PC?
4. Trigger option disabled in firmware 01.08 and 01.09
For DP832, the Trigger option is lost when upgrading to 01.08 or 01.09. This appears to be a firmware bug as the trial for evaluating Trigger is not active on new units. All options can be enabled in firmwares prior to 01.08.
[00.01.03.00.02] [00.01.06.00.00] [00.01.08.00.02] [00.01.09.00.01]
I received my DP832 today and noticed something strange. When i have the outputs disabled, but connected to my unfused 10A range of my multimeter, there is a significant current flow, different from channel to channel.Lover currents, but I also see them...
Channel 1: 98mA
Channel 2: fluctuating between -10 and -36mA (see scope shot for waveform on multimeter input, the other two channels are stable)
Channel 3: -17mA
When i select 1mA current limit on all channels and i enable them one by one, only channel 1 drops to 0mA (or i guess 1mA, is in the uncertainty of my multimeter :-) For the other channels i have to set a least 10mV (i don't have the high res option enabled yet) and 1mA to get the expected reading of 0 to 2 mA.
The voltages of the disabled channels are of not so much concern (especially given the cheap nature of my multimeter):
Channel 1: 4mV (off) 3mV (on @ 0V)
Channel 2: -5mV (off) -5mV (on @ 0V)
Channel 3: -1mV (off) -1mV (on @ 0V)
Did anyone observe the same effect, i couldn't find anything mentioned so far but i might have missed it.
My DP832 came with firmware version: 00.01.14.00.03 and analog boards: 03.02.04.03.02.04
1. LM317 voltage regulator overheating and causing shutdown
Rigol have "resolved" this issue with a v02.10 board revision as shown in these photos (http://www.flickr.com/photos/eevblog/sets/72157637434451504/) by Dave. Apparently this revised board is shipping in all new units manufactured from roughly Oct/Nov 2013. For units manufactured before that date, Rigol plans to replace units with older boards for free (http://beyondmeasure.rigoltech.com/acton/fs/blocks/showLandingPage/a/1579/p/p-0011/t/page/fm/0).
>> DIY: A number of users have posted custom fixes, typically replacing the LM317 for an alternate regulator. Refer to this post by ted572 (https://www.eevblog.com/forum/blog/eevblog-512-rigol-dp832-bad-design-investigation/msg370859/#msg370859) for a professional looking and inexpensive solution ($1.44), which would probably save time as well.
RE RANDOM REBOOTS
Back on page 18 or so there were mentions of random reboots, I've seen them before and while sitting reading the forum another just happened. Low load on one channel, screen saver on, channel shuts off and system reboots leaving channel off.
Has anyone ever found a solution for this or it just so rare? I've had it running for days without problems then tonight about an hour on it reboots.
George
I never understood why they keep such a tight leash on firmwares. Its been at least a year since 1.16 has been mentioned, and its still not "public".
Anyways, i had the same lan problem and i just emailed rigol and in less than a day they replied.
Should maybe edit the main post to includee the known lan issue and the fix is 1.16
That has been my exact problem and driving me nuts since day dot. Is it possible to share the file or perhaps the rigol contact.
Sigh, they sent me the link to the 1.14 fw. Now the dance begins to get the proper one.
Ill report back once I do get the proper one, or hopefully someone else on this thread can post the 1.16 they have.
If so where should I upload the firmware and instructions?
If so where should I upload the firmware and instructions?
I already posted a link to the firmware (direct from Rigol) in the first post; it's still active. Is it different to what you have?
Sparky
I was unaware (or forgot) of the links you posted and suspect it is the same version.
Note: I tried all the links in the following section but all three appeared broken.
"Firmware Updates and Install Instructions"
At work we have about a dozen DP832A by now (all with FW 1.14) and we have seen random reboots on pretty much every single one during the last one or two years.
But even with the one I'm using on daily basis myself I haven't been able to figure out any pattern, when this happens. Sometimes it reboots after running day and night for days, sometimes it reboots within 1 or 2 minutes after turning it on. Sometimes the reboots happen under heavy constant load, sometimes during power-cycle tests of DUTs, sometimes with channels enabled but idle (no DUTs connected), sometimes while all channels are powered-off. Sometimes I'm lucky and the PSU works for months without a single reboot, sometimes I get three or four reboots on one single day. Never noticed any correlations with room temperature, either.
Very strange...
Sounds like you would be a great candidate for trying v01.16 firmware (see link in first post -- in the list of firmware)! Hopefully it will solve your reboot problem! Let us know!
Sounds like you would be a great candidate for trying v01.16 firmware (see link in first post -- in the list of firmware)! Hopefully it will solve your reboot problem! Let us know!
Is it possible to just reinstall v1.14 after upgrading to this semi-official v1.16 beta firmware?
We're using the PSUs in a production environment, therefore I can't install a not really officially released firmware on all units. If downgrades back to v1.14 are possible, I might give it a try on the unit I'm using on a daily basis, though. As I'm unable to reproduce the reboots in any known way and they seem to occur pretty randomly and sometimes not at all for weeks, it might take quite some time to get some results.
Digital Version : 00.01.14.00.03
Analog Version : 01.02.04.01.02.04
Boot Version : 01.09
Keyboard Version: 01.01
Digital Version : 00.01.16.00.00
Analog Version : 01.02.05.01.02.05
Boot Version : 01.09
Keyboard Version: 01.01
Ok, some information on the v1.16-beta upgrade:
<snip>
If I still notice any more sudden resets with v1.16-beta, I'll let you know immediately.
My DP811 still resets itself once in a while, even after I updated it to F/W 1.16 beta. AFAIK F/W 1.16 was meant to solve the problem of the frequent network dropoffs.
Since the analog hardware of the DP811 is considerable different from the DP832 (which I've also got but didn't notice a single reset event on that one...), I guess the problem is related only to the front panel board. It's quite interesting to see the problem really appears to be more wide-spread than anticipated. And apparently Rigol hasn't got a solution for it yet.
Digital Version : 00.01.14.00.03
Analog Version : 01.02.04.01.02.04
Boot Version : 01.09
Keyboard Version: 01.01
Digital Version : 00.01.16.00.00
Analog Version : 01.02.05.01.02.05
Boot Version : 01.09
Keyboard Version: 01.01
Digital Version : 00.01.16.00.02
Analog Version : 01.02.04.01.02.04
Boot Version : 01.09
Keyboard Version: 01.01
good friend please and high resolution for dp832??Hello: I'm not sure what it is your looking for, although this will probably give it to you and much more.
Did not want to necro the "bad design investigation" thread and ask here prior to opening a new thread in case I missed an old topic that already has the answers.
Channel 1 on my DP832 died. It just dropped to 0V and now stays that way. There was no magic smoke etc. and visual inspection does not give me any pointers so far.
1: Are there any schematics available that I missed?
2: Is this an issue that has been addressed and solved? (I found a mention of defective channel 1 in one of the postings, but there was a whole unit replacement without further investigation)
I had the unit working close to the max. voltage of 32V @50mA with a COB LED connected at the time when the channel simply died.
I would gladly take any pointers from you to save me some time poking around on the board!
Hi, I've just received a new DP832 unit.You can turn the DP832 into a DP832A using a 'magic' USB stick and a single SCPI command; there's a thread here that has all the instructions.
Version information :
Digital Version : 00.01.16.00.02
Analog Version : 04.02.04.03.02.04
Boot Version : 01.09
Keyboard Version: 01.01
All the options were activated just fine using riglol.
Thanks for the useful info on this blog !
I'd like the round font (DP832A) instead the seven digit one, but can someone confirm if DP832A have the option for monochrome gray display ?All the displays that the DP832 can do are available in the DP832A menus, you can have a 'monochrome' display in any single color you want (I think).
I prefer it instead of "3 colour" version.
Regarding DP832 with all options activated vs DP832A, are there any differences (outside the round font) ?
Thanks !
As for good news, I got the DP832A connected via telnet at port 5555 and my Tektronix DMM4050 also works via telnet at port 3490. And since I don't have Matlab, LabView or understand Python (I want to learn it, but its syntax is really weird), I plan on writing a new script in Java using telnet rather than RS232, USB or LXI. If there is any interest in the new script let me know and I'll upload it to the forum.
Well time to start coding. Hopefully I can get this SOB PSU working again.
DMM4050 should have a 34401 SCPI emulation mode or be straight compatible, so one of the existing python scripts will work. I highly recommend using it.
hi all. what is the password for the manual calibration? cheers
Well, looks like they can't publicly release the SCPI cal routine.
Its alive again!Any chance you could come up with an outline of what we need to set up to run your code on a PC? I have a calibrated Keysight 34461A that would be the obvious meter to use to cal my DP832.
I've been stuck at home with what might very well be corona virus (or a very bad case of the flu), and finally decided to write the Telnet script in Java. Java sockets made writing the Telnet client a breeze and with TooOldForThis's reverse engineered SCPI commands I was able to recalibrate channel 1 and 2 better than before the manual calibration fiasco. Honestly, I don't see why people avoid using Telnet, its super convenient and avoids messing with drivers, bulky software and hardware adapters. The only hiccup I noticed was that I had to add some latency between sending commands to the Tek DMM4050, otherwise it would start missing commands. Some 50-60 milliseconds seemed to do the trick.
Is there any reason why people prefer to calibrate it vie scpi rather than through the unit it self? Reading the 16 page document about doing it through the gui it seems pretty strait forward.
Awesome work there. Maybe you could do a little tutorial on how to get telnet talking to the dp832. Would prob benefit guys like me. Hope your feeling better soon, can’t be very nice which having that virus.Seconded. This is what I need too. I can run up Windows 10 Powershell and Telnet to my instruments from there (first you have to enable Telnet in your copy of Win 10, it's disabled by default) and issue 1-off commands but the bit I'm missing is how to do this in a script form. And maybe this is nothing to do with Python? Maybe we need to install some sort of Python App and run Py Telnet scripts from there?
Steve
Seconded. This is what I need too. I can run up Windows 10 Powershell and Telnet to my instruments from there (first you have to enable Telnet in your copy of Win 10, it's disabled by default) and issue 1-off commands but the bit I'm missing is how to do this in a script form. And maybe this is nothing to do with Python? Maybe we need to install some sort of Python App and run Py Telnet scripts from there?
If it does then just do it through the the front buttonsThanks but that was what I was hoping to avoid.
Is there a way to backup/save the calibration on the DP832? I want to try the automated calibration process but I'm worried that I will screw up and make it worse or even unusable.
As far as TooOldForThis's reverse engineered commands go, there is no SCPI command to read the current cal constants and store them on a PC. It might exist, but Rigol won't release the command set, so we can only work with what we have.
I was used your script to calibrate my PSU (832) but with a Siglent DMM (3065X)
I don't know how this work :return dmm.read().replaceAll("\\+","")
first value is negative on PSU (now -235091 mV)
All results inreaDMM are ok as show in pic attached .
What I would like to see uploaded is a picture of the Putty output for
// first set DMM to measure dc current, we want to see if the DMM will change from dc current to dc voltage measurement
*cls
conf:volt:dc auto
samp:coun 1
trig:coun 1
trig:del 0
trig:sour imm
:init
:fetch?
:init
:fetch?
:init
:fetch?
I will have time to look at this over the next week, how do I find out what port number my 34461A is running on?Try 5025 .
if that works as expected, then we need to:
1) manually Telnet into the DP832 and clear the cal constants using
:calibration:start 11111,ch1
:calibration:clear ch1,all.
2) Close Putty to terminate the Telnet connection and then run the script with option 3 voltage calibration for ch1 and option 0 for both ch2 and ch3.
The :calibration:clear ch1,all command will fix any bugs that are present and allow the voltage calibration to work correctly. Then upload the output of the script. If you can manually send commands, then the script can do the same. But if they don't work, then it can't either.
I noticed that you used
*rst
more than once... That resets the instrument back to the "default state." Don't use that. It's not needed. Only *cls is needed, it clears any errors present that the instrument might hang on. And to be honest, even *cls isn't needed, but its good practice to clear errors to avoid possible issues.
From what I've seen of the Putty output you should be good to go. :fetch? return only a SINGLE value each time. That's GOOD! If you placed the DMM into current measurement and then used the remote commands to change it back to voltage, which is what I assume you did, then THAT IS GOOD! You now need to figure out the same thing for the rest of the methods: i.e. local voltage and remote and local current measurement setups. In your case, just replace all local methods in the script with the remote ones.
Finally, you just need to put all that BACK into the the TelnetCal.java file and recompile it and then run the NEWLY complied script. Again, there is no reason the script won't work if you can do it manually.
Done but same problem . Stall at the same point.
But I dont understand how is reading of the voltage interpreted to see why I'm not getting output in script running ...
And I don't understand why are remote and local methods and when and why they are changed ...
If the script was able to print a measurement, then reading the output buffer of the DMM is working. Though something is causing the next read to fail. Either *OPC? is always returning 0, causing an infinite loop or a null string is being received, but that should throw an error.The script is not showing any measurement ! The DMM is showing first value measured after that it will display same value (I have check with another dmm in paralel and it is not getting another values on inputs)
The script is not showing any measurement ! [...] So it doesn't output a measured value .
It is so important to switch to remote to local ?
It seem that set:rem and set:local are not used anymore in SCPI . Also Agilent 34410A has this problem .
;) it is from forum settings . When you have to upload a document you cannot put jar files , so I have to choose something quick . I should have to explain what to do with it or put it into a zip format . If you open it you will see that is plain text, it was just renamed for a quick upload. I have used Visual Studio Code for editing along with Notepad++ .
P.S.
I noticed that you copied the contents of TelnetCal.java into a MSFT Word doc... Use Notepad++ to read and edit the .java files directly. Don't use Word. That's just asking for trouble.
The attached Python script is known to work. It's the same one that has been floating around EEVBlog but has been slightly modified for use with a Keysight 34461A DMM.Thanks, so I'm running Windows 10 64 bit - does Python run in some sort of IDE? Can you please give me a few steps to follow? I'm code-literate but unfamiliar with Python
Requires Python 3.x with the python-ivi library (https://github.com/phsdv/python-ivi).
Change the IP addresses at the beginning of calibrate.py to match your DP832 and 34461A.
Also choose which DP832 channel(s) to calibrate for a given run by un-commenting the appropriate line just after the IP address lines:
calibrate_channels = range(1, 4) # All Channels
#calibrate_channels = range(1, 2) # Channel 1 only
#calibrate_channels = range(2, 3) # Channel 2 only
#calibrate_channels = range(3, 4) # Channel 3 only
I recommend doing one channel at a time.
When you install Python on Windows 10, it has a very minimal IDE called Idle. It is just combined text editor and Python command line interpreter (like old fashioned interactive Basic).LOL, we cross posted. I'll uninstall the MS one and take the one you suggested.
A more complete and popular Python IDE is PyCharm (https://www.jetbrains.com/pycharm/download/#section=windows (https://www.jetbrains.com/pycharm/download/#section=windows)). You would only need the free, community edition for this. The advantage of PyCharm is that you can more directly install add in libraries (like python-ivi) by just selecting them from a list in the IDE instead of having to go through GitHub via the Windows 10 cmd console.
Also, what do I do with the directory set of files attached to your post above? Where do I put them?
Thanks skander,
I was hoping to calibrate my DP832 in 30 minutes, now I'm off down a rabbit hole of learning Java and PowerShell scripting; not how I was planning to spend my Sunday. Plus I have a messed-up DP832
It's clear that the Java has something weird going on with how it handles the responses from my 34461A as I can issue all the commands from a PowerShell Telnet window but the responses I see when running Java have commands that I thought were sent out as the apparent response - the one command that I've commented out (because it didn't work) is the dmm.send("syst:rem"); although the dmm.send("syst:locl"); actually does work - really stupidly confusing.
Now I'm looking at writing a PowerShell script that would issue the commands but I'll have to write it all for the DP832 too :(
I don't own or have any knowledge of Mathlab, can I run a free version?
You're right, it's not obvious!I put your files in a folder and opened calibrate.py but, following your instructions above, the PyCharm menu systems can't find any interpreters. Was I supposed to download one separately to PyCharm or did PyCharm put it somewhere that it needs to be told?
With calibrate.py opened in PyCharm, click on menu item: File > Settings...
Select Project: calibrate.py on the left hand side of the Settings window and then select Project Interpreter.
In the drop down list at the top either select your version of Python or add it using the "gear" button on the right.
Now you will see a list of all of the library packages that are already installed in that particular version of Python. Click the '+' button on the top right to see a list of all other available packages. Select to install python-ivi and python-vxi11. You may need to add others if they are needed as dependents of installed packages. You will find out when you try to run the program and it crashes saying it cannot find something.
pip3 install python-vxi11Thanks JDubU :D
This was missing from my setup ...
The script work with Siglent 3065X but cannot switch from Volt DC to Amp DC , but if you manually switch the callibration is done !
I need only to find why is not switching .
Thank you JDubU !
...
I got PyCharm installed and added the MS Windows Python 3.8 which I can now see and select as the interpreter in the Setting as per your earlier post but there are no plugins listed and I get the error message below. I got a warning that I had a permissions issue so I ran PyCharm in admin mode but it still didn't work.
I've had better days than today.
...
So now I see the Pythin code and the interpreter and packages are all there, I modify the IP addresses, select what channels I want to calibrate, and then...
How do I execute this?
That location is suspicious since it is in a temp folder. It should be in a subfolder of the Python 3.8 installation folder (...\Python38\Lib\site-packages\ivi\agilent) since it augments the behavior of Python for all programs.I think it's Windoze security keeping me from changing certain things, I've had this before where the Temp/xx/yy folders mimic the Programs/xx/yy folder and, when the code wants the file, it finds it in the temp folder. If I'm wrong, I'll try what you suggest.
It may be that there is a copy of it in the wrong place because you had to reinstall Python.
In PyCharm, I suggest that you remove and then re-add those packages (python-ivi, python-vxi11 and numpy) and then go back to the new Python installation folder and do the file modification of python-ivi there.
CONF:CURR:DC 10And the manual states that selecting the 10A range (as above) automatically switches the input to the 10A terminal. Otherwise, the command to do that seems to beSENS:CURR:DC:TERM 10@JDubU
Can you tell me where SCPI parameters for current measure are set in script ? (DC:CURRENT:...) . Or where script switch DMM from voltage to current ...
Thank you !
I'd like to apologize for the hassle everyone has experienced.You have the patience of a saint. I can't believe you bothered to burn up so much of your life helping these people.
I might take my code down since very few people know Java.Please don't. I might want it in the future.
@JDubU
Can you tell me where SCPI parameters for current measure are set in script ? (DC:CURRENT:...) . Or where script switch DMM from voltage to current ...
Thank you !
In the file DP832Cal.py:
The calibration parameters for current are at the top of the file:
cal_daci12 = [0.1, 0.25, 0.5, 0.8, 1, 1.25, 1.5, 1.75, 1.9, 2.15, 2.35, 2.5, 2.75,
3, 3.2];
cal_adci12 = [0, 0.01, 0.1, 1, 2, 3, 3.2];
These are used at the bottom of the file in the Calibrate() method.
Do a search for the comment: "# Current".
Good to hear everyone got their units calibrated using the Python script. I'd like to apologize for the hassle everyone has experienced. The DMM4050 must use a different method to read the output buffer than these other DMMs. I might take my code down since very few people know Java. The only code that really needs to be adjusted are the DMM methods. As everyone has seen, Telnet cal involves much less mucking about but the SCPI commands are completely different between DMMs. If I do keep the script on the forum, I'll probably add a test class for people to get readback working first before running the script.GarrettM , as long as your code do the job with your DMM you are ok.
Again sorry for the trouble everyone has had with the script. It works great with my setup and really shouldn't be hard to figure out, but then again I wrote it. So yeah, my bad.
Also someone know how calibration values was obtained and from where ? Because on channel 2 lower voltages are negative until 40 mV . Only manual calibration of the DAC V on channel 2 manage to calibrate at a 1.5 mV for 1mV value . Above 100mV precission is equal on 3 decimals .
Thank you .
Mine , at 0V on channel 2 show (on DMM) -68mV and only to 39mV set show 0 on DMM - this for automated calibration (Matlab or Pyton same result)
But if I do a manual DAC calibration on CH2 I can obtain 1 to1.5 mV for Zero set. So PSU can do.
So from were the negative offset using calibration constants ... ?
garrettm
Don't feel bad, we know you were sincere in your effort to help. I can test your modified code if you like as long as it's adapted to:
a. NOT clear the DP832A cal and
b. NOT write the new Cal to the DP832
It should be pretty straightforward to come up with some test code that sets up the DP832 to output a certain voltage and then read the value from the 34461A
Thanks for your help.
I know about them but I want to know how they was obtained.
Can you check on your PSU if on CH2 range 0-40mV is ok ?
Thank you very much !
The reason I say this is that when my calibration was broken through the firmware update and cleared after a failed auto calibration, all the cal points were blank and showed up to 52 steps! So it would seem that custom cal points and increased number of cal points might be possible. But maybe not. It really depends on how Rigol implemented the linearization algorithm.
Yes , that I have seen on my PSU also . There were 52 points of calibration . And the first time when I try maual calibration was 44 .
All that needs to be done is to modify the SCPI strings so that a particular DMM can achieve proper configuration and readback. After that, calibration should be a breeze. Just need to copy the modified commands from TelnetTest into TelnetCal.If you look at the output I listed as the test was run, you'll see that the 34461A readings appeared to be the commands that were being sent, like this...
If you look at the output I listed as the test was run, you'll see that the 34461A readings appeared to be the commands that were being sent, like this...
ch1 DAC-V calibration
step 0, cal point: 0.2v, meas val: 34461A> 1
step 1, cal point: 0.5v, meas val: 34461A> *opc?
step 2, cal point: 1.2v, meas val: 34461A> 1
step 3, cal point: 2v, meas val: 34461A> *opc?
step 4, cal point: 3.2v, meas val: 34461A> *opc?
step 5, cal point: 4.1v, meas val: 34461A> *opc?
step 6, cal point: 5.2v, meas val: 34461A> :fetch?
The extended number of calibration points is also mentioned in this thread
-> https://www.eevblog.com/forum/testgear/rigol-dp832a-automatic-scpi-calibration-script/ (https://www.eevblog.com/forum/testgear/rigol-dp832a-automatic-scpi-calibration-script/)
with another calibration script, a bash one.
If I run this code, will it delete the good Cal I already have? I'm happy to test sending data and getting responses from the 34461A but I don't want to go back to where I was a few days back because my Python environment is unstable and I have to recreate the code every time I open up PyCharm (an issue which I'm working on separately).
The prime directive is to have running test gear. I used Python and it works and I'm trying to make it so that everyone can use it without the hassle I had which is why I created a new thread. I'm happy to try to test out your Java code as long as I don't mess up my gear.If I run this code, will it delete the good Cal I already have? I'm happy to test sending data and getting responses from the 34461A but I don't want to go back to where I was a few days back because my Python environment is unstable and I have to recreate the code every time I open up PyCharm (an issue which I'm working on separately).
No cal data is erased or saved and you can skip reading back the ch1 cal points if you want. That's just there to be a better simulation for testing. If you do run the cal point read back, a power reset of the PSU is needed to resume normal operation after running the script. Again, nothing is changed running TelnetTest.class. It only attempts to configure and read measurements from the DMM and then, optionally, read the PSU cal points.
It sounds like you've settled on the Python script, so you don't really need to run the test unless you want to. Though I am curious if we can get the 34461A to work with it, but again, its up to you.
The extended number of calibration points is also mentioned in this thread
-> https://www.eevblog.com/forum/testgear/rigol-dp832a-automatic-scpi-calibration-script/ (https://www.eevblog.com/forum/testgear/rigol-dp832a-automatic-scpi-calibration-script/)
with another calibration script, a bash one.
Here's a picture of my calibrated DP832(A) sending 5.000V to my 34461A :D
Here's a picture of my calibrated DP832(A) sending 5.000V to my 34461A :D
If I had the results you're showing here I'd be worried. It's saying that the output is quite a bit higher than it should be unless those cables you're using have absolutely no voltage drop? Which is unlikely.
McBryce.
@garrettm
It will be more easy to verify the status of calibration if the displayed read value is displayed in real values , not scientific .
The DMM has a 10 Meg ohm input resistance. Even if the leads had a total of 1 ohm resistance, the voltage drop would be half a microvolt.
If I had the results you're showing here I'd be worried. It's saying that the output is quite a bit higher than it should be unless those cables you're using have absolutely no voltage drop? Which is unlikely.
McBryce.
I also planned by myself to edit list with calibration points from thread with bash script. Tommorrow I will make time for this.
Here's a picture of my calibrated DP832(A) sending 5.000V to my 34461A :D
If I had the results you're showing here I'd be worried. It's saying that the output is quite a bit higher than it should be unless those cables you're using have absolutely no voltage drop? Which is unlikely.
McBryce.
The DMM has a 10 Meg ohm input resistance. Even if the leads had a total of 1 ohm resistance, the voltage drop would be half a microvolt.
I decided to do the print format edit first. Now everything is lined up and prints out values in volts and amps. So no mucking about with annyoing scientific notation. I also reduced the settling time to 2 seconds for volts and 3 seconds for current. This is in anticipation of the larger cal point arrays, which will make the calibration take longer.
Let me know if you have any problems with new changes and thanks for using the script!
UPDATE: There was a minor typo in TelnetTest that I fixed. It would cause the DMM to report an error because of an unfinished measuremnt. Accidentally called readDMM() instead of dmm.read() inside the for loop. Whoops.
As soon as you issue an SCPI command the instrument will switch into remote mode and the local panel is disabled. There's usually a way to regain local control.
*RST disables continuous auto triggering in some instruments, so unless you start a measurement (MEASure), set a trigger, or auto trigger-and-wait (READ) the instrument won't take measurements or display a readout (readout being a calibration data corrected measurement). My Keithley 2001 works the same; if I recall it also permits choosing what settings to load on reset, with the default being a complete reset with everything disabled (which is more practical for remote operation).
[...] so unless you start a measurement (MEASure), set a trigger, or auto trigger-and-wait (READ) the instrument won't take measurements or display a readout (readout being a calibration data corrected measurement). My Keithley 2001 works the same; if I recall it also permits choosing what settings to load on reset, with the default being a complete reset with everything disabled (which is more practical for remote operation).
I'm using your Telnet script :-)[...] so unless you start a measurement (MEASure), set a trigger, or auto trigger-and-wait (READ) the instrument won't take measurements or display a readout (readout being a calibration data corrected measurement). My Keithley 2001 works the same; if I recall it also permits choosing what settings to load on reset, with the default being a complete reset with everything disabled (which is more practical for remote operation).
You can also use INIT to begin a measurement, *OPC? to query if the measurement is done and FETC? to move the measurement to the output buffer. Of course, the DMM must be triggered, as you pointed out, either internally, externally or over the bus. I generally let the DMM figure out the triggering (TRIG:SOUR IMM) but you can manually trigger by sending *TRG (if using TRIG:SOUR BUS).
@Trident900fi are you using the Python script or are you writing your own? If you're using the Python script you might want to also get help over at https://www.eevblog.com/forum/testgear/dp832-calibration-using-python-pycharm-running-on-windows/ (https://www.eevblog.com/forum/testgear/dp832-calibration-using-python-pycharm-running-on-windows/). You can also use my Telnet script if you'd like. If you do, test your setup first using test_run.bat.
Are you guys running the 01.16 firmware now? I'm on 01.14 - should I upgrade it?
Basically I'm asking, have others had a good experience with 01.16 or are there any issues with it. :)
If a DP832 has been told it's a DP832A using the magic USB stick, will applying an official GEL file update result in the PSU staying as a DP832A?
I keep seeing this mentioned, do you mean that features are unlocked on the DP832, or do you mean something that makes it think it is a DP832A instead? I'm not familiar with that.Read the thread starting at page 10. You can make a 'magic' USB stick and then issue a SCPI command (while the 'magic' USB stick is plugged in) that tells a DP832 that it's a DP832A; after that, all the features of a DP832A are unlocked and the SysInfo reports that it's a DP832A. It's highly likely that this is how the Rigol factory decides what PSU is what version. You can't change to a model that is not the same hardware e.g you can't change from DP831 to DP832A.
edit : Is it that with a specific usb stick "magic stick" you can use the set model command?
Are you guys running the 01.16 firmware now? I'm on 01.14 - should I upgrade it?You should know that there are two firmware 01.16. Early received from support and late officially released. Judging by the forum earlier it was better. But I haven't tested it myself.
What was the difference(s)?You can read the discussion that began in the post at the link:
...
But I think I have another problem on hand... look at the bottom unit and the current leakage.
...
I just bought an 832A, and the firmware version from the factory is 00.01.19.00.00. I couldn't find any release notes as to what this version includes/fixes. Does anyone have any idea?
v00.01.19.00.00 2022-07-20
- The software increases compatibility with new and old screens;
v00.01.16.00.01
2017-12-18
- The simulation board software is changed to version 02.04
v00.01.16.00.00
2017-01-06
- Fixed the problem that GPIB cannot communicate
- Modified the problem of command *OPT? returning wrong result
v00.01.15.00.02
2016-05-25
- Modified the storage location of calibration points to solve the problem of missing calibration points. If you directly upgrade this version from the previous version, you need to recalibrate.
- Added interval monitoring function in the monitor
- Solved the problem that when the OCP is turned on when the current is small, the current is within the normal range, but the 'over-current protection' prompt will appear
- Added DP812 model support
- Modify the OUTP:TRAC? command timeout problem reported by the front end
v00.01.14.00.03
2015-03-10
- Modify the BUG where OVP and OCP lower limits are displayed incorrectly
- Added support for DP831, DP811, DP811
- Added OVP Trip function for new version of DP811A hardware
- Added series and parallel help information to the main help
v00.01.13.00.01
2014-11-18
- When modifying the dial display, the pointer is always displayed on the 0 scale BUG
- Replace the USB Device library: Solve the problem of unstable USB Device communication (picking the line, picking the computer)
v00.01.12.00.00
2014-9-27
- Added Russian menu
- Added support for DP812A
- Modified the display mode of the readback value on the main interface when the DP821A Timer is turned on.
v00.01.11.00.00
2014-11-03
- Added Traditional Chinese menu
- The maximum number of recording points for the extended recorder is 614400