Created attachment 290 [details]
logo of acquire.
Pulse View 0.4.0 git 8b9056d
fw 00.04.03.SP2 i think last today 20/04/2017
PulseView send command, configure parameter, start acquirie, but nothing appairs on screen.
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.
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).
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.
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.
USB works properly.
Remember to solve problem Rigol MSO1104Z
Serial analisys can not be performed on analogue channels.
Can you add it?
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.
Created attachment 296 [details]
Log on successful readout.
Created attachment 297 [details]
Log on failure.
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.
*** Bug 679 has been marked as a duplicate of this bug. ***
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.
It looks like there is a timing aspect to this problem.
Just using netcat talking to port 5555, I can type the commands:
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.
Fix now available here:
Created attachment 299 [details]
Successful log after fix (VXI)
Created attachment 300 [details]
Successful log after fix (TCP)
Please, can you add serial analysis even on analogue channels?
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.
*** Bug 765 has been marked as a duplicate of this bug. ***
Link at patch are sources.
Can i find windows compiled program ?
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.
Nothing appear, I re try tomorrow.