Re: [foxboro] ECB CHAN parameter new but not in ICC ??

  • From: "Boulay, Russ" <Russ.Boulay@xxxxxxxxxxxxxxxxxxxxxx>
  • To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
  • Date: Mon, 16 Nov 2015 13:36:04 -0500

According to the block initialization chapter of Integrated Control Concepts
A block initializes when:

The CP hosting the Comp/Block is rebooted or recovers from a power failure
The Compound containing the block is turned ON
A block changes operation mode (i.e.: from Manual to Auto)
A block recovers from re-established connections or from bad process inputs
Controller blocks in cascade schemes return from open loop conditions
Hitting DONE while adding or editing the block in ICC while the Compound is
ON

And then there is implicit and explixit initialization which is described in
several paragraphs
As each block type as deeper embedded initialization schemes.

While a block will initialize.....only changed parameters get written.
So as example.....AIN block Hi Alarm Limit of 70 in the CP. ICC shows 100. If
block is selected DONE with other changes.....Hi Alarm Limit stays at 70 in the
CP
Only if that parametr is changed in ICC...will it overwite CP value.
_____________________________________________________________________________________


-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Joseph M. Riccardi
Sent: Monday, November 16, 2015 7:52 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] ECB CHAN parameter new but not in ICC ??

Russ,

As a side question...

I always wondered if the block is always fully downloaded and initialized after
changes. Just from observations, it looked like the initialization only occurs
under certain types of changes; like maybe simple alarm limit changes. (the
Select page does not flash cyan). So I was careful about doing an upload 1st
in some cases. Russ, could you please clarify your statement... All block
types always download all parameters (even those not
changed) and the block will initialize? It makes a difference on a running
plant if there are differences in the parameters between the ICC work file and
the actual CP (i.e., different alarm values, auto/manual state, etc.).

Thanks


Joseph M. Riccardi
386-451-7607 Cell

Joe@xxxxxxxxxxxxx

"To give real service you must add something that cannot be bought or measured
with money; and that is sincerity and integrity." - Donald A. Adams

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Boulay, Russ
Sent: Sunday, November 15, 2015 5:31 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] ECB CHAN parameter new but not in ICC ??

Hitting ok downloads the block and it initializes. As to the block while
running, we are talking ecb's here so many inputs and outputs could be
affected at one time.

Sent from my iPhone

On Nov 14, 2015, at 11:30 AM, William C Ricker
<wcricker@xxxxxxxxxxxxxxx>
wrote:

"... Obviously cant occur on a running plant. ..."

Certainly the LOADALL can't be done while running, but can one open
the block in ICC, then pick OK to re-apply? Also, will this re-apply
actually occur if there are no actual changes made to the block?

WCR

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of Boulay, Russ
Sent: Saturday, November 14, 2015 9:43 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] ECB CHAN parameter new but not in ICC ??

Your issue is that your current CP workfile (which is what ICC
displays when you open it) and also should match what is running in
the CP, is missing those parameters which are now in your host new
updated
pdef/olist files.
So when you request an ICCprint or other maintenance type function,
the pdef/olist files are referenced ...create a so called block
template for which the parameters get displayed, but the workfile is
missing those parameters so garbage characters can get into the
results because of no real value...garbage can sometimes get substituted.

This usually occurs if there are many blocks in the workfile that are
missing those parameters, the bigger the list of blocks the more
opportunity for the characters to wraparound and cause garbage characters.

The blocks in the workfile and CP that were there before the
upgrade....can only get those new parameters applied by opening the
blocks and selecting OK to re-apply them....or during a loadall of the
CP the new parameters get added to the workfile and CP as they load.

Obviously cant occur on a running plant.



-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of foxpat
Sent: Saturday, November 14, 2015 4:51 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] ECB CHAN parameter new but not in ICC ??

Dear list,

After upgrading 2 of our host servers to I/A 9.2 we noticed a new
parameter CHAN in some of the ECB blocks (ECB1,2,5). This parameter
does not show in ICC but does show up with an icc get all parameters
command. Most of the time the value is empty but sometimes it contains
garbage exceeding the length of a normal parameter value. This caused
our in house 'FoxRay' (not by a long way as good as FoxRay) to crash.
As it is 'in-house' I could simply solve it by trimming the parm value
so at least is will continue the import.

What could be the cause of this? Wrong iom files or something?

CP images were not upgraded (still 8.8)

The problem is reported to our local support but it would be nice to
present them with the solution on monday.

Kind regards,

Patrick Martens
Zeeland Refinery NL





_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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 email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________

*** 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 mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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: