Re: Multiline input to drvAscii?

[Maren Purves <m.purves@jach.hawaii.edu>]

a while later, a (partial) solution:

I finally realaized that the device was sending
\n\r rather than what I expected \r\n.
First point taken.
Due to the fact that it echoes because drvAscii
doesn't allow (or I didn't figure out how) to send
strings without terminators, it sends more replies
back than you send commands in.

The solution to that part is is to eat all leading
carriage returns and/or line feeds, with a custom
read function (thanks Matt (Rippa), I used a
skeleton of your getTrimmedFrame that you wrote for
the Optomuxes).

That bit of the code looks like this:
    if (chr == '\n' && idx==0) continue;
    if (chr == '\r' && idx==0) continue;

It still left me with 2 more lines, both
of which were too long (the first line was
120 characters long but had a lot of letters,
parentheses and blanks in it which the data
line I'm after doesn't, so:
    if ( chr == ')' ) continue;
    if ( chr == '(' ) continue;
    if ( chr == '>' ) continue;
    if ( chr == ' ' ) continue;
    if ( isalpha(chr) ) continue;

(">" is the returned prompt)

which left me with a too long line consisting
of numbers, periods, commas, a % at the end,
another \n\r and the data that I'm trying to
get.

Getting rid of that took this:
    if (chr == '.' && idx==0) continue;
    if (chr == ',' && idx==0) continue;
    if (chr == '0' && idx==0) continue;
    if (chr == '1' && idx==0) continue;
    if (chr == '2' && idx==0) continue;
    if (chr == '3' && idx==0) continue;
    if (chr == '4' && idx==0) continue;
    if (chr == '5' && idx==0) continue;
    if (chr == '6' && idx==0) continue;
    if (chr == '7' && idx==0) continue;
    if (chr == '8' && idx==0) continue;

/* (there are no 9s in that string) */

/* eat the terminator after the '%' */
    if (chr == '\n' && prevchr=='%') continue;
    if (chr == '\r' && prevchr=='%') continue;

(and the implementation of a static prevchr).

Why between the drvAscii debug output and
the next record down it loses a few characters at the
end I havent gotten at yet, and I'm not sure I really
care (they contain the ambient temperature, pressure
and humidity which we monitor elsewhere).

But, this rather awkward to interface thing is giving
me data now (well, almost. I still have to chop its
return string up into numbers, but I'm as far as geting
the string into the gensub as well).

Don't know whether anybody wants to know at this
point, but it may come in handy to somebody at some
point.

(Allan, I never got the <n>T do anything for me in this case,
I presume because it (took me ages to realize) doesn't
send \r\n but \n\r., and the last line comes out several
seconds later)

Aloha,
Maren

On Tue, 1 Jun 2010, Maren Purves wrote:

> Hi all,
>
> I'm currently trying to not just talk to (that part was
> easy) but also get replies back from a device that responds
> in a somewhat awkward way.
>
> On an xterm it looks like this:
>
> The command is
> S
> (with no <cr> or <lf>)
>
> and the response is:
> Time,1 (0.5),2 (0.7),3 (1.0),4 (2.0),5 (3.0),6 (5.0),7 (7.0),8
> (10.0),Alarms,Flow(lpm),AT(C),BP(mmHg),RH(%)
> 176502,302,119,66,23,6,2,2,0,12,1.6,27.4,348.6,51
>
> where the first line (which ends in RH(%)) comes
> back immediately and the second line after a sampling
> period that can be specified.
>
> If I do the same from an IOC I get the following
> (with drvAscii debug output included but edited to
> reassemble the mixed up buffers):
>
> drvAscii(2) => S[ a]
> filename="../drvAscii.c" line number=4057
> S_errno_EINTR  : [/pty/dustm.M] lost sem - recovering
>
> filename="../drvAscii.c" line number=4074
> S_errno_EINTR  : [/pty/dustm.M] lost msg sync - discarding response
>
> filename="../drvAscii.c" line number=4074
> S_errno_EINTR  : [/pty/dustm.M] lost msg sync - discarding response
>
> filename="../drvAscii.c" line number=4074
> S_errno_EINTR  : [/pty/dustm.M] lost msg sync - discarding response
>
> filename="../drvAscii.c" line number=4074
> S_errno_EINTR  : [/pty/dustm.M] lost msg sync - discarding response
>
> filename="../drvAscii.c" line number=4074
> S_errno_EINTR  : [/pty/dustm.M] lost msg sync - discarding response
>
> filename="../drvAscii.c" line number=4074
> S_errno_EINTR  : [/pty/dustm.M] lost msg sync - discarding response
>
> filename="../drvAscii.c" line number=4074
> S_errno_EINTR  : [/pty/dustm.M] lost msg sync - discarding response
>
> drvAscii(5) <= >S [ d][ a]
> drvAscii(110) <=Time,1 (0.5),2 (0.7),3 (1.0),4 (2.0),5 (3.0),6 (5.0),7 
> (7.0),8 (10.0),Alarms,Flow(lpm),AT(C),BP(mmHg),RH(%)[ d][ a]
> drvAscii(3) <= [ d][ a]
> drvAscii(3) <= [ d][ a]
> drvAscii(51) <= >183771,213,72,28,7,2,1,1,1,12,1.6,28.6,343.2,45[ d][ a]
> drvAscii(2) => Q[ a]
> drvAscii(4) <= Q[ d][ a]
> drvAscii(4) <= >[ d][ a]
> drvAscii(3) <= [ d][ a]
>
> I tried the %nT (suggested by somebody in the office) format but never
> managed to get past the line that's too long.
>
> This is on EPICS 3.13.8 and I think we're using drvAscii 2.3.
>
>
> Thanks in advance,
> Maren