Connect Rigol DM3058 to Agilent Data logging utility

[iDevice]

You have a 34401A?

Yep.

Perhaps you can test if it is an actual 34401A command? Using the SCPI terminal:

*CLS [Send]
ABORT [Send]
SYST:ERROR? [Send & Read]

I just tried and no errors nor beep.

If there is No Error then that is a command that Rigol should implement for compatibility. Maybe they have on the 3068? try the same but obviously after sending CMDS AGILENT and see what happens. 

Ok, so I tried the "Abort" command on the '68 but first in RIGOL mode and it didn't accept it, but when I switched to AGILENT mode it did without error...
So at least we know that it has been fixed on the '68.

Next, I tried again the IDNS command and checked for error and in fact it seems the '68 accepts it, so now we know it is supported by the '68 with the same syntax as the '58.
*IDN? still answers with the RIGOL signature though so I then tried the IDNS? command and what do you know ?, it answered with the AGILENT defined string I just sent with IDNS earlier...
So, the '68 definitely understand the IDNS command and store the string ok but just fails to report it with the *IDN? query.

So basically we have a 3058 that correctly honors the personality change but fails on the ABORT command and a 3068 that fails on the personality change but accept the ABORT command in AGILENT mode. 

Good job RIGOL...

One additional info is that this setting is volatile. To be sure the personality change didn't need a reboot to be effected on the *IDN? query, I rebooted the '68 after a IDNS command and it reverted back to the standard RIGOL signature.

[Macbeth]

So basically we have a 3058 that correctly honors the personality change but fails on the ABORT command and a 3068 that fails on the personality change but accept the ABORT command in AGILENT mode. 

Good job RIGOL...

I don't know what those Rigol DMM boys are smoking... 

What irks me is the "fix" for the Agilent mode READ? command documented in '68 1.10. This was never an issue with the 3068, but the 3058 its a total obvious failure!. I think some Chinese Whispers have somehow changed the reported fault from 3058 to 3068 and they've wasted a year scratching their heads wondering what exactly is wrong... then figured its some white space

Anyway, more sniffing and another BenchVue command my Rigol chokes on is SYST:LFR? BenchVue itself seems to choke when the ABORT command fails in the live meter mode and actually completely crashes.

The only reason the Data Logger sort of works with the 3058 is because its using the FETCH? command and not READ?

Now the poorly implemented IDNSET seems to be a new introduction to the 3068 with 1.10 firmware. I know the 3058 has had it since 2010 because their UltraSensor software of that era sends CMDSET RIGOL and IDNSET RIGOL to the meter constantly. Unfortunately it can also send some low level undocumented data (not SCPI) as well which doesn't update the sensor data, but can lead to a bricked meter. I think I should start a whole new topic on that including how to recover via JTAG without sending it back to Rigol  (and yes, I have informed them of this UltraSensor problem and confirmed the German HQ support guy managed to brick his own meter following specific instructions. But I am not holding my breath on a fix any time soon.)

[Macbeth]

Oh one other thing. The response to IDNSET? - does it force the supplied string to lower case on the 3068? It does on the 3058 and I can't work out the rationale. Perhaps there is some inherited SCPI pre-processing that forces all input to lower case for easier processing and its inherited from that.

[iDevice]

Oh one other thing. The response to IDNSET? - does it force the supplied string to lower case on the 3068?

Yes it does as well.

[Dwaine]

I used the IDNS? and also got the aglient string on read.   But the IDN? still reports the Rigol.  Output listed below.

[Macbeth]

So in summary we need the following fixes by Rigol:

DM3068 FW 01.10:

Fix the IDNSET command so that it actually works with *IDN? the same way it does with DM3058 FW 02.02
* Possibly implement SYST:LFR? if it isn't already - even a spoof version so SYST:LFR 50 | 60 is possible to set it or just default a return value of either - pick one!

DM3058 FW 02.02:

Implement the Agilent ABORT and SYST:LFR? commands so they don't throw an error, the same way they work with DM3068 FW 01.10
...and fix the READ? command while we are at it... I refer Rigol to my earlier bug report from last year.

(* not had it confirmed that SYST:LFR? works on the DM3068 or 34401A - not in official documentation for either, but BenchVue wants it for some reason?)

[iDevice]

* Possibly implement SYST:LFR? if it isn't already - even a spoof version so SYST:LFR 50 | 60 is possible to set it or just default a return value of either - pick one!

SYST:LFR? works perfectly on the 3068 as well as on the 34401A

[Dwaine]

* Possibly implement SYST:LFR? if it isn't already - even a spoof version so SYST:LFR 50 | 60 is possible to set it or just default a return value of either - pick one!

SYST:LFR? works perfectly on the 3068 as well as on the 34401A

Tested it here on my 3068.   SYST:LFR? works fine.....    Oh man, if we could only get the IDN to return the agilent string.   It would be really nice to get the benchvue working with the meter.   It's really nice software.

[Macbeth]

Well I guess its time  for you to get onto Rigol and point them at this thread. But I wouldn't hold your breath waiting on a quick fix, not if my experience is anything to go by 

[dssence]

Well I just bought this DM3058E meter, and wanted to test for some data logging capability. But there's not much you can do , a couple 2 applications done be some independant guys not working easily. I tried Ultraview but it's asking me a license I hoped I could try it as a trial and it's nto working, do I need to validate my equipment serial number.  So make story short we're screwed no simple way to have an on screen display in realtime on windows to see all logging by the meter?.
  I played around with Keysight benchvue and modifinyg signature to Agilent. Switches modes but hangs.