On Sun, Jan 11, 2015 at 06:24:11PM -0800, Tymm Twillman wrote:
> (re-sending as I think original might have gotten lost during sourceforge
> outage a couple of days ago — apologies if it shows up as a duplicate)
>
> Hi,
>
> I just started playing with Sigrok & am pretty excited about it :)
>
> I've been trying to get data from my Rigol DS1204b over ethernet. (The
> DS1204B is a 4- channel, 200Mhz scope in the DS1000 line with LXI support),
> from an OSX 10.9 machine.
Great :-)
> Seems like there are a few places that need some help in order to make this
> work. I just started poking at the code last night, so still pretty green on
> a lot of the ways things are organized & done, but think I've got at least
> initial stabs at some of the issues...
>
>
> Getting DS1204b recognized by ligsigrok (easy part):
>
> diff --git a/src/hardware/rigol-ds/api.c b/src/hardware/rigol-ds/api.c
> index 1c2a2ba..8ef3583 100644
> --- a/src/hardware/rigol-ds/api.c
> +++ b/src/hardware/rigol-ds/api.c
> @@ -215,6 +215,7 @@ static const struct rigol_ds_model supported_models[] = {
> {SERIES(DS1000), "DS1052D", {5, 1000000000}, 2, true},
> {SERIES(DS1000), "DS1102D", {2, 1000000000}, 2, true},
> {SERIES(DS1000), "DS1152D", {2, 1000000000}, 2, true},
> + {SERIES(DS1000), "DS1204B", {1, 1000000000}, 4, false},
> {SERIES(DS2000), "DS2072", {5, 1000000000}, 2, false},
> {SERIES(DS2000), "DS2102", {5, 1000000000}, 2, false},
> {SERIES(DS2000), "DS2202", {2, 1000000000}, 2, false},
That's a pretty obvious one.
You should take the opportunity to add the DS1104B and DS1074B at the
same time, and then send a git formatted patch (with commit message and
author), or just push it to a github account or similiar.
This would certainly be merged into mainline.
> Getting the SCPI VXI stuff to work seems to have a couple bigger issues...
>
> First one I ran into is that scpi_vxi_send() appends a CR/NL to the command.
> The DS1204b doesn't like that -- I haven't been able to tell whether (like
> with some other transports) there are assorted types of message terminators (
> CR, CR/NL, NL, hardware EOI ) that different hardware supports, or whether CR
> is not allowed by spec but some hardware will just ignore it, or whether it's
> actually not ok...
>
>
> Removing the CR gets things to work for this unit:
>
> diff --git a/src/scpi/scpi_vxi.c b/src/scpi/scpi_vxi.c
> index 62bf8c6..d7c34f0 100644
> --- a/src/scpi/scpi_vxi.c
> +++ b/src/scpi/scpi_vxi.c
>
> @@ -120,7 +123,7 @@ static int scpi_vxi_send(void *priv, const char *command)
> char *terminated_command;
> unsigned int len;
>
> - terminated_command = g_strdup_printf("%s\r\n", command);
> + terminated_command = g_strdup_printf("%s\n", command);
> len = strlen(terminated_command);
>
> write_parms.lid = vxi->link;
>
>
> Whether that is broadly fine or whether it's necessary to have a configurable
> message termination for different hardware, I'm not sure.
I havn't found a definitive answer in the VXI-11 specs but actually I
think that no CR and or LF character should be necessary.
The END indicator (DF_END) is used to indicate the "packets" separation.
IIRC I've initially added those line ending just in case some
instruments would need them.
Could you please check if removing both \r and \n also works for you ?
> Next piece is that sigrok-cli's run_session() will leave open the RPC
> connection used to find instruments by sr_driver_scan(), and then try to open
> another connection with sr_dev_open(); this second connection will fail since
> the first is still open.
It shouldn't leave the connection open...
> I've hacked around this by having ligsigrok's scpi_vxi_open() just return
> SR_OK if there's already an open client connection from the scan:
>
> diff --git a/src/scpi/scpi_vxi.c b/src/scpi/scpi_vxi.c
> index 62bf8c6..60b42c4 100644
> --- a/src/scpi/scpi_vxi.c
> +++ b/src/scpi/scpi_vxi.c
> @@ -65,7 +65,10 @@ static int scpi_vxi_open(void *priv)
> Create_LinkParms link_parms;
> Create_LinkResp *link_resp;
>
> + if (vxi->client != NULL) {
> + return SR_OK;
> + }
>
> vxi->client = clnt_create(vxi->address, DEVICE_CORE,
> DEVICE_CORE_VERSION
> if (vxi->client == NULL) {
> sr_err("Client creation failed for %s", vxi->address);
> return SR_ERR;
>
>
>
> but this seems a bit... ugly
Indeed, it is.
> wondering if someone familiar with the code might have some better thoughts?
I've just tested the VXI code-path with a Rigol DP832. scpi_vxi_open()
is indeed called twice, but the vxi->client is NULL the two times,
because scpi_vxi_close() is called in between.
So maybe this is the scpi_vxi_close() which is failing for you, and that
needs to be fixed.
Aurel
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
sigrok-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
