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

Subject: Re: About pvPut dafault behavior
From: <[email protected]>
To: "Benjamin Franksen" <[email protected]>
Cc: [email protected]
Date: Fri, 25 Feb 2011 23:01:32 +0900
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, [email protected] 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
> 
> 
program sncTest
long cnt;
assign cnt to "count";

ss ss1 {
    state init {
	when (delay(5)) {
	    printf("sncTest: Startup delay over\n");
	    cnt = 0;
	} state up
    }
    state up {
	when (delay(1.0)) {
	    cnt += 300;
/*
	    pvPut(cnt);
*/
	    pvPut(cnt, SYNC);

	    printf("sncTest: cnt = %d\n", cnt);
	} state up
	when (cnt > 10000) {
	    printf("sncTest: returning to init...\n");
	} state init
    }
}

Attachment: count.db
Description: Binary data


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

Navigate by Date:
Prev: Re: About pvPut dafault behavior Benjamin Franksen
Next: RE: About pvPut dafault behavior Mark Rivers
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  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: About pvPut dafault behavior Benjamin Franksen
Next: RE: About pvPut dafault behavior Mark Rivers
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  2021  2022  2023  2024 
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 ·