-
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.
I was testing on my own with a different DMM so I asume fail.
As I said before your code is unique in that it does not require any setup . Just compile.bat and run.bat The others scripts need Python setup which is a mess with PY-Charm , or MatLab installed .
So if you can put a on/off switch to del/write values in PSU for testing/debug you are ok !
P.S. My unit was first calibrated with MatLab LaurentR script , then wanted to gave Siglent owners an alternative method I gave Python a second chance.
-
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 .
I didn't write the Python calibration script.
Here is a link to its GitHub page which also describes some of its history:
https://github.com/stupid-beard/dp832cal
The calibration values came from EEVBlog member TooOldForThis:
https://www.eevblog.com/forum/testgear/rigol-dp832-firmware-updates-and-bug-list/msg556101/#msg556101
-
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 ! -
No idea how TooOldForThis came up with those calibration points.
Just checked my DP832 and channel 2 is currently reading approximately 1.5mV low at 0V setting.
Set at 0V, measures -1.5mV
Set at 1mV, measures 0.9982mV
Set at 40mV, measures 38.2mV
Set at 0.5V, measures 0.4991V
Set at 1V, measures 0.9982V
Set at 10V, measures 9.9995V
Set at 20V, measures 20.0004V
Set at 30V, measures 29.9998V
I have not done a calibration on it for at least a year. Maybe it's time. -
Just checked channel one.
Set at 0V, measures -0.3mV
Set at 1mV, measures 0.73mV
Set at 40mV, measures 39.7mV -
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 ... ?
-
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 ... ?
Don't know, but it could be that there is just too much negative offset in the channel's voltage control loop for the limited number of calibration coefficients to compensate at millivolt resolution. I'm surprised that they don't have a DAC calibration point at zero volts. -
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.
Thanks. I've already written the new test class (TelnetTest.java). It starts with getting readback from the DMM in dc voltage and current first, then steps through reading back the PSU cal points. Only ch1 is tested since the others are identical. Nothing is cleared and nothing is saved. However, a power reset is needed after the test to resume normal operation of the PSU.
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.
Again, since I've written these scripts I think they are simple, but obviously thats not true for everyone. Especially if you don't know Java. But if you do know C or C++ its very similar, just with OOP concepts where they make sense, like the Telnet clients. Of course there are the Java bultin objects and methods, like for Strings and Scanner. But those you can look up in Oracle's online documentation.
Finally, I've updated the documentation to reflect the recent changes and provided .txt of the output of both TelnetCal and TelnetTest so people can see what its supposed to do when working correctly.
If there are any issues let me know and I'll try and sort them out ASAP. I think using Telnet is honestly the easiest option when calibrating, but if I'm the only one who can get this working, then I'll probably just take it down. No need to "help" people break things that are already working.
-
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 !
I just checked my DP832A and entering 1mv gives 0.7mv on my DMM, 0.000V on the display and entering 10mv gives me 9.4mV on my DMM and 8mV on the display. So TooOldForThis's cal points seem right.
The cal point values are visible in the manual calibration mode, though you would need to look at an instrument that HASN'T been calibrated using one of the scripts to see what the factory cal points are. I am of the understanding that you can actually add cal points and make them arbitrary too. I just haven't played around with that yet.
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. -
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 .
About calibration point I see that is the only one set that is used for both DAC channels (CH1 and 2) .
So , as long as calibration is done well on CH1 but not on CH2, and manual calibration on CH2 adjust them, I see a hardware problem rather than a calibration values. I need to mention that over 100mV , CH2 is very precise .The problem is only to 0-40mV and slowly increase precision to 100mV.
-
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 .
Does your DP832 still show the 44 cal points when manualy calibrating channel 2? If it does, upload a .txt file of them and I'll give them a try on my unit. When I entered into the manual calibration for the first time I only had 36 cal points for DAC-V on channel 1. I think Rigol may have extended the number of cal points on newer units. My power supply dates back to 2014 or maybe even a little earlier. It was made around the time they added the giant silver heatsink on the top analog board to address the over heating problem.
It would be interesting for late model DP832/A owners who haven't calibrated their units with the script to enter into the manual calibration menu and look at the number of cal points avaliable for DAC-V. So long as you exit using the back arrow (to avoid saving anything) and power cycle the unit afterwards, no changes to the calibration will be made. If there are more cal points we can easily improve the automated calibration process and achieve better programming linearity for the output. -
Unfortunatelly no.
From the moment when I start automated calibration test there was only 36 points showed on PSU when I do calibration by hand.
Maybe I can erase everything again to see if the 44 counts or even 52 appear ?
Your new script work for readDMM . It just read the values without any modification on my Siglent .
Even it does not switch to local , the DMM display values from PSU .
So is functional for me .
Thank you !
-
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...
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?
Do you have any understanding on why that may be? I can issue the sequence of dmm commands in your code from telnet and see the expected responses so I believe there's an issue with the read/write buffers in Java or at least something fundamentally wrong with the sequence of data exchange.
Any ideas?. -
The extended number of calibration points is also mentioned in this thread
-> https://www.eevblog.com/forum/testgear/rigol-dp832a-automatic-scpi-calibration-script/
with another calibration script, a bash one.
-
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?
It looks like the 34461A is echoing back the commands from readDMM(). I'm not sure Java is the problem here. We are clearly able to connect to the 34461 via Telnet (half the battle). So the Java Socket is okay. We can also send a command and actually read back a reply, even if its not what we expected. So PrintWriter and BufferedReader look to be okay. But maybe <CR>, <NL> or <EOL> aren't sent the way Keysight wants. I'll have to look into this. It could be that the 34461A is case sensitive. I was pretty lazy about capitalizing the SCPI strings since my gear didn't seem to care one way or the other while testing. Hell, even the Tektronix Programming Manual uses lowercase.
If you could, try the new TelnetTest.java file I've attached to this message, which uses "proper" SCPI case, with the "3rd release" .zip file in my earlier message I would appreciate it. If that works, then it was just an issue of character casing. I doubt that is the issue, but it doesn't hurt to check. I also removed the colon ":" from INIT and FETC? in readDMM(), as the Keysight manual doesn't show them. (The Tek manual uses colons in front of those two commands.) I also added *CLS before trying to read, to clear any errors that might cause reading the output buffer to hang. Hopefully one of those changes will help.
-
The extended number of calibration points is also mentioned in this thread
-> https://www.eevblog.com/forum/testgear/rigol-dp832a-automatic-scpi-calibration-script/
with another calibration script, a bash one.
Thank you! I didn't know about that thread. That basically confirms my hunch that you can do custom cal points. I believe there are 0-52 (53 in total) cal points each for DAC-V, ADC-V, DAC-I and ADC-I. So you can do a very thorough calibration routine if desired. A big improvement would be to start at 0 for all of the cal points. Why Rigol doesn't do this is beyond me.
I'm going to give this a try later today. If everything goes well, I'll upload the new version of the script with 53 points per parameter. Apparently, the hex dump shows 80 cal points. But I'll stick to "just" 53, since the firmware is more likely to work with that from what I've seen. -
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).
-
Rather than clog up this firmware list thread any more, I created a new thread on DP832 Calibration using Python & PyCharm Running on Windows
Can JDubU and any others who can help, please jump over there and figure out how to create a perfect Python environment to perform DP832 calibration?
Thanks
-
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 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/
with another calibration script, a bash one.
Good catch!
I did some experimentation with added control points using the Python calibration program and got good results with the attached DP832Cal.py. For channels 1 and 2, it has 46 voltage calibration points and 31 current calibration points. I did not change the calibration points for channel 3. You can freely change the number and values of the calibration points in the top of the file. No other changes need to be made in the program (gotta love Python!).
I have not yet tried a lot of variations on the number or values of the calibration points but did find that it gets a bit unstable with too many points near zero. The ones in the bash script did not work as well and caused my zero volts to go negative after that calibration.
-
Here's a picture of my calibrated DP832(A) sending 5.000V to my 34461A
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. -
Here's a picture of my calibrated DP832(A) sending 5.000V to my 34461A
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. -
On some points is X.000 (like 5.000/7.000/10.000) and other is X.999 (like 4.999/7.999/21.999) . It is not a high precision multimeter with a very stable reference though ...
-
@garrettm
It will be more easy to verify the status of calibration if the displayed read value is displayed in real values , not scientific .
step 0, cal point: 0.2v, meas val: -1.54019811E-01
step 1, cal point: 0.5v, meas val: 1.46975726E-01
step 2, cal point: 1.2v, meas val: 8.42319390E-01
step 3, cal point: 2v, meas val: 1.63485328E00
step 4, cal point: 3.2v, meas val: 2.83015883E00
Thank you !