Controlling a Rigol DP832 using Python-IVI

[ernest...@gmail.com]

Hi Alex,

We just recently obtained a Rigol DP832, and I've been trying various ways to control it via USBTMC. We're hoping to control it using a Linux embedded system (currently simulating it in an Ubuntu VM), and hence hoping to find an alternative to using NI-VISA + the software that they provided. I've tried a few things to get it working, and your solution seems the most promising to date... so here I am!

I've been able to initialize the instrument (at least, it didn't complain), but when I try to send it commands, nothing changes in the power supply. When I unplug the USB, the kernel begins complaining, so I assume that there's some level of communication happening. Examples of things I've tried are (I called it DPPS):

These commands happily execute without complaining, but the PS doesn't change:

DPPS.outputs[0].voltage_level = 12.0

DPPS.utility.reset()

DPPS.identity.supported_instrument_models

returns: 'DP831A, DP832, DP832A'

However, I'm pretty sure that's just hard-coded and isn't actually communicating with the device?

These commands give issues - I chose these as I was trying to find something that would explicitly write "*IDN?", because that's the step that's always failed me in all my approaches:

DPPS.identity.instrument_manufacturer()

DPPS.identity.instrument_serial_number()

The last few lines of the error are:

File "build/bdist.linux-x86_64/egg/usbtmc/usbtmc.py", line 347, in unpack_bulk_in_header

struct.error: unpack_from requires a buffer of at least 4 bytes

I've come across this error before in my other attempts as well, making me think that perhaps the issue is within Python USBTMC.

Would you have any idea what potential issues might be? I'm more than happy to provide any other information or detail my other attempts if you think it'll help. I'm perfectly happy working with the raw SCPI commands - getting some sort of communication/response from the device is my top priority. I also understand that you don't have a Rigol power supply device physically with you, but I'm also more than happy to play around with it here and feedback accordingly - I'm starting to run out of leads to follow!

Thanks a lot, I really appreciate it!

Ernest

[Alex Forencich]

Well, for one, the identity.instrument_whatevers (and most of everything in python-ivi) are properties, not functions, so you just read them:

print(DPPS.identity.instrument_manufacturer)

You can also test by bypassing python-ivi and connecting directly with python-usbtmc:

import usbtmc
psu = usbtmc.Instrument('some::resouce::string')
print(psu.ask("*idn?"))

Second, this issue seems familiar, though I was under the impression that it was fixed: https://github.com/python-ivi/python-usbtmc/issues/1 .  Oddly enough, this issue was opened almost exactly a year ago.  Go figure.  This may be something else, though. 

What versions of python and pyusb are you using?  Do you have the latest version of python USBTMC from git?

Also, can you please include a complete stack trace instead of just the last line?

Alex Forencich

--
You received this message because you are subscribed to the Google Groups "python-ivi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python-ivi+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ernest...@gmail.com]

Hi Alex,

Thanks for the quick reply.

1) Thanks for that, I'm pretty much new to everything involved here, so everything's appreciated. I tried bypassing python-ivi as you suggested, and the same thing happens. This is the full output:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "ivi/ivi.py", line 187, in __getattribute__
    return f()
  File "ivi/scpi/common.py", line 55, in _get_identity_instrument_manufacturer
    self._load_id_string()
  File "ivi/scpi/common.py", line 43, in _load_id_string
    lst = self._ask("*IDN?").split(",")
  File "ivi/ivi.py", line 1957, in _ask
    return self._interface.ask(data, num, encoding)
  File "build/bdist.linux-x86_64/egg/usbtmc/usbtmc.py", line 462, in ask
  File "build/bdist.linux-x86_64/egg/usbtmc/usbtmc.py", line 445, in read
  File "build/bdist.linux-x86_64/egg/usbtmc/usbtmc.py", line 401, in read_raw
  File "build/bdist.linux-x86_64/egg/usbtmc/usbtmc.py", line 351, in unpack_dev_dep_resp_header

  File "build/bdist.linux-x86_64/egg/usbtmc/usbtmc.py", line 347, in unpack_bulk_in_header
struct.error: unpack_from requires a buffer of at least 4 bytes

2) Wow literally on the same day. I'm using Python 2.7.6, PyUSB version is Beta 1.0.0. Python USBTMC version is 0.5 - all of these have been downloaded from git over the past 4 days.

