EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: StreamDevice communication problems
From: Mark Rivers <[email protected]>
To: Tito Körner <[email protected]>, Dirk Zimoch <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Wed, 28 Aug 2013 13:00:38 +0000
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: [email protected] [[email protected]] on behalf of Tito Körner [[email protected]]
Sent: Wednesday, August 28, 2013 7:38 AM
To: Dirk Zimoch
Cc: [email protected]
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 <[email protected]<mailto:[email protected]>>
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





References:
StreamDevice communication problems Tito Körner
Re: StreamDevice communication problems Dirk Zimoch
Re: StreamDevice communication problems Tito Körner

Navigate by Date:
Prev: Re: StreamDevice communication problems Burkhard Kolb
Next: RE: StreamDevice communication problems Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: StreamDevice communication problems Mark Rivers
Next: Re: StreamDevice communication problems Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 20 Apr 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·