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 <2013> 2014 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 <2013> 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
<== Date ==>		<== Thread ==>

Subject:	StreamDevice communication problems
From:	Tito Körner <[email protected]>
To:	[email protected]
Date:	Mon, 26 Aug 2013 17:33:33 +0200

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   kread_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; Re: StreamDevice communication problems Fabian S.; Re: StreamDevice communication problems Dirk Zimoch

Navigate by Date:: Prev: Re: epicsThread Dirk Zimoch; Next: RE: ICALEPCS Agenda - Emmanuel Mayssat; Index: 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 <2013> 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
Navigate by Thread:: Prev: Re: Delay within asyn driver (was: epicsThread) Vikram Bhagat; 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 <2013> 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024

ANJ, 20 Apr 2015

· Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System