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

  • From: "Joseph M. Riccardi" <Joe@xxxxxxxxxxxxx>
  • To: <foxboro@xxxxxxxxxxxxx>
  • Date: Mon, 16 Nov 2015 14:16:05 -0500

Whew! It looks like I have been taking some unnecessary steps in the past.
Thanks for the detailed response...


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: Monday, November 16, 2015 1:36 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] ECB CHAN parameter new but not in ICC ??

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






_________________________________________________________________________
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: