RE: StreamDevice communication problems

[Mark Rivers <rivers@cars.uchicago.edu>]

If this is a soft IOC the command is not "streamDebug=1", it is:

var streamDebug 1

I believe that streamDevice does lock the port while executing a protocol, so you should not be getting garbled input.

I recommend you turn on debugging at the drvAsynIPPort in asyn:

In your startup script put:

asynSetTraceIOMask "myIPPort" 0 2
asynSetTraceMask "myIPPort" 0 9

You will then see all messages sent and received from the device without needing to use Wireshark.

Mark

________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Tito Körner [tito.koerner@gmail.com]
Sent: Wednesday, August 28, 2013 7:38 AM
To: Dirk Zimoch
Cc: tech-talk@aps.anl.gov
Subject: Re: StreamDevice communication problems

Hi everyone,

Thanks for the replies.

@ Mark Rivers: This FLNK field is just a relict from my very first attempts. This FLNK should keep the record going even though there is a mismatch. Using the SCAN field it is pretty unnecessary I admit, but it shouldn't be responsible for my problem - however I deleted the line now.

@ Fabian S.: I tried to enter "streamDebug=1" at the epics console but I got the message "Command streamDebug=1 not found".
I don't really thinkg the output really appears in the input. When I take a look at the packages sent via telnet it looks like the out commands from the read_volt record are sent in between the out and in command from the set_volt record.

@ Dirk Zimoch: I'm using asyn4-21.

As I see it my problem is that the device is not locked by a protocole once the first out command is sent (or may I just don't understand locking correctly) and that the response to the out command of read_volt is not unique for a specific channel (like it for example would be when the level and channel number would be part of the output - then I could parse these values.
I can't change the strings coming from the box unfortunatelly. So is there a away to actually check how and if a protocol really locks a device? Or is there the possibility to somehow manually lock the box - with a field for example.
I'm also thinking of using the DISA und DISV field. My basic idea would be to stop the read_volt record via first writing to the DISA/DISV field in the read_volt record so it no longer processes, then set the voltage and restart the read_volt record afterwards. I guess it may possible somehow.

Tito



2013/8/27 Dirk Zimoch <dirk.zimoch@psi.ch<mailto:dirk.zimoch@psi.ch>>
Hello Tito,

Which asyn version are you using?

Dirk


On 26.08.2013 17<tel:26.08.2013%2017>:33, Tito Körner wrote:
Hello,

I am using Streamdevice (
http://epics.web.psi.ch/software/streamdevice/doc/index.html) to control a
high voltage box. The box has 5 levels with 8 channels each, so it controls
40 channels. The boxes receive commands and send output via telnet.
Currently I only have two records - one for reading one for writing values.
To access all channels I use a template. The problem is whenever I give one
channel the command to change the value - the entire traffic gets mixed up:

My .db looks like this:

record (stringout, "$(P):BOX:$(BOXNO):$(LEVELNO):$(CHANNELNO):set_volt")
{
     field (DTYP, "stream")
     field (OUT,  "@$(PROTO) set_voltage($(LEVELNO),$(CHANNELNO))
termBox$(BOXNO)")
}

record (ai, "$(P):BOX:$(BOXNO):$(LEVELNO):$(CHANNELNO):read_volt")
{
     field (DTYP, "stream")
     field (INP, "@$(PROTO) read_voltage($(LEVELNO),$(CHANNELNO))
termBox$(BOXNO)")
     field (SCAN, "1 second")
     field (FLNK, "$(P):BOX:$(BOXNO):$(LEVELNO):$(CHANNELNO):read_volt")
     field (PACT, "")
     field (STAT, "")
     field (SEVR, "")
     field (VAL, "")
}

My protocol file looks like this:

terminator = CR LF;
LockTimeout = 10000;

read_voltage {
     out "read_adc floats_csv \$1 \$2";
     in "%*d.%*d.%*d %*d:%*d:%*d,%f";
     @mismatch{out "read_adc floats_csv \$1 \$2";  in "%*d.%*d.%*d
%*d:%*d:%*d,%f";}
}

set_voltage {
     out "SetVpmF \$1 \$2 %s";
     in "DAC: \$1   CH: \$2   U: %*f  Uk: %*f";
     in "Nachregelung aktiv!";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
}

I created a python script that prints all values to the terminal. As long
as only the read record is activ everything works out. But when I use
another terminal to set a voltage like: 'caput
CB:HV:BOX:19:0:0:1480:set_volt' the voltage values start to  'jump around'.
I monitored the network traffic with wireshark and saw this:

read_adc floats_csv 2 5
01.01.1900 04:23:55,1345.003
read_adc floats_csv 2 6
01.01.1900 04:23:55,1345.123
read_adc floats_csv 2 7
01.01.1900 04:23:55,1345.156
read_adc floats_csv 3 0
01.01.1900 04:23:56,1346.075
read_adc floats_csv 3 1
01.01.1900 04:23:56,1343.827
read_adc floats_csv 3 2
01.01.1900 04:23:56,1376.977
read_adc floats_csv 3 3
01.01.1900 04:23:56,1346.537
read_adc floats_csv 3 4
01.01.1900 04:23:56,1341.462
read_adc floats_csv 3 5
01.01.1900 04:23:56,1368.079
SetVpmF 0 0 1480
*read_adc floats_csv 3 6 *

DAC: 0   CH: 0   U: 1480.000  Uk: 1584.800
Nachregelung aktiv!
Messwert: 1479.545   DAC: 0   CH: 0   Value: 1480.350   korrigiert:
1585.165
Messwert: 1479.941   DAC: 0   CH: 0   Value: 1480.395   korrigiert:
1585.212
Messwert: 1479.935   DAC: 0   CH: 0   Value: 1480.445   korrigiert:
1585.264
Messwert: 1480.045   DAC: 0   CH: 0   Value: 1480.410   korrigiert:
1585.228
Messwert: 1480.046   DAC: 0   CH: 0   Value: 1480.375   korrigiert:
1585.191
Messwert: 1479.941   DAC: 0   CH: 0   Value: 1480.420   k*read_adc
floats_csv 3 6 *

orrigiert: 1585.238
Messwert: 1480.052   DAC: 0   CH: 0   Value: 1480.379   korrigiert:
1585.196
Messwert: 1479.963   DAC: 0   CH: 0   Value: 1480.408   korrigiert:
1585.226
Messwert: 1480.063   DAC: 0   CH: 0   Value: 1480.359   korrigiert:
1585.175
Messwert: 1479.963   DAC: 0   CH: 0   Value: 1480.388   korrigiert:
1585.205
read_adc floats_csv 3 7
01.01.1900 04:23:59,1344.063
read_adc floats_csv 4 0
01.01.1900 04:23:59,1344.070
read_adc floats_csv 4 1
01.01.1900 04:23:59,1346.169
read_adc floats_csv 4 2
01.01.1900 04:23:59,1357.607
read_adc floats_csv 0 0
01.01.1900 04:24:00,1352.217
read_adc floats_csv 0 1
01.01.1900 04:24:00,1340.962

As you can see (marked bold) in between the command 'SetVpmF 0 0 1480' and
the response from the box there are two out commands from the read_volt
record. The problem now is - the first response from the box after the
response to the set_voltage command is '01.01.1900 04:23:59,1344.06. This
is actually the voltage value belonging to the command 'read_adc floats_csv
3 6'. But because the read_volt record sent this command in between the
command and response of  the set_volt record, Epics 'thinks' this is the
value for 3 7. At the StreamDevice website it says that a protocols first
out command locks the device for exclusive access until the protocol is
finished. But here this does not seem to work because obviously the
read_volt record sends the out command of its protocol while the protocol
called in the set_volt record is active. I hope someone can help me to
figure out what's going wrong and how to fix it.

Regards,
Tito Koerner