Hi,
Since your application is so much like a gateway.
Checking the gateway source (gateServer.cc) might help.
void gateServer::mainLoop(void)
{
int not_done=1;
// KE: ca_poll should be called every 100 ms
// fdManager::process can block in select for delay time
// so delay must be less than 100 ms to insure ca_poll gets called
// if delay = 0.0 select will not block)
double delay=.010; // (10 ms)
...
while (not_done) {
...
fileDescriptorManager.process(0.01);
...
ca_poll();
...
}
...
}
On the other hand, if preemptive is enabled on caClient code, this delay is no more critical.
Your previous attempt failed might be that in caClient callback, the value is overwritten.
Instead casPV::postEvent should be called.
That is just my speculation. Wait for core developers' comments.
Best
Xiaoqiang
On Feb 26, 2013, at 1:27 AM, [email protected] wrote:
> Hi,
>
> I was wondering where I might be able to find more information on
> fileDescriptorManager.process. I am using this command as illustrated in
> the examples to process events for a portable channel access server. Is
> there a way to do this without calling it periodically? I seem to be
> running into trouble doing this, because when I call it in a loop with
> ca_poll, (or a usleep of more than 100000) it does not appear to be called
> often enough and caget will time out trying to connect to channels in the
> pcas.
>
> Thank you,
> Patrick
>
>> Hi Xiaoqiang,
>>
>> Thank you for your response. I think it turns out that the problem was
>> that I actually had preemptive callback enabled and I should not have. I
>> think with preemptive callback enabled, the callback functions were being
>> run while the fileDescriptorManager.process was processing. Now they only
>> run when I call ca_poll or ca_pend_event, which I can separate from
>> fileDescriptorManager.process.
>>
>> -Patrick
>>
>>>
>>> Hi,
>>>
>>> It is difficult to say anything without looking at your source.
>>> But one thing come to my mind is, you are using
>>> fileDescriptorManager.process to poll for updates.
>>> It would be good to test again using preemptive callback in caCleint
>>> code.
>>> Check here for more infos.
>>> http://www.aps.anl.gov/epics/base/R3-14/12-docs/CAref.html#Thread
>>>
>>> On the other hand, if you are not bound to use C++,
>>> one can write such an application in Python, like I just did, in 3
>>> minutes, 33 lines of code.
>>>
>>>
>>>
>>>
>>> It uses module PCASpy[1] for PCAS server programming.
>>> I use module CaChannel[2] for caClient, but other modules[3] should work
>>> the same.
>>>
>>> Best
>>> Xiaoqiang
>>>
>>> [1] https://code.google.com/p/pcaspy/
>>> [2]
>>> http://controls.web.psi.ch/cgi-bin/twiki/view/Main/NewPythonEpicsInterface
>>> [3] http://www.aps.anl.gov/epics/extensions/index.php
>>>
>>> On Feb 22, 2013, at 8:00 PM, [email protected] wrote:
>>>
>>>> Hi,
>>>>
>>>> I am trying to add a portable channel access server to a channel access
>>>> client, similar to the EPICS gateway I believe. The values for the
>>>> process
>>>> variables that are created by the PCAS are written to from the
>>>> connection
>>>> and event handler callbacks for the caClient. The problem I think I am
>>>> running into, is that when I call fileDescriptorManager.process, these
>>>> callbacks get called similar to as if a ca_pend_event was called. So
>>>> after
>>>> the call to fileDescriptorManager.process and before it completes, new
>>>> values are being written to the PCAS process variables, and postEvent
>>>> is
>>>> being called for these changed values. This leads to funny behavior
>>>> where
>>>> the same value is posted for a PCAS channel multiple times in a row (as
>>>> seen with camonitor). For example, it should post 1, 2, 3 but posts 3,
>>>> 3,
>>>> 3 instead, all with the same time stamps. Is there a way around this?
>>>>
>>>> I also ran a test, with just the PCAS and leaving out the caClient. I
>>>> wrote to a PCAS process variable continuously with increasing values in
>>>> one thread and called fileDescriptorManager.process continuously in
>>>> another thread. This gave me similar results, that is the same value
>>>> was
>>>> posted multiple times in a row for stretches of time before it
>>>> increased.
>>>> I was not surprised that I got funny behavior doing this, but the fact
>>>> that it was similar to the caClient helped me diagnose what may be
>>>> happening.
>>>>
>>>> Also, what is the usual way to update the values for the PCAS process
>>>> variables from the application itself (i.e. not with a caput)? I added
>>>> a
>>>> public function to the PCAS Server that calls functions in the
>>>> appropriate
>>>> PV instance to write a value and call the postEvent function. Is this
>>>> typical? If so, I am guessing that I should also check in this function
>>>> to
>>>> see if the new value will actually be different before writing it, so
>>>> that
>>>> postEvent is not called when the value has not really changed? Or is
>>>> there
>>>> another way to do that?
>>>>
>>>> Thank you for your time,
>>>> Patrick
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
- References:
- caClient with PCAS pthomas
- Re: caClient with PCAS Xiaoqiang Wang
- Re: caClient with PCAS pthomas
- Re: caClient with PCAS pthomas
- Navigate by Date:
- Prev:
CA client on iOS? Pavel Maslov
- Next:
Re: CA client on iOS? Xiaoqiang Wang
- 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: caClient with PCAS pthomas
- Next:
Re: caClient with PCAS 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
|