Cannot capture from DS1074Z - multiple messages

[vicnevicne]

Hi,
This tool really seems to fulfill one of my needs : capture without bloated drivers. However, I can't seem to make it work with my DS1074Z.
Surprisingly, each time I start the same command line, I'm getting a different error message, in sequence:

D:\DS1054Z_screen_capture-master>python OscScreenGrabLAN.py png 192.168.0.212

ERROR: No Rigol from series DS1000Z found at  192.168.0.212
ERROR

D:\DS1054Z_screen_capture-master>python OscScreenGrabLAN.py csv 192.168.0.212
command error
Check the oscilloscope settings.
Utility -> IO Setting -> RemoteIO -> LAN must be ON
ERROR

D:\DS1054Z_screen_capture-master>python OscScreenGrabLAN.py bmp 192.168.0.212
Instrument ID: RIGOL TECHNOLOGIES,DS1104Z,<serial_removed>,00.04.00

Receiving screen capture...
Traceback (most recent call last):
  File "OscScreenGrabLAN.py", line 149, in <module>
    im = Image.open(StringIO.StringIO(buff))
  File "C:\Python27\lib\site-packages\PIL\Image.py", line 2317, in open
    % (filename if filename else fp))
IOError: cannot identify image file <StringIO.StringIO instance at 0x02059DA0>

D:\DS1054Z_screen_capture-master>

And the cycle restarts if I request again.

It seems the first call cannot see the scope, but wakes it up. The second call sees the scope but it doesn't reply yet. The third call sees the scope, gets a reply (the "Receiving screen capture" step lasts a few seconds) but then crashes.

Any idea ?

[RoGeorge]

It seems the first call cannot see the scope, but wakes it up.

What do you mean by "wakes it up". Is your oscilloscope powered on, with the display showing the traces? Mine is always on after I push the power button.

• The message "ERROR: No Rigol from series DS1000Z found at 192.168.0.212" means that the computer was able to reach the IP you specified, asked the oscilloscope for its name, the oscilloscope replied, but the name is not what the program expected.

In your case, the oscilloscope has replied with an empty line (the line imediatly after your "python OscScreenGrabLAN.py png 192.168.0.212" command). Instead, the answer should have been the oscilloscope ID, "RIGOL TECHNOLOGIES,DS1104Z,<serial_removed>,00.04.00".

• On the second run (csv request) your oscilloscope replied with "command error" instead of "RIGOL TECHNOLOGIES,DS1104Z,<serial_removed>,00.04.00"
• On the 3rd run (BMP request), your oscilloscope finally replied with a valid instrument ID. Some data was received, but something went wrong trying to save it as a BMP.

At each run, the program ask for the oscilloscope ID sending the same SCPI command, "_idn?", no matter what type of csv/bmp/png was requested. It is strange that your oscilloscope is sending different answers for the same "_IDN?" command.

• Check the LAN by pinging your scope from a command prompt:
  ping -n 20 192.168.0.212
  There should be no lost packets.
• Disable any standby mode or power save features your oscilloscope might have, then try again.

[vicnevicne]

Hi,

Thanks for your reply.
I didn't make myself clear, sorry. The scope is up and running for the whole session and shows a trace. There is no "standby" or similar setting enabled anywhere that I know of, and a "ping -t" indicates zero packet loss.
What I mean is that it looks like the first call I issue reaches step 1 (find the scope) then stops, the second call reaches step 2 (recognize the scope) then stops, and the third call reaches step 3 (start retrieving the image) and then stops. But if I go on, the next call is back to step 1 and so on.
Also, sorry if I didn't use the same export format on each run in the sample above. That is irrelevant as I'm getting the same results no matter the output format.
Here is a video capture of what I'm observing: https://youtu.be/L9J5dluZzko
As it's not very legible (crappy action cam), in the top command window, I execute the same command "python OscScreenGrabLAN.py png 192.168.0.212" over and over, and the bottom command runs a "ping -t" (I stop it once with CTRL-C to show it's still running). Here's a capture at the end:

What more can I do to debug the issue further ? Is there a debug mode or something I can enable ?
Kind regards,
Vicne

[RoGeorge]

Hi and thanks for the effort to debug this issue.

• From your ping screenshots I noticed your windows is in French. I didn't tested with any OS language other than English. I will look into possible OS language issues later (character set setting in command prompt).
• From the video, I noticed that a message appears on the scope display at each run. The message is hard to read from the video, but I bet the display message says "Invalid Input!". This usually happens when a new command is received while the oscilloscope is busy.

Right now, I am trying to add a check for "scope busy" (maybe a debug mode too), then I will reply to you when the new version will be ready.

[RoGeorge]

