Re: [foxboro] Best method for remote read-write DM/AM?
- From: "Boulay, Russ" <russ.boulay@xxxxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Thu, 24 May 2007 16:27:26 -0400
Corey,
/usr/fox/wp/data/wp51_cmds causes all non local DM's to come up with
those =
settings. You can edit that file if needed to remove all remote DM's
from those restrictions. That file also prevents certain AM functions as
well.
If FoxView, the file is fv_cmds
As to the Alarm Manager.
If Alarm Manager is already up and running, then subsequent environment
changes need the pref AM stuff in the environment file.
If Alarm Manager is called up after an environment is already displayed,
then the AM inherits the DM protections.
So,
protect all
unprotect 0,100
dmcmd run /usr/local/pref -$AMNAME " protect all "
dmcmd run /usr/local/pref -$AMNAME " unprotect value 0,100"
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Corey R Clingo
Sent: Thursday, May 24, 2007 3:45 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] Best method for remote read-write DM/AM?
I did some searching on the list archives for this, but 8 or 9 pages
into =
it, didn't really find anything specific to my question.
I want to have a PC in the control room with the ability to launch =
read-write DMs and AMs from adjacent WPs in the event of plant upsets, =
startups, ops engineer wants to play, etc. I've defined extra DMs/AMs
in =
the dmcfg file as class O, but they still come up with omsets disabled
and =
access class 100 protected. This of course is contrary to what all the =
docs I read said (dmcfg.man, Workstation Alarm Management, the
X-terminal =
user guides). I can work around it in DM, however, by enabling omsets
and =
unprotecting value 100 in the initial environment file; I like this
better =
anyway because there is no reboot required if I ever have to change it.
However, the alarm manager is killing me. It will not inherit the =
unprotected 100 class from the DM (like the docs imply that it should).
It =
also will not read the initial environment file, even if I define that
in =
the ADMC (I tested this by including a pref -SOMEOTHERDM DMCMD "msglin
am_activated" -- it worked when I launched the DM, but not the AM). I
can =
pref the unprotect 100 to the AM after it's up, and the buttons become =
black on cue, but I can't automate this on AM startup, since it won't
read =
the environment file. Other hacks I've considered, like a daemon script
to 'ps' periodically for the AM and pref it, or launch it with the DM, =
wait a few, and then pref it, are just too ugly.
The only other thing that crossed my mind here is that I'm not launching
the DM or AM as root, but as a special account I created for this
purpose =
(though I made sure this account has read access to all the files in =
question, if that's even necessary). No mention of that in the docs,
but =
I wouldn't be surprised if that is the problem, I'll probably try that =
later today, though I would not prefer to run that way.
Anyone else run across this (OK, stupid question :)?
Thanks,
Corey Clingo
BASF Corporation
=
=
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
=
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=
Confidentiality Notice:
The information contained in this electronic message and any attachment(s) =
to this message are intended for the exclusive use of the recipient(s) and =
may contain confidential, privileged or proprietary information. If you are=
not the intended recipient, please notify the sender immediately, delete a=
ll copies of this message and any attachment(s). Any other use of the E-Mai=
l by you is prohibited.
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
