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