EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: security rules and autosave
From: "Mooney, Tim M." <[email protected]>
To: Touchard Dominique <[email protected]>, "[email protected]" <[email protected]>
Date: Tue, 22 Jul 2014 18:32:20 +0000
More study.  Instead of setting PINI="YES", you could set STAT and SEVR to zero.

Evidently, the reason access-security doesn't get the right value at boot time for PVs used in its calculations,
is that it ignores monitors from PVs if the records hosting them are in alarm.  You can get the record out of
alarm by processing it, or by setting (in the database file) the alarm fields to non-alarm values.

Tim


From: [email protected] [[email protected]] on behalf of Mooney, Tim M. [[email protected]]
Sent: Tuesday, July 22, 2014 12:11 PM
To: Touchard Dominique; [email protected]
Subject: RE: security rules and autosave

I get that behavior for any value of a PV used in an access-security rule,
whether it was defined in the database or restored by autosave.  If I
set PINI to get the record processed at init time, it behaves as I think it
should.

record(bo,"$(P)LocalAccess") {
    field(DESC,"AS for Local PCs")
    field(DTYP,"Soft Channel")
    field(ZNAM,"Disabled")
    field(ONAM,"Enabled")
    field(ASG, "controlFields")
    field(PINI, "YES")
    field(UDF, "0")
}

Tim


From: [email protected] [[email protected]] on behalf of Touchard Dominique [[email protected]]
Sent: Tuesday, July 22, 2014 7:25 AM
To: [email protected]
Subject: security rules and autosave

Hi,

I need some advices on rules and autosave.

I configured a Linux IOC with following rules

================================================================
ASG(FAISCEAU) {

#Operation mode lock
  INPA(DEFAULT:OPState)

#BEAM characteristics lock
  INPB(FAISCEAU:WritePerm)

# We can always read PVs
  RULE(1,READ)

# BEAM Characteristcs could be changed by everyone in maintenance mode and BEAM characteristics unlocked
  RULE(1,WRITE) { CALC("A=0 && B=1") }

# BEAM Characteristcs could be changed only by operators in operation mode and BEAM characteristics unlocked
  RULE(1,WRITE) {
    UAG(operateurs)
    CALC("A=1 && B=1")
  }
}

==============================================================
DEFAULT:OPState could be 0:Maintenance 1:Operation
FAISCEAU:WritePerm could be 0:BEAMLocked 1:BEAMUnlocked

These rules work perfectly when values of DEFAULT:OPState and FAISCEAU:WritePerm are changed  manually.

At starting, with autosave mechanisme, there is a mismatch between right access and  lock values.

Any ideas?

Dominique.



References:
security rules and autosave Touchard Dominique
RE: security rules and autosave Mooney, Tim M.

Navigate by Date:
Prev: RE: synApps usage on 64 bit systems Mark Rivers
Next: StreamDevice, asynDriver or some other solution? Bryan J. Boardman / Aware Electronics Corp.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: security rules and autosave Mooney, Tim M.
Next: synApps usage on 64 bit systems Henrique Dante de Almeida
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·