> 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: [email protected] on behalf of jun-ichi.odagiri@kek.
jp
> Sent: Fri 2/25/2011 8:01 AM
> To: Benjamin Franksen
> Cc: [email protected]
> 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, [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
> >
> >
>
>
- 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
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- 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
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|