Re: [foxboro] HLBL question
- From: "Steinbrecher, Nick" <E.Steinbrecher@xxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Thu, 21 Jan 2010 13:58:27 -0500
One issue related to this topic is effect on system load of a statement
like
:COMP:BLOCK:MA := FALSE;
Our understanding is that this results in a broadcast across the system
even if :COMP:BLOCK is in the same station.
Mr. Johnsons reply indicates that if the :COMP:BLOCK is in the same
station no broadcast is made and no load is put on the system outside
the CP.
Is my interpretation of Alexes response correct?
Us applications folks were being chastised for adding excess load on the
system with the extensive use of these kind of statements in HLBL.
>Nick Steinbrecher
>
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Kevin Fitzgerrell
Sent: Wednesday, January 20, 2010 8:30 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] HLBL question
A couple issues with this include:
* in my experience output limits are more likely to be connected than
MA,
which requires writing in to the logic to which these are connected
* the sites I've worked at required operators to bring control loops
back to
auto
Having said that, Terry's right, using the output limits gives you some
effective tools for forcing control blocks.
Regards,
Kevin
On Thu, Jan 21, 2010 at 8:33 AM, Terry Doucet <doucet427@xxxxxxxxxxx>
wrote:
> Have you considered writing to the HI or the Low or Both output limits
to
> force the output wherever you want it? Now you do not need to check
the MA
> paramter. When you release the limits the output comes back at the
integral
> rate.
>
> Terry
>
> > To: foxboro@xxxxxxxxxxxxx
> > Subject: Re: [foxboro] HLBL question
> > From: neil_martin@xxxxxxxxxxxx
> > Date: Wed, 20 Jan 2010 10:26:40 -0600
> >
> > We have had trouble in the past, and that is why we are changing all
the
> > sequence to verify that the controller is in manual before the
output is
> > changed.
> > Neil Martin
> > Huntsman Performance Chemicals
> > Conroe & Dayton , TX.
> > Conroe ph) 936-760-6205
> > Dayton ph) 936-257-4212
> > pager) 936-522-0052
> >
> >
> >
> > "foxpat" <foxpat@xxxxxxxxxxxxx>
> > Sent by: foxboro-bounce@xxxxxxxxxxxxx
> > 01/20/2010 10:18 AM
> > Please respond to
> > foxboro@xxxxxxxxxxxxx
> >
> >
> > To
> > <foxboro@xxxxxxxxxxxxx>
> > cc
> >
> > Subject
> > Re: [foxboro] HLBL question
> >
> >
> >
> >
> >
> >
> >
> > Jerry,
> >
> > Are you sure about this?
> >
> > I never had any problems with, for example, following code without
wait:
> >
> > ::PIDA.MA <http://pida.ma/> := FALSE ;
> > ::PIDA.OUT := 0.0 ;
> >
> > It is my understanding that the PIDA will be 'forced' executed as
soon as
> > the .MA parameter changes, regardless the PERIOD/PHASE of the PIDA.
I do
> > recall that this has not always worked like this (version 3.x ?).
> > If you were to set a PIDA.PERIOD of say 4 (10 sec.) and you would
change
> > the
> > .MA just after it executed, it will execute again and not wait 10
seconds
> > to
> > reflect the .MA change.
> > Also the PIDA most likely first checks the .MA status, detects it's
in
> > manual and therefore will accept the output change.
> >
> > Try it and let us know!
> >
> > Pat
> >
> >
> > -----Oorspronkelijk bericht-----
> > Van: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]
> > Namens Jerry Hidahl
> > Verzonden: woensdag 20 januari 2010 14:56
> > Aan: foxboro@xxxxxxxxxxxxx
> > Onderwerp: Re: [foxboro] HLBL question
> >
> > Tim,
> >
> > Presumably, you're setting these controllers to manual in order to
set
> the
> > outputs to a safe value. Here's a tip. Wait one BPC (WAIT 0.5;
works)
> > before attempting to change the output, or else you may have a run
time
> > error for attempting to change a secured parameter (error -3, if I
> > remember
> > right). The PIDA blocks have to process, even if they are in the
same
> > compound, before you can change the output. You can change all the
modes
> > in
> > one cycle, then all the outputs in the next to save time.
> >
> > Jerry Hidahl
> > Process Control Engineer
> > Port Neches Performance Products
> > Huntsman 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=join
> > to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
> >
> >
> >
> >
> >
_______________________________________________________________________
> > 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
> >
> >
> >
> >
> >
> >
> >
_______________________________________________________________________
> > 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
> >
>
> _________________________________________________________________
> Reinvent how you stay in touch with the new Windows Live Messenger.
> http://go.microsoft.com/?linkid-06116
>
>
>
_______________________________________________________________________
> 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
>
>
_______________________________________________________________________
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
_______________________________________________________________________
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:
