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: Burkhard Kolb <[email protected]>
To: Tito Körner <[email protected]>
Cc: tech-talk Mailing List <[email protected]>
Date: Wed, 28 Aug 2013 14:55:13 +0200
Hi Tito,
the correct command would be
var streamDebug=1

Do I understand it right that you get the values for 8 channels with one read?
You would need to include these responses and sort them into different records by specifying
the record names in the protocol.

Burkhard
--
Dr. Burkhard Kolb
Tel +49 6159 712667
GSI Helmholtzzentrum für Schwerionenforschung GmbH
Planckstraße 1 | D-64291 Darmstadt | www.gsi.de

Gesellschaft mit beschränkter Haftung
Sitz der Gesellschaft: Darmstadt
Handelsregister: Amtsgericht Darmstadt, HRB 1528

Geschäftsführung: Professor Dr. Dr. h.c. mult. Horst Stöcker, Peter Hassenbach

Vorsitzende des Aufsichtsrates: Dr. Beatrix Vierkorn-Rudolph
Stellvertreter: Ministerialdirigent Dr. Rolf Bernhardt




Am 28.08.2013 um 14:38 schrieb Tito Körner:

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]>
Hello Tito,

Which asyn version are you using?

Dirk


On 26.08.2013 17: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





Replies:
RE: StreamDevice communication problems Mark Rivers
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 Tito Körner
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 Tito Körner
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 
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 ·