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 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.
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.
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.
* 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:
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
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?
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?
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.
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.