Hi,
The first release, v1.0.0, is ready for you to test.
Please download it from
`https://github.com/RoGeorge/DS1054Z_screen_capture/releases
then unpack and run.

It will create a log file 'OscScreenGrabLAN.py.log'. For the moment, logging features are always on, and it will be appended at each run. I didn't had more time to add a switch for debugging, so the log will grow after many runs, sorry for that. It will be fixed in the future version.

You can delete the log file any time you want, after a run has completed.

Please let me know if v1.0.0 is working for you.
Please attach the log file 'OscScreenGrabLAN.py.log' to any future issues.

Thank you for your feedback,
RoGeorge

[vicnevicne]

Hi,
Sorry for the delay. Busy end of week...
I tested the new version but the behaviour is somewhat different. On the first run, I got

D:\DS1054Z_screen_capture-master>python OscScreenGrabLAN.py png 192.168.0.212
Instrument reply: command error
Check the oscilloscope settings.
Utility -> IO Setting -> RemoteIO -> LAN must be ON
ERROR

and on the second run, I got:

D:\DS1054Z_screen_capture-master>python OscScreenGrabLAN.py png 192.168.0.212
Found instrument model
Traceback (most recent call last):
  File "OscScreenGrabLAN.py", line 144, in <module>
    print "Found instrument model", id_fields[model], "instead of expected model, DS1*Z"
IndexError: list index out of range

Then if I run it again and again, I mostly got the "LAN must be ON" error, and less often the "IndexError"

Here is the log for the two first runs. I admit I don't see a difference between the two except the second one makes one more request...

2016-10-01 15:02:26,897 - INFO - New run started...
2016-10-01 15:02:26,897 - INFO - Log message: INFO level set.
2016-10-01 15:02:26,897 - INFO - ***** Running Python version:
2016-10-01 15:02:26,897 - INFO - 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:19:22) [MSC v.1500 32 bit (Intel)], sys.version_info(major=2, minor=7, micro=12, releaselevel='final', serial=0)
2016-10-01 15:02:26,898 - INFO - sys.version_info(major=2, minor=7, micro=12, releaselevel='final', serial=0)
2016-10-01 15:02:26,898 - INFO - Installed Python modules:['pillow==3.3.1', 'pip==8.1.2', 'setuptools==20.10.1']
2016-10-01 15:02:26,953 - INFO - SCPI to be sent: *idn?
2016-10-01 15:02:26,953 - INFO - Send SCPI: *OPC?
2016-10-01 15:02:26,957 - INFO - Received response: RIGOL TECHNOLOGIES,DS1104Z,DS1ZA161951786,00.04.00

2016-10-01 15:02:26,957 - INFO - Send SCPI: *OPC?
2016-10-01 15:02:27,957 - INFO - Received response: command error
2016-10-01 15:02:27,957 - INFO - Send SCPI: *OPC?
2016-10-01 15:02:27,961 - INFO - Received response: 1

2016-10-01 15:02:27,961 - INFO - Sent SCPI: *idn?
2016-10-01 15:02:28,961 - INFO - Received response: command error
2016-10-01 15:03:06,510 - INFO - New run started...
2016-10-01 15:03:06,510 - INFO - Log message: INFO level set.
2016-10-01 15:03:06,510 - INFO - ***** Running Python version:
2016-10-01 15:03:06,510 - INFO - 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:19:22) [MSC v.1500 32 bit (Intel)], sys.version_info(major=2, minor=7, micro=12, releaselevel='final', serial=0)
2016-10-01 15:03:06,510 - INFO - sys.version_info(major=2, minor=7, micro=12, releaselevel='final', serial=0)
2016-10-01 15:03:06,512 - INFO - Installed Python modules:['pillow==3.3.1', 'pip==8.1.2', 'setuptools==20.10.1']
2016-10-01 15:03:06,602 - INFO - SCPI to be sent: *idn?
2016-10-01 15:03:06,602 - INFO - Send SCPI: *OPC?
2016-10-01 15:03:06,621 - INFO - Received response: RIGOL TECHNOLOGIES,DS1104Z,DS1ZA161951786,00.04.00

2016-10-01 15:03:06,621 - INFO - Send SCPI: *OPC?
2016-10-01 15:03:07,621 - INFO - Received response: command error
2016-10-01 15:03:07,621 - INFO - Send SCPI: *OPC?
2016-10-01 15:03:07,628 - INFO - Received response: 1

Don't know if it helps...

Vicne

[vicnevicne]

Oh, and yes, the message "Invalid Input" sometimes (not every time) pops up on the scope with both versions. I tried in "STOP" mode on the scope but I'm still getting it randomly.

[vicnevicne]

Now wait, your note "This usually happens when a new command is received while the oscilloscope is busy." makes me think of a conflict.
I remembered that I once installed the Rigol tools (Ultra Sigma). The tool is not running, but could it be that a driver, service or something is running in parallel and conflicts with the commands you send ?

[RoGeorge]

Thank you for letting me know. There are 2 problems with v1.0.0 of the script. First, is that somehow I managed to push a broken version and tag it as the first release, v1.0.0. My bad here, sorry for that. Second is that different versions of oscilloscope firmware respond different to the same SCPI commands sent by the script.

As an example, the firmware version I have on my scope now, 00.04.03 SP1, is accepting commands without '\n' at the end. Other firmware versions seems to require a mandatory '\n' at the end of each command.

Also, 00.04.03 SP1 is adding 2 unexpected bytes at the end of the bitmap file. These two bytes does not follow the description of the BMP format, and does not follow the description of the response described in the Rigol's own manual. These 2 extra bytes can also be seen with Wireshark.

Long story short, this weekend I will try to fix all the reported issues:

• missing '\n'
• variable BMP length response
• broken CSV capture