Rigol DSA815 and PyVISA - setting frequency and span almost never working - Page 1
Forum section: electronics / testgear

author: mwilson
author_rank: Contributor
timestamp: December 14, 2013, 10:57:36 pm
content: I'm trying to play around with some automation using PyVISA to control my Rigol DSA815 over the LAN. I'm pretty new to VISA/SCPI/etc, but am making progress. However, I'm getting very inconsistent results when trying to set values like center frequency and span. I'm using Python 2.7 on Windows if that makes any difference.Reading values always works. Commands like turning the tracking generator on (:OUTPut ON) and the reset to defaults (:SYSTem:PRESet) always work. But most of the time when I try to set a value, nothing happens.Here's what I'm doing. Basically resetting, setting a center freq and a span, then reading the center freq and span to see if it took effect. Run through that ten times and print the results:Code:import visaimport timedef test_commands(sa, delay):"""Run a sequence of commands. sa is the spectrum analyzer to control,delay is the number of seconds to wait between commands."""sa.write(":SYSTem:PRESet")time.sleep(delay)sa.write(":FREQuency:SPAN 0")time.sleep(delay)sa.write(":FREQuency:CENTer 1000000")time.sleep(delay)current_freq = sa.ask(":FREQ:CENT?")current_span = sa.ask(":FREQ:SPAN?")if(current_freq != "1000000"):print ("Freq FAIL (%s)" % current_freq),else:print ("Freq PASS"),if(current_span != "0"):print "Span FAIL (%s)" % current_spanelse:print "Span PASS"sa = visa.instrument("TCPIP0::192.168.43.123::INSTR", term_chars='\n')print sa.ask("*IDN?")for i in range(10):test_commands(sa, 1)And here's the output when I run the script:Code:Rigol Technologies,DSA815,DSA8A15xxxxxxx,00.01.07.00.01Freq FAIL (750000000) Span FAIL (1500000000)Freq FAIL (750000000) Span PASSFreq FAIL (750000000) Span FAIL (1500000000)Freq FAIL (750000000) Span PASSFreq FAIL (750000000) Span FAIL (1500000000)Freq FAIL (750000000) Span FAIL (1500000000)Freq FAIL (750000000) Span FAIL (1500000000)Freq FAIL (750000000) Span FAIL (1500000000)Freq FAIL (750000000) Span FAIL (1500000000)Freq FAIL (750000000) Span FAIL (1500000000)So the frequency never got set, and the span only got set twice.I turned the delay between commands down to zero and ran it again:Code:Rigol Technologies,DSA815,DSA8A15xxxxxxx,00.01.07.00.01Freq FAIL (750000000) Span PASSFreq FAIL (750000000) Span PASSFreq FAIL (750000000) Span FAIL (1500000000)Freq FAIL (750000000) Span FAIL (1500000000)Freq FAIL (750000000) Span FAIL (1500000000)Freq PASS Span FAIL (2000000)Freq FAIL (750000000) Span FAIL (1500000000)Freq FAIL (750000000) Span FAIL (1500000000)Freq FAIL (750000000) Span FAIL (1500000000)Freq FAIL (750000000) Span FAIL (1500000000)This time the frequency got set successfully once! And the span got set a couple times. But still... usually not working. I did have one test run earlier (with 1 second delay) where both frequency and span got set correctly.Anyway... what am I doing wrong?Can anyone successfully and consistently set the center frequency and span using PyVISA on a Rigol DSA 815 over the LAN?

author: Harvs
author_rank: Super Contributor
timestamp: December 15, 2013, 04:20:30 pm
content: To narrow down your problems have you tried the same commands just using the NI tools that allow you to manual type each command in? Be worth trying to see if it works every time.I've used PyVISA with the DS2000 and never had any issues.

author: free_electron
author_rank: Super Contributor
timestamp: December 15, 2013, 04:25:04 pm
content: Set center first, then change span.I know it sounds silly, but it may work.

