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  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: About pvPut dafault behavior
From: <jun-ichi.odagiri@kek.jp>
To: "Mark Rivers" <rivers@cars.uchicago.edu>
Cc: tech-talk@aps.anl.gov
Date: Mon, 28 Feb 2011 08:24:28 +0900
> Is the other IOC behind a PV gateway?

No. All IOCs are on a single network and no PV gateway is included.

Jun-ichi


----- Original Message -----
> Is the other IOC behind a PV gateway?
> 
> 
> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov on behalf of jun-ichi.odagiri@kek.
jp
> Sent: Fri 2/25/2011 8:01 AM
> To: Benjamin Franksen
> Cc: tech-talk@aps.anl.gov
> Subject: Re: About pvPut dafault behavior
>  
> Dear Ben;
> 
> I'd like to thank you for your crystal clear answer.
> I understood the differences between no-option case, SYNC-option
> case and ASYNC-option case.
> 
> Now, I have to bring up a problem I'm facing on pvPut.
> 
> The attached files are a simple .stt program that repeatedly puts
> a value into a PV, and a .db file including the PV (a soft longout
> record with its all fields initialized with their default values).
> 
> If the .stt progrm runs on an IOC where the soft record resides,
> it works just fine for all of the following three cases:
> 
> 1. pvPut(var)
> 2. pvPut(var, SYNC)
> 3. pvPut(var, ASYNC).
> 
> However, if the .stt program runs on an IOC to put a value into
> the soft record placed on another IOC, only pvPut(var) works fine. 
> 
> pvPut(var, SYNC) and pvPut(var, ASYNC) behave strangely. It's very
> hard to explain in short sentences since it varies from case to
> case.
> 
> For example, the value actually put into the record is shortened
> to a multiple of 256 that is mostly close to the value the .stt
> program tried to put... or ... always zero...
> 
> At any rate, pvPut(var, SYNC) and pvPut(var, ASYNC) shows exactly
> the same strange befavior in the situation.
> 
> I found that "caput -c" also does not work in that situation. So,
> I guess this problem might be related with Channel Access as the
> underlying message system. 
> 
> I appreciate it if you could give me any suggestions on what I
> can try to solve the problem.
> 
> Thanks a lot in advance.
> 
> Jun-ichi
> 
> 
> ----- Original Message -----
> > On Friday, February 25, 2011, jun-ichi.odagiri@kek.jp wrote:
> > > Dear all;
> > >
> > > I'm looking into the following site to check if pvPut of seq-2.0.
11
> > > works synchronously or asynchronously (with NO compiler option and
> > > NO explicit SYNC/ASYNC option, just a pvPut(pvname) call).
> > >
> > > http://www-csr.bessy.de/control/SoftDist/sequencer/Manual.html
> > >
> > > In "Notes on Release 2.0 (Synchronous/asynchronous override on 
gets 
> and
> > > puts)",
> > >
> > > it says as follwos:
> > >
> > > "pvGet and pvPut both accept an optional SYNC or ASYNC argument 
that,
> > > for pvGet, overrides the default as set using the -a option and, 
for
> > > pvPut, overrides the default synchronous behavior."
> > >
> > > So, I thought pvPut(pvname) works synchronously. However, it say 
in
> > > "Asynchronous Use of pvPut" as follows:
> > >
> > > "Normally the pvPut operation completes asynchronously. In the 
past 
> it
> > > has been the responsibility of the programmer to ensure that the
> > > operation completed (typically by monitoring other variables). 
> However,
> > > the function pvPutComplete can now be used for this."
> > >
> > > So, I'm getting confused.
> > >
> > > Does pvPut(pvname) work synchronously, or asynchronously by 
default?
> > >
> > > Sorry in advance if I'm bothering you all due to my poor ability 
in
> > > reading English.
> > 
> > Not at all. You are pointing out a bug in the release notes: the 
first
> > paragraph is wrong as stated; I am going to fix that. The default 
> behaviour
> > for pvPut is definitely asynchronous, or, to put it more precisely, 
> pvPut
> > sends the request off to the PV and does *not* wait for any 
> confirmation (in
> > fact never requests it in the first place). In short: it is a fire 
and
> > forget operation.
> > 
> > It may be clarifying to point out that for the pvPut operation, the
> > synchronous/asynchronous distinction is not enough to completely 
> describe
> > the behaviour. There are actually three variants, one synchronous 
and 
> two
> > asynchronous:
> > 
> > * pvPut(var): fire and forget, no completion message is requested
> > * pvPut(var,SYNC): request completion message, block state set (
thread)
> >   until it arrives (or timeout occurs)
> > * pvPut(var,ASYNC): request completion message but do not block 
state
> >   set; instead user code can call pvPutComplete to find out if 
> completion
> >   message has arrived
> > 
> > Note that pvPut is *not* affected by the +a or -a options given to 
the 
> snc
> > compiler. These options only change the default behaviour of pvGet.
> > 
> > You can find a more detailed description of the pvPut and pvGet (and 
> all
> > other) commands in the online SNL reference at
> > 
> > http://www-csr.bessy.de/control/SoftDist/sequencer/Reference.html
> > 
> > HTH
> > Ben
> > 
> > ________________________________
> > 
> > Helmholtz-Zentrum Berlin für Materialien und Energie GmbH
> > 
> > Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher 
> Forschungszentren e.V
> > 
> > Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, 
> stv. Vorsitzende Dr. Beatrix Vierkorn- Rudolph
> > Geschäftsführer: Prof. Dr. Anke Rita Kaysser-Pyzalla, Prof. Dr. Dr. 
h.
> c. Wolfgang Eberhardt, Dr. Ulrich Breuer
> > 
> > Sitz Berlin, AG Charlottenburg, 89 HRB 5583
> > 
> > Postadresse:
> > Hahn-Meitner-Platz 1
> > D-14109 Berlin
> > 
> > http://www.helmholtz-berlin.de
> > 
> > 
> 
> 


References:
About pvPut dafault behavior jun-ichi.odagiri
Re: About pvPut dafault behavior Benjamin Franksen
Re: About pvPut dafault behavior jun-ichi.odagiri
RE: About pvPut dafault behavior Mark Rivers

Navigate by Date:
Prev: Re: About pvPut dafault behavior J. Lewis Muir
Next: Re: About pvPut dafault behavior jun-ichi.odagiri
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: RE: About pvPut dafault behavior Mark Rivers
Next: Re: About pvPut dafault behavior benjamin . franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·