Rigol DP832 - Firmware list and bugs

[thn788]

Sounds like the release notes documents Rigol handed out for previous firmware release on request via personal e-mail. Yes, these were available for previous firmware versions of the DP800 (and other Rigol products) already, if you personally asked one of the Rigol FAEs for them.

Automatic translation of these Chinese documents works surprisingly well, but unfortunately didn't reveal significantly more meaningful version information in the past than the already included English parts (I wonder why...  ).

But still nice that Rigol seems to have decided to include these release notes directly with the firmware release, now.

[Omikron]

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   

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 just installed it.  Interestingly, my voltage readouts on each rail when on and set to 0.000 has changed from 0.00 across all three channels to .005, .000, and .001, respectively.  I'm not sure what they "fixed" but it seems strange that the readout would change.  At first first I thought it might have been a difference in how the analog board was working since I hadn't updated the analog board firmwares but the difference persisted even after updating both boards.

[_Wim_]

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...

[Omikron]

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...

That's a negative, Ghost Rider.  I was talking about when the outputs were on.  Also, after your post I tested to see if the readout was working even when the output was off.  It does not appear to be.

[Omikron]

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.

I have been having some serious issues getting this script to work. :-/

First, I tried to do everything over LAN:

Code: [Select]

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

That failed miserably.  I could tell the script was trying to do *something* because both devices were responding to LAN commands and were in remote mode.

After spending way too long trying to troubleshoot that, I switched to USB:

Code: [Select]

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.

Why the heck is the DM3068 self-test failing?  I can run the test manually from the front panel and it passes, but when the script runs it, a FAIL message flashes after the test completes and the script doesn't continue.

Thoughts?

[Omikron]

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?

[Omikron]

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?

To answer my own question, I downloaded the newest version of the programming guide which for reasons beyond my understanding is not published as a PDF but as a fscking Windows Help File (.chm).

I guess *TST? is a common IEEE 488.2 command.  Still no clue why it's failing.

[Omikron]

Just called up to Rigol support and he said he's going to check with a co-worker and get back to me regarding the issue.

[Omikron]

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.

What is particularly troubling is the fact that the self-test passes when started from the Utility menu, but fails via *TST?.

Edit: I realize that this is now more related to the DM3068 than the DP832, so if a mod wishes to move the posts into the appropriate thread, it would be appreciated.

[Omikron]

Apologies for all of the posts, but this is becoming quite a frustrating situation.

I've now been able to get the test to pass and fail intermittently when issuing commands via SCPI.  Sometimes it passes, sometimes it fails.  I can only get failures via SCPI.

That said, the script *also* seems to have an issue in that it doesn't wait long enough for the response from the DM3068.  This is why the response to "*TST?" in the log just shows as ' '.

[Macbeth]

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.

What is particularly troubling is the fact that the self-test passes when started from the Utility menu, but fails via *TST?.

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 

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  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.

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.

[Omikron]

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.

What is particularly troubling is the fact that the self-test passes when started from the Utility menu, but fails via *TST?.

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 

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  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.

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.

So actually, in this case, the *TST? is actually *failing* when issued via SCPI, but only sometimes.  When it does fail, I always get "+1" response and checking the error codes shows the following two codes:

Code: [Select]

* 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"


[vovets]

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:


NOTE: My unit is equipped with TopBoard_V02.20 / BottomBoard_V02.20.

Recreating firmware bug:

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.

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.

I turn CH3 OCP OFF. V/A/W readback remains unchanged and again, my Fluke 87V confirms an actual output of 110.1mA.

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.

I turn CH3 OCP ON. CH3 immediately registers an OCP event, displays a popup warning window and turns CH3 OFF.

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

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.

[kjdotts]

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.

It's good to receive confirmation of the bug and I'm hopeful firmware v1.14 does in fact resolve the bug on my unit.

Thank you for taking the time to post and welcome to the EEVblog forum!

-Kris

[shrek]

Has anyone tried to hack the DP832's ANALOG board? Any luck with JTAG and full memory dump of the controller?

[Omikron]

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?

[Macbeth]

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? 

[Omikron]

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? 

This was precisely my point, but I was trying to tease out what shrek had in mind in the first place.

[Sparky]

Hi all!

I have been busy for sometime and finally got around to updating the first post.     I have noted several things from the thread including 01.14 firmware release, report of coupled AC voltage between Earth and output terminals, report of CH3 OCP bug (thanks kjdotts) and fix in 01.14 (thanks vovets), and Python calibration script by bson (port of LaurentR's MATLAB script).  Thanks to everyone with the updates!

Below I have attached the latest available release notes that came with firmware 01.14, and I can confirm that all options are enabled after installing this release.

Folks, let's try to keep this thread on-topic: posts related to DP832 firmware, bugs and closely related.  Issues of DM3068 and SCPI should be posted in a new thread so as to not derail this one.  Thanks!

Best,
Sparky

[shrek]

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? 

This was precisely my point, but I was trying to tease out what shrek had in mind in the first place.

Hello guys, thanks for responding. Sorry about delay in my reply, but this was a long weekend.

When I asked the question, I was referring to reverse engineering of the analog subsystem of DP832. I have a problem with my unit, where CH2 and CH3 stopped working, showing 0V on the outputs. My diagnose is that the micro's DAC is dead, since I get nothing on the output. Digital part seems OK, responsive to firmware upgrade procedure. And yes, the warranty is gone... since some time ago.  The unit is way too heavy, so sending it off to the nearest repair center is as expensive as like half of the new unit!
My question was actually asking if somebody used the Analog Micro's JTAG, and was it successful, meaning, was the firmware readable or not, all sectors or just a piece... or not... everything worked fine afterwards?
I am getting the replacement for the microcontroller from Farnell soon, but it will be blank, so I'll need to flash it with something. Would be the simple copying back "the fallen one's" dump file work or not?
I believe the calibration tables are stored in the micro's flash, along with original, factory calibrated values. If somebody has a different opinion or experience, please come back to me.

And yes, Dave was right when criticised some of design solutions of DP832 in his video. And what I hate there on the board is erasing chip markings... why for God's sake? We are not going to clone their babies, just to fix them when they're "sick"!

Regards,

Shrek

[Sparky]

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

[LaurentR]

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

Thanks. There are a few other issues as well that materialized in bson's Python port. My DM3068 guinea pig never materialized, so I'll wait for one to try to make a proper update.

[Sparky]

Warning: USB Device broken in 01.14

UPDATE: I re-flashed the 01.14 firmware, and this time no problems!  Ignore below...

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.

[OldNeurons]

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.

[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