3) I copied the entire section as above, let me know if you meant something else. If it helps, I've also included what happens when I do: strace echo "*IDN?" > /dev/usbtmc0 directly in the kernel (without initialising it using ivi). It gets to the last line and then just sits there until either the sudo is killed, or the Rigol is unplugged/switched off.

root@ernesttan-VirtualBox:/dev# strace echo "*IDN?" > usbtmc0
execve("/bin/echo", ["echo", "*IDN?"], [/* 27 vars */]) = 0
brk(0)                                  = 0x25f4000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc198cd0000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=80106, ...}) = 0
mmap(NULL, 80106, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc198cbc000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\37\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1845024, ...}) = 0
mmap(NULL, 3953344, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc1986ea000
mprotect(0x7fc1988a6000, 2093056, PROT_NONE) = 0
mmap(0x7fc198aa5000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bb000) = 0x7fc198aa5000
mmap(0x7fc198aab000, 17088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fc198aab000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc198cbb000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc198cb9000
arch_prctl(ARCH_SET_FS, 0x7fc198cb9740) = 0
mprotect(0x7fc198aa5000, 16384, PROT_READ) = 0
mprotect(0x606000, 4096, PROT_READ)     = 0
mprotect(0x7fc198cd2000, 4096, PROT_READ) = 0
munmap(0x7fc198cbc000, 80106)           = 0
brk(0)                                  = 0x25f4000
brk(0x2615000)                          = 0x2615000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=7216688, ...}) = 0
mmap(NULL, 7216688, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc198008000
close(3)                                = 0
fstat(1, {st_mode=S_IFCHR|0660, st_rdev=makedev(180, 0), ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fffdc133d80) = -1 EBADRQC (Invalid request code)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc198ccf000
write(1, "*IDN?\n", 6

Thanks a lot!

Ernest

[Alex Forencich]

Oh, the /dev/usbtmc device is not working?  That is very odd.  Python USBTMC bypasses this driver and connects to the device directly so it doesn't matter if the kernel driver is present or not, but if the kernel driver isn't working, then it seems the issue may not be a problem with Python USBTMC.  Have you tested the device with any other computers?  Are you sure the USB cable is good?  It also could be a problem with the VM USB forwarding.  Can you possibly try this outside of the VM?  Python USBTMC will run in Windows and in Mac OS. 

Alex Forencich

[Alex Forencich]

Also, what VM software are you using?

Alex Forencich

On 08/07/2014 06:23 PM, ernest...@gmail.com wrote:

[ernest...@gmail.com]

I'm right now in the process of getting Python USBTMC set up on my Windows side. I'm using VirtualBox, running Ubuntu (tried both 64-bit and 32-bit, same behaviour)

 - I've been able to control it using their supplied software (Ultra Sigma), which uses NI VISA. This was on Windows. That seems to indicate to me that the cable and machine was working okay. 

 - I've been able to read/write files from a USB stick in the same port using cat/echo, which suggests the forwarding is okay from within the VM (unless it's specifically an issue with USBTMC).

I'll feedback again once I've tried Python USBTMC in Windows.

Cheers!

Ernest

[Alex Forencich]

I'm thinking this may be a forwarding issue with either USBTMC itself or the specific implementation on the instrument.  If NI VISA works in Windows to communicate with the device, then it seems like there should be no issue with Python USBTMC communicating with it from Windows. 

Another possibility to try is installing NI VISA in the virtual machine.  Not sure if you can do that in Ubuntu or not.  I have a Scientific Linux 6 VM that I use to test PyVISA integration, but I have not tested forwarded USB support. 

Alex Forencich

[ernest...@gmail.com]

It works in Windows! I've got a native Linux partition here as well, will just need to undust it a little. I've read that it's pretty painful to get NI VISA on Ubuntu, so hopefully it's just an issue with the VM and I can get it to work natively.

Cheers,

Ernest

[ernest...@gmail.com]

It works in the native Linux as well! So looks like it is a forwarding issue with the VM after all. Now I just have to try it with our actual embedded board, but unfortunately I can't do that till later.

Thanks a lot for your help, really appreciate it!

Ernest

[Alex Forencich]

No problem.  Nice to hear that you got it working.  It would be nice to figure out what's up with the VM, but I think that might be a real pain to debug. 

Alex Forencich

[ernest...@gmail.com]

Hi Alex,

Just as a heads up, I've been having some issues when using Python USBTMC directly - I'm still trying to poke around and figure out what might be wrong. It seems to be timing issues when calling the read or ask functions - it seems pretty happy writing commands if no response is required.

Sample log (Windows):

C:\Python27>python Rigol.py

Traceback (most recent call last):

  File "Rigol.py", line 30, in <module>

    print PPS.ask("*ESR?")

  File "C:\Python27\lib\site-packages\usbtmc\usbtmc.py", line 462, in ask

    return self.read(num, encoding)

  File "C:\Python27\lib\site-packages\usbtmc\usbtmc.py", line 445, in read

    return self.read_raw(num).decode(encoding).rstrip('\r\n')

  File "C:\Python27\lib\site-packages\usbtmc\usbtmc.py", line 399, in read_raw

    resp = self.bulk_in_ep.read(read_len+12, timeout = self.timeout)

  File "C:\Python27\lib\site-packages\usb\core.py", line 301, in read

    return self.device.read(self.bEndpointAddress, size, self.interface, timeout

)

  File "C:\Python27\lib\site-packages\usb\core.py", line 654, in read

    self.__get_timeout(timeout)

  File "C:\Python27\lib\site-packages\usb\backend\libusb01.py", line 483, in bul

k_read

    timeout)

  File "C:\Python27\lib\site-packages\usb\backend\libusb01.py", line 568, in __r

ead

    timeout

  File "C:\Python27\lib\site-packages\usb\backend\libusb01.py", line 384, in _ch

eck

    raise USBError(errmsg, ret)

usb.core.USBError: [Errno None] libusb0-dll:err [_usb_reap_async] timeout error

In Linux, I've had some issues that causes the computer to not even recognise the USB device is there anymore until the Rigol is restarted - I haven't quite figured out if it's the same issue though. I'll keep poking around and let you know what I find. I'll also try going through python-ivi and see if the same thing happens.

Cheers,

Ernest

Ernest

For more options, visit <a moz-do-not-send

...

[Alex Forencich]

That's odd.  What is the timeout set to?  And is this consistent (every read call fails) or not?

It should not make any difference if you use python-ivi or usbtmc directly - python-ivi will just call read, write, and ask in usbtmc so if those calls fail then you will know about it. 

Alex Forencich

For more options, visit https://groups.google.com/d/optout.

[ernest...@gmail.com]

If it's the one in usbtmc.py, then 1000. I tried fiddling with that number, but didn't make a difference.

It's not consistent. It happens more often than not - if I keep running a simple program of say, write("*RST") followed by ask("*IDN?"), it'll crash in anywhere between 1 and 10 attempts. If my program has multiple ask/read calls, it sometimes get past the first ones to fail at the latter ones. If I have a program of just write commands there's no issues. 

This issue only happens when running a python script - not when putting in commands into the interactive shell. So if I manually make it reset, then *IDN?, then apply voltage, then switch output on, then measure power, it works. If I put all those into a .py file, then it gets cranky. I then thought there might be timing issues, so I threw in half second sleeps around the place - no difference. Also tried doing something like write("IDN?"), sleep(0.5), then reading. Same issue. I've also been playing around with the *OPC and *OPC? commands - putting them around the place seems to change the behaviour, but I can't quite figure out how yet.

I'll try to get the logs from the Linux side in a bit. Over there it seems that another issue occurs when the device tries to (re)initialise - not sure if the two issues are perhaps related.

On another note, I just tried ivi on Windows and it's not finding the device (command literally copy pasted from Linux, where it works). But I'd probably prefer to use usbtmc directly anyway, since I'm just dealing with the one device.

Cheers,

Ernest

...

[ernest...@gmail.com]

Here's the log from Linux. I tried doing it with ivi - sure enough, same thing as with usbtmc.

Code:
import ivi
pps = ivi.rigol.rigolDP832("USB::6833::3601::DP8C162951547::INSTR")
pps.utility.reset()
print pps.identity.instrument_serial_number
pps.outputs[1].voltage_level = 12.0
pps.outputs[1].enabled = True
print pps.outputs[1].measure('voltage')
print pps.outputs[1].measure('current')

After running this script several times (in this case, 3 times, but historically anywhere between 1 and 10 times), the following error is produced, and the Rigol must be restarted to re-establish communication. This occurs even if only write commands are sent.

Traceback (most recent call last):

  File "iviplatypus.py", line 3, in <module>
    pps = ivi.rigol.rigolDP832("USB::6833::3601::DP8C162951547::INSTR")
  File "/usr/local/lib/python2.7/dist-packages/python_ivi-0.14.4-py2.7.egg/ivi/rigol/rigolDP832.py", line 35, in __init__
    super(rigolDP832, self).__init__(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/python_ivi-0.14.4-py2.7.egg/ivi/rigol/rigolDP800.py", line 35, in __init__
    super(rigolDP800, self).__init__(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/python_ivi-0.14.4-py2.7.egg/ivi/rigol/rigolBaseDCPwr.py", line 43, in __init__
    super(rigolBaseDCPwr, self).__init__(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/python_ivi-0.14.4-py2.7.egg/ivi/scpi/dcpwr.py", line 48, in __init__
    super(Base, self).__init__(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/python_ivi-0.14.4-py2.7.egg/ivi/extra/common.py", line 33, in __init__
    super(SerialNumber, self).__init__(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/python_ivi-0.14.4-py2.7.egg/ivi/scpi/common.py", line 104, in __init__
    super(SelfTest, self).__init__(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/python_ivi-0.14.4-py2.7.egg/ivi/dcpwr.py", line 56, in __init__
    super(Base, self).__init__(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/python_ivi-0.14.4-py2.7.egg/ivi/ivi.py", line 1691, in __init__
    self.initialize(resource, id_query, reset, **kw)
  File "/usr/local/lib/python2.7/dist-packages/python_ivi-0.14.4-py2.7.egg/ivi/scpi/dcpwr.py", line 82, in _initialize
    super(Base, self)._initialize(resource, id_query, reset, **keywargs)
  File "/usr/local/lib/python2.7/dist-packages/python_ivi-0.14.4-py2.7.egg/ivi/ivi.py", line 1777, in _initialize
    self._interface = usbtmc.Instrument(resource)
  File "/usr/local/lib/python2.7/dist-packages/python_usbtmc-0.5-py2.7.egg/usbtmc/usbtmc.py", line 237, in __init__
    self.device.set_interface_altsetting()
  File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 832, in set_interface_altsetting
    self._ctx.managed_set_interface(self, interface, alternate_setting)
  File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 179, in managed_set_interface
    self.backend.set_interface_altsetting(self.handle, i.bInterfaceNumber, alt)
  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", line 743, in set_interface_altsetting
    altsetting))
  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", line 552, in _check
    raise USBError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBError: [Errno None] Other error
Exception usb.core.USBError: USBError(19, u'No such device (it may have been disconnected)') in <bound method Device.__del__ of <DEVICE ID 1ab1:0e11 on Bus 001 Address 006>> ignored


Before, I had also done a system lsusb call just before the pps = ... line. The Rigol appears in the usb listing up till that line itself - then it disappears after the error. It seems unlikely to me that the issues in Windows and Linux are related (due to failing at different lines etc.), but I thought I might as well put everything down.

Ernest

Second, this issue seems familiar, though I was under the impression that it was fixed: <a href="https://github.com/python-ivi/python-usbtmc/issues/1" targ

...

[giripremi]

Hi I'm new to python and we have  DP832A in lab to which I need to communicate with using python. Can anyone tell me what are the steps I need to follow. I have to do it by USBTMC and Ethernet. Howshould I start? Do I need to include any libraries for the  same?
Thanks

[ernest...@gmail.com]

Hi,

Sorry I haven't been on here for ages. Are you using Windows or Linux?

[Spork Schivago]

Hey Ernest,

I'm using Linux and I'm thinking of purchasing this Rigol DP832.  Did you ever figure out the problem?  I'm thinking of ordering mine tomorrow.  I too am curious as how to use python to communicate with the device.  I'm hoping a good night of sleep and a fresh mind in the morning will enable me to properly find out how to communicate with the power supply in Linux.  Thanks!