author: mwilson
author_rank: Contributor
timestamp: December 15, 2013, 07:39:20 pm
content: Quote from: Harvs on December 15, 2013, 04:20:30 pmGood idea... looks like I'm getting the same behavior from the NI VISA Test Panel. I can consistently execute commands like *IDN? and :system:preset, but have very intermittent (few and far between) successes setting center frequency or span.Quote from: free_electron on December 15, 2013, 04:25:04 pmUnfortunately that doesn't seem to make a difference.

author: G0HZU
author_rank: Super Contributor
timestamp: December 15, 2013, 08:53:26 pm
content: I don't have any experience of this instrument but it will take a finite amount of time for the analyser to change frequency or the span and then get a legit trace. This is because of the retune time of the PLL etc.So could it be that the analyser needs a longer timeout in order to achieve these commands? Are you trying to send another command too soon?The other commands you tried should occur almost instantly. Does the analyser send an echo 'after' it has retuned and performed a sweep over the new span? This could require a long delay to happen in hardware before you can send another command.

author: Mr Simpleton
author_rank: Unknown
timestamp: December 15, 2013, 08:54:43 pm
content: Even though I do not have the 815 I am somewhat curious... reading the programming guide it states the command for frequency setting as: [:SENSe]:FREQuency:CENTer <freq>Is the SENS embedded in the driver?

author: alex.forencich
author_rank: Frequent Contributor
timestamp: December 16, 2013, 03:38:11 am
content: Quote from: Mr Simpleton on December 15, 2013, 08:54:43 pmIf it's in brackets then it's optional. The following are all (or at least should be) equivalent::sense:frequency:center:sens:freq:cent:frequency:center:freq:centetc.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: December 16, 2013, 03:39:12 am
content: Try waiting longer after the reset. Try like 10 seconds. It may still be resetting itself when you try to set the center and span parameters.

author: clifford
author_rank: Regular Contributor
timestamp: December 16, 2013, 08:27:11 pm
content: Quote from: alex.forencich on December 16, 2013, 03:39:12 amthis.I don't have a DSA815 but I know from my other RIGOL devices that one second is not always enough when waiting for a reset.SCPI actually has a quite good mechanism for synchronizing with commands that execute in the background. Unfortunately I've never managed to get this working with any of my RIGOL equipment (DG1022, DM3068, DS2072, DP1308A).Either I am doing something wrong or RIGOL did not bother implementing this stuff. I assume it is the latter, but I can't be sure because I don't have any other devices with SCPI (VXI-11 or USBTMC) support to test my scripts.PS: I'm using PyVXI11 (https://pypi.python.org/pypi/PyVXI11) for VXI-11 and the Linux kernel USBTMC driver (seehttps://github.com/eevidtron/eevt002/blob/master/usbtmcDevice.pyfor a primitive python wrapper with visa-like api) for VXI-11 and USBTMC on 64 bit linux because there are no 64 bit linux visa drivers..

author: alex.forencich
author_rank: Frequent Contributor
timestamp: December 17, 2013, 04:15:20 am
content: If you need a cross-platform solution, take a look at my pure python USBTMC and VXI11 drivers here:https://github.com/alexforencich/python-vxi11https://github.com/alexforencich/python-usbtmcThey have both been verified in Linux and in Windows. I have heard that python-usbtmc works on the Rasberry Pi as well.I also have an instrument abstraction library that I am working on:https://github.com/alexforencich/python-ivi. I am would like to add support for Rigol devices, but unfortunately I do not have any to test on.And I think the SCPI interface on the Rigol devices is more of an afterthought. The documentation is horrible and the DS1000 series scopes are missing some rather important commands related to waveform readback, making it rather difficult to figure out how many points you will get and what those points actually mean in terms of voltages and time steps.

