| Products > Test Equipment |
| Rigol DP832 - Firmware list and bugs |
| << < (138/153) > >> |
| garrettm:
--- Quote from: skander36 on March 17, 2020, 08:01:41 am ---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 . --- End quote --- 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. |
| skander36:
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 ! |
| Gandalf_Sr:
--- Quote from: garrettm on March 17, 2020, 12:35:31 am ---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. --- End quote --- 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?. |
| aristarchus:
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. |
| garrettm:
--- Quote from: Gandalf_Sr on March 17, 2020, 08:55:22 am ---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? --- End quote --- 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. |
| Navigation |
| Message Index |
| Next page |
| Previous page |