On 11/29/2017 02:44 PM, Ralph Lange wrote:
> This is one of those situations when a link type that atomically reads a
> dbState value might be worthwhile, and a better solution than using CA
> links. Actually why limit ourselves to just binary values, why not
> create a link type that provides atomic access to any shared storage
> (similar to the old global symbol support, but with proper thread
> protection)?
>
> We have a single simulation switch bo record per PLC, and it resides on
> the IOC connecting to the PLC.
> We only need CA links in SIML to not have all >10K records be in a
> single lock set.
Right, and by setting all your SIML inputs to read the same dbState
value they can read the binary value from the state without all the
added complexity of a CA link.
field(SIML, {state:simMode})
You would also have a bo record to set the simMode dbState value.
Next release maybe...
> I will prepare a merge proposal tomorrow.
Okay.
- Andrew
--
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon
- References:
- SIML type CA and PINI=YES issue Ralph Lange
- Re: SIML type CA and PINI=YES issue Ralph Lange
- Re: SIML type CA and PINI=YES issue Kasemir, Kay
- Re: SIML type CA and PINI=YES issue Ralph Lange
- Re: SIML type CA and PINI=YES issue Kasemir, Kay
- Re: SIML type CA and PINI=YES issue Andrew Johnson
- Re: SIML type CA and PINI=YES issue Ralph Lange
- Navigate by Date:
- Prev:
RE: EPICS 7.0.1-pre1 -- vxWorks 6.2 Mark Rivers
- Next:
RE: EPICS 7.0.1-pre1 -- vxWorks 6.2 Mark Rivers
- Index:
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: SIML type CA and PINI=YES issue Ralph Lange
- Next:
warnings about strict aliasing Dirk Zimoch
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
<2017>
2018
2019
2020
2021
2022
2023
2024
|