Experimental Physics and
Industrial Control System

Hello Dirk,

As you suggested, the device actually echoes the command ...
So now that this reply is consumed, periodic reads are no more disturbed !

thanx indeed

Le 16/10/2014 17:23, Dirk Zimoch a écrit :

Hello Christophe,

The reason seems to be that the device sends an acknowledge after setting DCP, or simply echos the command (when designed for a serial console). So you get the reply from your setPwr protocol and don't consume it.

StreamDevice tries its best to avoid this situation. It discards all "old" input at the beginning of a new out command. But it cannot discard input that is still in the device. So this is what happens:

You send: "DCP=1" and the record is finished.
Before you send "REM/" StreamDevice flushes the input.
The device echos "DCP=1"
You send "REM/"
You receive the "DCP=1"

To avoid this change the setPwr protocol:
setPwr{
         out "%{DCP=0|DCP=1}"; # or: out "DCP=%i"
         in  "DCP=%*i";
      }
Then the protocol waits for the echoed command and the next command starts with a clean interface.

Dirk



On 16.10.2014 10:07, haquin wrote:

Hi All,

I am using StreamDevice with Asyn TCP connection to control a power supply.
I have some periodic read (power ON/OFF or Ready/Fault or Local/distant)
  and commands (switch power ON/OFF or reset) can be send asynchronously.

My problem is that periodic reads are disturbed because they also
receives the strings of the asynchronous commands.
In such case the record goes temporarily into CALC INVALID state.

Following is the message I can have when I issue Power ON command (the
record reading the local/distant status is disturbed)
TCP_BPI TST-BPI:Ctrl: Input "DCP=1" mismatch after 0 bytes
TCP_BPI TST-BPI:Ctrl: got "DCP=1" where "REM/" was expected

How could I have the periodic read not being disturbed by asynchronous
commands ?

thanx in advance for your help.

here is an example of my records/protocol:

#####################################################
record(bi, "$(EQPT):Ctrl") {
   field(SCAN, "1 second")
   field(DTYP, "stream")
   field(INP, "@alimISrc_SerialProtocol.db getRem TCP_BPI")
   field(ZNAM, "LOCAL")
   field(ONAM, "DISTANT")
}

getRem{
   out "REM/";
   in "REM/%u";
}
#####################################################
record(bo, "$(EQPT):PwrCmdOut") {
   field(SCAN, "Passive")
   field(DTYP, "stream")
   field(OUT, "@alimISrc_SerialProtocol.db setPwr TCP_BPI")
   field(ZNAM, "OFF")
   field(ONAM, "ON")
}

setPwr{
         out "%{DCP=0|DCP=1}";
     }
#####################################################

--
Christophe Haquin
Control and Real Time systems Engineer

+33 231454661 office
+33 231454728 fax
SdA/GIM
GANIL
Bd Henri Becquerel BP 55027
14076 CAEN CEDEX5

begin:vcard
fn:Christophe Haquin
n:Haquin;Christophe
email;internet:[email protected]
tel;work:02 31 45 46 61
x-mozilla-html:FALSE
version:2.1
end:vcard

References:

StreamDevice "in" command disturbed by out command haquin

Re: StreamDevice "in" command disturbed by out command Dirk Zimoch

Navigate by Date:

Prev: RE: EPICS on vxWorks Amit Chauhan

Next: Re: csstudio RAP applications Kasemir, Kay

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: StreamDevice "in" command disturbed by out command Dirk Zimoch

Next: webopi -- http status 404 error Tom Smart

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