Siglent SDM3055 multimeter, SCPI commands and Python

[Gunders]

Hi
I’m playing around with The Siglent SDM3055 multimeter, SCPI commands and Python. I have found some minor issues which would be nice to figure out, any help will be appreciated. I have attached the SDM3055 manual.

First of all; I’m using Python 3.4.2 and have installed the PyVISA module (https://pyvisa.readthedocs.org/en/master/) and NI VISA.
 
My basic script is really simple:

• Send *IDN? to check whether I have contact with the instrument.
• Send *RST to reset the instrument to factory settings
• Send MEAS:VOLT:AC? to read AC voltage

Here are my issues so far:

• My first problem is that the *RST cmd don’t reset the instrument, there is no response. I have tried *RST on my Tektronix DMM4050 multimeter and it works as expected, the instrument is reset back to factory state.
• When I run my script the instrument is set in remote mode, that’s fine. But when my script is finished and I have closed the connection to the instrument it is still in remote mode. I haven’t found any commands to get it back into local mode. The only way to get it back into local mode is to push the blue shift/local button at the front panel.

Code: [Select]

import visa
import time

current_measurement = 1
number_of_measurements = 5

print('VISA resources: ')
rm = visa.ResourceManager()
print(rm.list_resources())
siglent = rm.open_resource('USB0::0xF4EC::0xEE38::SDM305C2150105::INSTR', write_termination='\n', query_delay=0.25) #insert the correct VISA resource
print(siglent.query('*IDN?'))
siglent.write('*RST')           #RST function won't work, CLS won't work either
time.sleep(2)

while current_measurement <= number_of_measurements:
    value = siglent.query('MEAS:VOLT:AC?')
    print(value)
    time.sleep(1)
    current_measurement += 1

siglent.close()

[tautech]

Welcome to the forum.

I'm sorry code is not one of my strengths so I'll point Siglent tech support to your thread for assistance.

[Gunders]

Here are a couple of new findings:

• In remote mode the meter doesn’t do any measurements unless you ask for it. So the value shown at the display will be the last reading you read from the meter. I see this as a weakness compared to my Tektronix DMM4050 and BK 5491B multimeters, these meters can continue to do measurements even though I don’t ask for any readings. They continue to function as “normal” multimeters even in remote mode. I haven’t yet found any way to setup/program the Siglent to behave the same way. The problem with the way Siglent does it is that it can take a long time before I get any feedback regarding my current or voltage. For my measurement setups it is quite common to do a measurement every minute and save the data to a CSV-file. If something goes wrong with my circuit I won’t get any feedback until my next reading from the multimeter(unless I can smell it or see smoke). If my sample rate is once a minute it will take maximum 1 minute until the next time I get any feedback and can do any action to save my circuit. The easy way for me right now will be to ask for readings more often and only save data each minute.
• A more severe issue is that the multimeter does a complete restart every now and then. When I use and setup the meter to log every minute for 2-3 days I must trust that the meter operates without restarting. My Python script also fails if the meter restarts. I’m a Python newbie so I haven’t found any good way to solve this in my code.

[pascal_sweden]

Just a side question to another Norwegian fellow

Where do you buy your new test equipment in Norway?
I have used Batronix before, and know about Instrumentcenter in Sweden. Used to live in Sweden.

[Gunders]

Hi Pascal,
it depends on what kind of test equipment. The easiest is to buy from Farnell. Nortelco, http://www.nortelcoelectronics.no/, is also quite big and have good support. For Rigol we have used Venotek, http://www.venotek.no. Our Siglent multimeters come from Batronix.

[eas]

For handling the instrument restart, make use of the Python exception handling with a try/except block. Note the exception generated when the DMM resets and your script fails, then catch that specific exception type in the except. That way you won't eat other exceptions that you'd probably rather see. Or, you could use the quick-and-dirty solution I used the other night -- invoke the script from the command line in an endless loop, with a sleep statement to give the DMM time to restart.  If you are using Linux or OSX with the bash shell, you can do something like this:

Code: [Select]

while true; do python scriptpy.py; sleep 150; done
As to the issue with the update rate of the front display. I took a look at the programming doc, but couldn't figure out the solution from my cursory glance, but, I think you probably want to focus on the triggering setup and look at how to trigger continuously, and you probably want to use either a FETCH or READ to get the latest data, after setting up the measurement mode, rather than calling MEAS every time.

Finally, I'd suggest working to the point where script explicitly configures all critical configuration state, rather than relying on the instrument's defaults, or its current state.

[Gunders]

Hi
I have now spent some time trying to program the multimeter and have attached a code that seems to work well as long as the multimeter doesn't do a random restart. The code asks for voltage measurement at regular intervals and writes the voltage to a CSV-file together with a timestamp. You have to change the file extension from txt to py in order to run the script.

Unfortunately, I'm not very experienced when it comes to Python programming so I haven't included any try/excpetion statements. @Eas is also right when he writes that I shouldn't rely on the instruments defaults but MEAS:VOLT:AC? was the simplest way to get a reading from the instrument and it was a good start. The script attached is a bit more sophisticated.

Regarding the *RST command I got an e-mail from Siglent in Europe where they confirm that there's no response to the *RST command.

I hope some of you will find the script useful 

[noisefreak]

Hi,

I wrote an article about that issue: http://www.zeilhofer.co.at/wiki/doku.php?id=siglent_sdm3065x

I know, this is an older topic, but it costed me a major time to solve the problem of getting current measurements in an adequate time.
My solution solves also the issue with updating the display when remotly controlled.

...
As to the issue with the update rate of the front display. I took a look at the programming doc, but couldn't figure out the solution from my cursory glance...

I hope this will help out many users of the Siglent DMM, which basically is a very good DMM, IMHO.

Greets, Karl

[tautech]

Thanks for the 'heads up' on the error in the programming manual.
I'll pass this on to Siglent for an update/correction to their documentation.

[ScottW]

Old topic, but this is a direct follow-up to the information posted above so this seems like the best place for it.

The article Karl (@noisefreak) wrote and linked above was really helpful to me in two ways:  (1) Demonstrating how to setup continuous, fast triggering and get individual readings when desired, and (2) Pointing out that the "R? 1" command actually returned the "most recent" or "last taken" measurement, despite the documentation (incorrectly) saying it would return the "oldest" measurement from the buffer. 

I wrote code based on Karl's information, and it worked great with firmware 3.01.01.06R2 on my 3065X.  But things fell apart when I recently updated to firmware 3.01.01.10 (2021-JUL)! 

Apparently Siglent "fixed" the "R?" command to work per the documentation.  It now returns the "oldest" value(s) first, as the documentation states.  Unfortunately, that means the technique that previously worked -- using "R? 1" to get the latest measurement -- instead returns an OLD measurement. 

I found a pretty simple fix.  Instead of using "R? 1" to read a value, use the "DATA:LAST?" command.  This will return the last (most current) measurement, as "R? 1" used to do in the old firmware.   And "DATA:LAST?" can be used to get the most recent measurement regardless of firmware version (i.e., it works the same in old and new firmware).

One complication of replacing "R? 1" with "DATA:LAST?" is that the return format is different.  Since "R?" can return multiple values, it's return string is prefixed with some digits to indicate the length, so that had to be interpreted and stripped to isolate the actual value returned.   The "DATA:LAST?" only returns a single value, so there is no length prefix -- but it is suffixed with " VDC", " VAC", etc., so the suffix has to be stripped before attempting numeric conversion.