author: mwilson
author_rank: Contributor
timestamp: December 19, 2013, 06:06:43 am
content: Quote from: alex.forencich on December 16, 2013, 03:39:12 amUnfortunately I don't think it's a timing problem. When it works, it works instantly; when it doesn't work, it doesn't work no matter how long I wait. When I'm testing manually with the NI VISA Test Panel I can see this too... every once and a while the center frequency or span changes when I issue the command (nearly instantly), most of the time I issue the command and can wait all day without the change reflecting on the instrument.I have also tried doing things the "right way" and calling the *OCP? (going off of memory here) SCPI command which shouldn't give a result (of 1) until previous SCPI commands have finished executing. Whether I call *OCP? or get the status byte which I clear the complete bit in with OCP before issuing the frequency set command, I get the "completed" result back even though nothing has happened.Perhaps time to see how good Rigol support is and ask them about it... thanks for all the suggestions, but it sounds like nobody else that's chimed in so far has an 815 they've tried to program over the LAN interface to verify if this is common behavior or not with this particular instrument.

author: Bored@Work
author_rank: Super Contributor
timestamp: December 19, 2013, 09:07:45 am
content: Quote from: mwilson on December 19, 2013, 06:06:43 amLAN interface? The first thing I would do is to get Wireshark out and check if the packets are going out. The second thing would be to use Wireshark to check if they contain what they should contain. The third and forth thing would be to repeat the previous two steps at the receiving end (inserting a switch with a port mirror/monitor or a network tap close to the instrument).

author: kmr
author_rank: Newbie
timestamp: December 19, 2013, 03:18:33 pm
content: Quote from: mwilson on December 19, 2013, 06:06:43 amI found it to be common. I've had the same problem of SCPI commands only sometimes changing parameters on the LAN interface (using python-vx11). I then change the interface to a USB interface based on PyUSB and encountered the same problem. I've found some work-arounds that where my interface adds varying characters to the end of a command that improves the likelihood that a setting will be changed while also avoiding subsequent errors from :SYSTEM:ERROR? about invalid characters found.For setting parameters, the below work-around has been the most successful that I've found:Code:elif ((c.find(":SENS") > -1) or (c.find(":CALC") > -1)) and (c.find("?") == -1):c = c+" ; *WAI \r\n"A more difficult problem to work-around has been when the DSA815 has taking increasingly long times to respond to a command or query, up to over 60 seconds, and then returns a VXI-11 timeout error with a -5 error code. Even more difficult problems has been been the device stops responding to LAN altogether including not responding to pings. The work-around for that is to exit the remote mode with the ESC key and then using the PRESET button to reset the device. The most difficult problem is then the display freezes and doesn't respond at all to its keypad and the only work-around I found is to power-cycle the device.Unfortunately, I haven't found a short and completely reproducible test case to send to Rigol. It appears the increasingly long command times, stopping responding to ICMP pings, and freezing of the instrument occur more frequently as the tests proceed, but the exact duration of run before problems occur is non-reproducible, even running with the exact same parameters and after a fresh power-cycle.To completely collect the data needed for the below plots usually requires 3-5 runs of the problem with me adjusting the start parameters of the program between runs so that I collect data over the entire range. I then manually combine the output of the program executes into a single output file which would be in the correct format if the program could run correctly from start to finished. With several dozen of hours of trying work-arounds and collecting partial data on runs, I've collected data for:

author: free_electron
author_rank: Super Contributor
timestamp: December 19, 2013, 06:03:32 pm
content: Try querying the deve for responses. This looks like an i ternal buffer overflowing after a while. There may be messages waiting that you never read ...

author: kmr
author_rank: Newbie
timestamp: December 19, 2013, 08:33:43 pm
content: Quote from: free_electron on December 19, 2013, 06:03:32 pmHi Vincent, I had the same thought. One of the first things I added was clearing any error messages by repeatedly querying :SYSTEM:ERROR? after every SCPI command until the error response buffer is empty. I also tried various combinations of *WAI and OPC? to try to ensure that I wasn't building up any queuing data that would cause an overflow. In the FW 1.07 that I've been using, there is least one bug in both SCPI command parsing as well as in the progressive non-responsiveness to SCPI commands. The latter, I agree, is consistent with a buffer overflow. I'm not sure of other buffers that I can keep from growing other than the SCPI system error query. I've blindly increased time between commands and adding *WAI commands for the possibility of that there is a time-sensitive component to the unresponsive state.

