Re: [foxboro] AOUT Issue

  • From: Tom Vandewater <tjvandew@xxxxxxxxx>
  • To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
  • Date: Wed, 27 Jan 2016 18:42:52 -1000

That sounds like a pretty reasonable request to me Jimmy. Holding an analog 
output in last value with no way to override/change it would seem to be a very 
serious safety issue.  That is similar to the PIDA block parameter called CEOPT 
which by default value settings puts the PIDA controller in hold when it gets 
an error in its MEAS. If the valve opens up so much that it drives the 
Measurement high out of range then it holds the last output waiting for the 
measurement to come back in range. Hmm, what is wrong with that picture??  At 
least, in that case, the operator CAN put the controller in manual and drive it 
closed to bring the measurement back in range. 

Tom VandeWater
Control Conversions, Inc.

On Jan 27, 2016, at 10:33 AM, Jimmy Chan <jkchan@xxxxxxxxxxxx> wrote:

Hi All,
I believe this is the same issue we discovered back in 2009.

It only happens when you enable HART and does not matter if you have AOUT or 
not. When reported to GCS, this is the response we got:

CAR 1013207 -- Function Needed to Ignore Device Malfunction Status Bit

CAR 1013207 which you submitted is being put in REVIEW status, preparatory to 
being CLOSED with the following proposed Response:

9 Dec 2009 (RH) - The described problem is Not a Product Defect (NPD) that 
can be remedied within the 8.4.1 I/A system, because the I/A logic was 
purposely designed to not override basic safety interlocks within its 
external devices. With some devices, such as our SRD991 positioner, the 
allowable amount of deviation (output setpoint minus actual position) before 
the "Device Malfunction" status is set can be programmed/configured by users 
in the device itself. The I/A system is purposely designed to never ignore a 
Device-Malfunction status bit that is set by the device, even though it may 
not be regarded seriously for this one case, because, it indicates any device 
malfunction or failure of any sort, some of which could endanger personnel 
and the process itself.

We had another go late 2015 with the latest firmware and tried all available 
options:  NOFAIL, NOALARM OCD, the same results. This is the new case 
(1289589) we submitted, as PER this time:

Problem Description :   ROUT connected to a HART device should not be frozen 
and not having any other means to alter the output when "Device Malfunction" 
bit is set.
Suggested Solution:     Make this an option, just like with HART 
communication failure or at least, make available a method to recover from 
the ''hold'' state like switching block to manual before driving the output 
manually.
Expected Benefit:       Provide more control to user rather than locking the 
block in potentially unrecoverable state. For example, if you are trying to 
open a damper but it is stuck closed and ''Device Malfunction'' is set. You 
should be able to try to close the damper to reset ''Device Malfunction''. As 
it is, the                   output will hold the last value before ''Device 
Malfunction'' is set and there is nothing you can do from then on.

Regards

Jimmy Chan  |  Systems Engineer
Methanex New Zealand Ltd.
409 Main North Road, SH3, Motunui 4383
Private Bag 2011, New Plymouth 4342
T:  +64 6 754 9808
E:  jkchan@xxxxxxxxxxxx
 
 
_________________________________________________________________________
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: