Stuart,
I have a vague recollection that I ran into the same problem while
working with the Fluke 45. As you point out, by default the meter will
echo back the command it was sent (along with a prompt character if
memory serves) but Sigrok expects raw data. On the other hand, humans
like to see what they are typing which might be why Fluke decided on
that as the default setting. It is therefore necessarily to first turn
off echo on the Fluke 45 prior to communicating with Sigrok. My
recollection is that this problem occurs only when communicating over
serial and does not affect GPIB. If I still had my Fluke 45 I would have
done some tests, but as it is, I can only apologize for not thinking of
this sooner. I agree that the information ought to be added to the Wiki
so as to help anyone encountering the problem in the future. In the
meantime I have also added it to my own notes in case it arises again.
Thank you for your persistence and reporting back your findings.
stuart wrote on 03/06/2021 04:37:
Hi Gerhard,(and Christo)...
I figured it out. I'm running Linux so I can run sigrok w/STRACE. I
found STRACE and sigrok's loglevel=5 are the same. Both produced too
much data. But I did see what looked like communication and what
looked like many communication failures. I started looking through
the fluke 45 code. Noticed a compiled out "echo" detection code
segment (because it didn't work well?). Going on, I repeated the log
test at level 4. Now I could clearly see the DMM was echoing the
command causing sigrok to get confused. I can change echo from the
DMM's front panel. Now sigrok-cli is reporting values seen on the
DMM. I found I had to drop the baud rate to 1200 from 9600 to get
dependable operation.
P1: -0.01 mV DC
P1: -0.01 mV DC AUTO
P1: -0.02 mV DC
P1: -0.03 mV DC AUTO
P1: -0.03 mV DC AUTO
P1: -0.03 mV DC
P1: -0.02 mV DC AUTO
P1: -0.02 mV DC
P1: -0.02 mV DC
-thanks!
On 6/2/21 11:17 AM, Gerhard Sittig wrote:
On Tue, 2021-06-01 at 07:20 -0500, stuart wrote:
Hi Christo,
Well, this is getting interesting:
./sigrok-cli --driver
fluke-45:conn=/dev/ttyUSB0:serialcomm=9600/8n1 --scan
The following devices were found:
FLUKE [S/N: 6123456] with 2 channels: P1 P2
And turning on logging and setting it to 5 have pushed out and
endless stream of events. I'll look at this in more detail later,
but after failing a transaction where sigrok sent "*IDN?" closing
and re-opening the ttyUSB0 port, sigrok endlessly sends out
"FUNC1?", "AUTO?", "FUNC2" & "AUTO?". The repeats these 4 commands
endlessly.
You are assuming. Don't do that. _Show_ the output that you got,
so that others can reason about it. Or keep the information to
yourself, and consult the driver source at your site for your
amusement. The driver is small, and easy to read if you follow
the code paths starting from the api.c source file.
Here is why I think your interpretation is incorrect: If the
early scan had failed, then the acquisition had not started.
Because the identification succeeded, the acquisition gets
initiated. That's why the meter's current mode is queried. No
measurement value is taken because the meter's current function
could not get identified. That's why seeing the responses is so
important if you want to receive a helpful answer.
If the textual presentation of the SCPI communication is not
enlightening, you may have to sniff the serial traffic to get the
raw content. The driver does hard string comparisons. Control
characters or unexpected whitespace could interfere while the
issue might go unnoticed, depending on how the logging is done.
Is unusual end-of-line involved which affects the MQ detection?
Do you have other cables that you can try? Would not be the first
time that individual USB to UART adapters get in the way, while
others work fine. Is the communication 8bit clean, or is some
ASCII plus parity scheme involved? Some USB "cables" are terrible
in this respect (seen with cheap handheld meters).
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
--
John.
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