author: mwilson
author_rank: Contributor
timestamp: January 04, 2014, 09:37:20 pm
content: Okay, for those playing along at home (and for people googling for this in the future), I think I've gotten to the bottom of the problem.The short version: when using PyVISA, setterm_chars='\n'on the instrument object. Do not include any new lines or line feeds on the commands themselves.The long version:I suspected this was a line endings (termination characters) problem from the start because I had to manually put in \n characters at the end of my lines using the VISA test panel or the instrument.ask() method of PyVISA, whereas on my Agilent scope I didn't have to (the defaults seemed to work fine). By default it looks like PyVISA was using \r\n as the termination characters. Manually putting in \n at the end of my commands would make some commands work, but there were then still those couple of trailing characters.I thought I had tried all of the permutations and combinations trying to find the magic combination of term_chars and manually-appended line endings that would work, but the reason I was getting such seemingly random intermittent results in my attempts was becauseas soon as you send one command with the wrong termination characters, no further commands (at least the ones that are affected by this) work until you power cycle the instrument. I thought the fact that the "*IDN?" query kept working even after FREQ:CENT commands didn't work, the SCPI engine in the instrument must have still been in an okay state. But that wasn't the case. Eventually I realized that UltraSigma worked to do the FREQ:CENT commands if that was the first program I ran after powering on the instrument. If I did anything from Python first, UltraSigma didn't work. The power cycle was the key.In any case...it sounds like from others' experience there may still be some bugs I'll hit in the SCPI implementation in the instrument, but at least I'm past my initial issue of the frequency and span set commands seeming to almost never work: now as long as I get the termination characters right and reboot the instrument if there's ever a bad command, the commands seem to be working consistently.

author: kmr
author_rank: Newbie
timestamp: January 06, 2014, 06:34:43 pm
content: Quote from: mwilson on January 04, 2014, 09:37:20 pmYes, Rigol's SCPI implementation isn't robust handling termination characters. Glad that you figured our PyVISA. For the interface library that I'm using, python_vxi11, does not append any termination characters by default, so it was easier to find a combination of termination characters that both were effective for the current command and also didn't queue any errors for :SYSTEM:ERR? to report.For myself, I wrap a call around each write command with an idea based on PHK's pylt library: call AOK() after each command to query for any errors and report them. Now that you're past that point, the next place where I ran into problems was querying the X and Y marker positions where the DSA815 would progressively delay returning until either commands timed out, the LAN interface stopped responding to ICMPs, or the device keyboard and display would freeze. If you find some robust way to work around this, I'd be interested in your method.

author: casinada
author_rank: Frequent Contributor
timestamp: January 06, 2014, 06:49:47 pm
content: Is Rigol support helping about this problem?I'm thinking about purchasing the 815 with tracking generator.

author: kmr
author_rank: Newbie
timestamp: January 07, 2014, 04:40:28 am
content: Quote from: casinada on January 06, 2014, 06:49:47 pmI haven't requested Rigol's assistance as I haven't taken the time to create a simplified test case for their technical support. For example, I haven't taken the time to test if I'd get the same issues when calculating X and Y marker positions if my test program wasn't driving a waveform generator to create test signals for which I was querying the DSA815 to analyze. So, requesting tech support is on my list of things to do as soon as I have cleared my list of things that are of greater present concern.

author: kmr
author_rank: Newbie
timestamp: January 19, 2014, 11:16:24 pm
content: Looks like firmware version 1.08 for the DSA815 has helped. Now time to try removing layers of workrounds to see exactly how well the new firmware without the workarounds. Seems like other fixes are in store for the LXI firmware. From the release notes:Version: 00.01.08.00.03 Date: 2013-12-021. Solve the problem some spelling mistakes. M2. Temporary solution to the problem LXI communication is unstable. M3. Increased multi-language support, including Portuguese,German,Polish,Korean and Japanese. E4. Solve the problem marker table and PF don’t display correctly. M

author: kmr
author_rank: Newbie
timestamp: January 20, 2014, 07:01:41 pm
content: With 1.08, I was able to remove all my work-around command line terminations. Also, queries no longer cause the unit to have progressive delays with responses and to ultimately stop responding altogether.