Re: [foxboro] HLBL question
- From: "Johnson, Alex P (IOM)" <alex.johnson@xxxxxxxxxxxxxxxx>
- To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
- Date: Thu, 21 Jan 2010 20:59:53 -0600
Re: :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.
This is incorrect unless you are addressing a very large number of compounds
outside the CP running the statement.
For these calls, the CP adds the compound name to its IMPORT table. So, only
the first reference to a block in that compound will result in a multicast. All
subsequent accesses will go directly to the target station.
That is, this reference works like omsetimp.
Re: 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?
No multicast is issued if the target compound is in the CP executing the
statement. It's a local lookup. It's not particularly fast, esp. in older CPs,
but it does not add load outside of the CP executing the command.
Re: Us applications folks were being chastised for adding excess load on the
system with the extensive use of these kind of statements in HLBL.
I hope this helps minimize the criticism.
Regards,
Alex Johnson
Invensys Process Systems
10900 Equity Drive
Houston, TX 77041
+1 713 329 8472 (desk)
+1 713 329 1600 (operator)
+1 713 329 1944 (SSC Fax)
+1 713 329 1700 (Central Fax)
alex.johnson@xxxxxxxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Steinbrecher, Nick
Sent: Thursday, January 21, 2010 1:58 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] HLBL question
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
*** Confidentiality Notice: This e-mail, including any associated or attached
files, is intended solely for the individual or entity to which it is
addressed. This e-mail is confidential and may well also be legally privileged.
If you have received it in error, you are on notice of its status. Please
notify the sender immediately by reply e-mail and then delete this message from
your system. Please do not copy it or use it for any purposes, or disclose its
contents to any other person. This email comes from a division of the Invensys
Group, owned by Invensys plc, which is a company registered in England and
Wales with its registered office at Portland House, Bressenden Place, London,
SW1E 5BF (Registered number 166023). For a list of European legal entities
within the Invensys Group, please go to
http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77.
You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail
inet.hqhelpdesk@xxxxxxxxxxxxx This e-mail and any attachments thereto may be
subject to the terms of any agreements between Invensys (and/or its
subsidiaries and affiliates) and the recipient (and/or its subsidiaries and
affiliates).
_______________________________________________________________________
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:
