Experimental Physics and Industrial Control System
On 10/12/12 11:38 AM, Andrew Johnson wrote:
> Hi Lewis,
>
> On 2012-10-12 J. Lewis Muir wrote:
>> Yes, inserting the delay makes the problem go away.
>>
>> But this seems like a bug to me. Isn't the IOC supposed to be
>> in the "running" state after iocInit completes? I would expect
>> this to mean that any threads related to CA link processing have
>> completed starting and are in a state ready to service CA
>> requests. I would not expect to have to insert epicsThreadSleep
>> calls after iocInit to make things work.
>
> The threads involved have all started and are processing, but connecting CA
> channels is fundamentally an asynchronous process. You wouldn't want us to
> delay the completion of iocInit until all CA links in the database are
> connected up; the database has no idea whether a CA link points to a local or
> remote PV, it treats them all identically.
Hi, Andrew.
This is where my naivety about how the CA links work in the IOC
has caused me look at things in a different way. To me it seems
crazy that I would have to worry about a CA link not connecting
when it is a local PV.
Anyway, no, I wouldn't want the iocInit to wait until all CA
links in the database are connected if those links can be to PVs
that are not local and may not exist. I didn't know they all
get connected at start-up. I thought they got connected as
needed. So, for this calcout problem, I would have expected the
calcout record (or some built-in EPICS Base facility) to
establish the CA connection if needed before doing the write.
Or, whatever, the calcout record could command a write using an
EPICS Base facility, and that facility would ensure the CA link
is connected before doing the write.
> I may have removed an epicsThreadSleep() from the iocInit code in the past; I
> could put one back in so you don't have to provide one yourself, but that
> would unnecessarily delay IOCs that don't actually need to wait.
Agreed.
> In your case the delay is really a requirement before doing the dbpf because
> you don't want to process that calcout record until the output link has
> connected. Maybe a more robust alternative might be to provide a command
> which waits for a named link field to have connected, so instead of a delay
> you'd use something like
> dbcaWaitConnected "ioc23:PresetHistoryAdd.OUT"
> but I don't know how easy it would be to implement that.
That would be nice--way better than a delay.
Even better for me would be a dbcaWaitAllLocalConnected that
would wait for all local PVs to be connected. I'd put that
after iocInit in every single one of my IOCs. I can't even
think of a case where I wouldn't do that. Is there a case where
one wouldn't want to do that? Of course, if there is no case
where one wouldn't want to do that, then it starts to seem like
it should be in iocInit.
>> Also, I don't know exactly how the pause and run stuff works,
>> but if the IOC is paused and then run again at a later time,
>> will the same problem occur? If so, I guess I'd have to add a
>> delay on coming out of the paused state to ensure my record will
>> process correctly. That would be pretty lame.
>
> Pausing won't help, that stops the CA server side of the IOC so requires
> reconnecting. It was added to solve a completely different problem.
I understand that it was added for a redundancy solution. I
wasn't suggesting that pausing would help; I was wondering if
coming out of a pause would be the same as what happens right
after iocInit completes. If it is, then there could be cases
right after the IOC came out of a pause where a record using CA
links to local PVs would fail because the CA links have not been
established yet.
Thanks,
Lewis
- Replies:
- Re: Calcout using CA output link sometimes gets INVALID severity Andrew Johnson
- References:
- Calcout using CA output link sometimes gets INVALID severity J. Lewis Muir
- Re: Calcout using CA output link sometimes gets INVALID severity Andrew Johnson
- Re: Calcout using CA output link sometimes gets INVALID severity J. Lewis Muir
- Re: Calcout using CA output link sometimes gets INVALID severity Andrew Johnson
- Navigate by Date:
- Prev:
Re: Calcout using CA output link sometimes gets INVALID severity Andrew Johnson
- Next:
Re: Calcout using CA output link sometimes gets INVALID severity J. Lewis Muir
- 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: Calcout using CA output link sometimes gets INVALID severity Andrew Johnson
- Next:
Re: Calcout using CA output link sometimes gets INVALID severity Andrew Johnson
- 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