Bug 933 - Not Display waveform and data
Summary: Not Display waveform and data
Status: RESOLVED FIXED
Alias: None
Product: libsigrok
Classification: Unclassified
Component: Driver: rigol-ds (show other bugs)
Version: unreleased development snapshot
Hardware: x86 Windows
: Normal blocker
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
: 679 765 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-04-20 09:22 CEST by Giorgio Evangelista
Modified: 2017-05-11 11:57 CEST (History)
5 users (show)



Attachments
logo of acquire. (19.69 KB, text/plain)
2017-04-20 09:22 CEST, Giorgio Evangelista
Details
Log on successful readout. (28.09 KB, text/plain)
2017-05-09 19:55 CEST, Martin Ling
Details
Log on failure. (13.08 KB, text/plain)
2017-05-09 19:55 CEST, Martin Ling
Details
Successful log after fix (VXI) (28.34 KB, text/plain)
2017-05-10 01:46 CEST, Martin Ling
Details
Successful log after fix (TCP) (29.83 KB, text/plain)
2017-05-10 01:46 CEST, Martin Ling
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Giorgio Evangelista 2017-04-20 09:22:07 CEST
Created attachment 290 [details]
logo of acquire.

Pulse View 0.4.0 git 8b9056d

RIGOL MSO1104Z
fw 00.04.03.SP2   i think last today 20/04/2017

PulseView send command, configure parameter, start acquirie, but nothing appairs on screen.
Comment 1 Soeren Apel 2017-04-20 19:09:35 CEST
As discussed on IRC, my assumption is that the 'co' are the first two bytes of "command error". While there may be a reason why *OPC? may fail, I have also seen a similar log from the same user where even :WAV:YREF? prompted a "command error" response from the scope.

Hence, my assumption is that there is sometimes data lost when sending the SCPI commands. The user connects to the scope via TCP/IP, so there may be a bug in the TCP/IP SCPI layer, too.

Martin, do you have such a scope? I don't know who else does.
Comment 2 Martin Ling 2017-04-20 19:55:17 CEST
I have access to that model but I won't be at that lab till next week. I can have a look then (maybe remind me on IRC next week).
Comment 3 Giorgio Evangelista 2017-04-21 08:28:12 CEST
I am available to any test, if you wish.
Why not save the IP? Every time I open I have to reset the device search.
When I exit the program, windows says pulsewiev.exe has stopped running.
Comment 4 Soeren Apel 2017-04-21 09:53:10 CEST
Well, as I said on IRC: if would be good to connect to the device via USB instead of TCP/IP to see if the problem is still present.
Comment 5 Giorgio Evangelista 2017-04-21 10:01:02 CEST
Ok
Tried now.
USB works properly.
Comment 6 Giorgio Evangelista 2017-04-24 18:05:14 CEST
Remember to solve problem Rigol MSO1104Z
Comment 7 Giorgio Evangelista 2017-05-03 15:14:13 CEST
Serial analisys can not be performed on analogue channels.
Can you add it?
Comment 8 Martin Ling 2017-05-09 19:54:39 CEST
OK, I now have this scope on the desk. Testing with current git master for everything, using:

$ sigrok-cli -l 5 -d rigol-ds:conn=vxi/10.38.38.133 --frames 1

I get inconsistent results. Sometimes I get a successful readout, sometimes I get "Device read failed" with error 15, just after the ":WAV:DATA?" command.

I don't see any sign of the 'co' string.

Slightly different firmware though - this unit has 00.04.02.SP4.
Comment 9 Martin Ling 2017-05-09 19:55:24 CEST
Created attachment 296 [details]
Log on successful readout.
Comment 10 Martin Ling 2017-05-09 19:55:51 CEST
Created attachment 297 [details]
Log on failure.
Comment 11 Soeren Apel 2017-05-09 20:42:36 CEST
It may be that the difference between you and the bug reporter is that the bug reporter used the tcp-ip transport while you use vxi. Just a thought.
Comment 12 Martin Ling 2017-05-10 00:07:03 CEST
*** Bug 679 has been marked as a duplicate of this bug. ***
Comment 13 Martin Ling 2017-05-10 00:09:20 CEST
Yes, it looks like you're right. With tcp-raw on port 5555 I get the same result as originally reported.

I've also noticed that this issue was already reported as bug #679. Although it came first I'm marking that one as the duplicate, to keep the ongoing discussion on this bug.
Comment 14 Martin Ling 2017-05-10 00:23:53 CEST
It looks like there is a timing aspect to this problem.

Just using netcat talking to port 5555, I can type the commands:

:WAV:START 1
:WAV:STOP 1200
:WAV:DATA?

and get a valid block returned.

If I paste those three lines into the session however, I get the 'command error' message. I can paste other sequences of commands without issue.

I think the problem is occuring because the scope firmware hasn't yet finished processing the :WAV:STOP 1200 command when the :WAV:DATA? is sent.

Since the :WAV:START and :WAV:STOP commands don't return a response, there's nothing for the driver to wait for to provide flow control.

We should be able to solve this by having the driver send some harmless query and wait for a response, to ensure that the previous command has been fully processed.
Comment 16 Martin Ling 2017-05-10 01:46:02 CEST
Created attachment 299 [details]
Successful log after fix (VXI)
Comment 17 Martin Ling 2017-05-10 01:46:29 CEST
Created attachment 300 [details]
Successful log after fix (TCP)
Comment 18 Giorgio Evangelista 2017-05-10 08:49:56 CEST
Please, can you add serial analysis even on analogue channels?
Comment 19 Uwe Hermann 2017-05-10 15:48:25 CEST
Fixed in ef7fb1abffad411c1bf20099228e4d23db402a81, thanks a lot!

Giorgio, being able to run protocol decoders on analog channels (directly or via conversion to logic values) is planned / work in progress, but it's unrelated to this issue.
Comment 20 Martin Ling 2017-05-10 18:34:39 CEST
*** Bug 765 has been marked as a duplicate of this bug. ***
Comment 21 Giorgio Evangelista 2017-05-11 09:24:09 CEST
Link at patch are sources.
Can i find windows compiled program ?
Comment 22 Soeren Apel 2017-05-11 10:26:04 CEST
The patch was committed to the main repo > 24 hours ago, so the nightly build contains it. Simply download the Windows build from the sigrok page and you'll have it.
Comment 23 Giorgio Evangelista 2017-05-11 11:57:40 CEST
Nothing appear, I re try tomorrow.