Emerson Exchange 365

Which Fail Parameter?

When using a flow transmitter in a control loop, which fail parameter would you recommend using to monitor the flow transmitter for failure?

Lucky

• 21 Sep 2015 3:58 PM
• Cancel

13 Replies

• Tinh Phan

  

  • 21 Sep 2015 4:54 PM

  Hello Lucky, Is this a HART of Foundation Fieldbus transmitter?

  • Cancel
• Lucky

  

  • 21 Sep 2015 6:09 PM

  In reply to Tinh Phan:

  This is a HART transmitter.

  • Cancel
• Tinh Phan

  

  • 21 Sep 2015 8:54 PM

  In reply to Lucky:

  Here are some options you can think about:
  DeltaV function block:
  Use the DeltaV function block "Field_Val_pct" for control loop
  Use DeltaV function block "HART_Field_Val" which is a hybrid of Analog and Digital. If you are comfortable with HART communication and your installation is solid, you could use this to trigger HART communication issue that the flow transmitter might be having. This will give your AI block HART status. When the HART status goes bad, it could cause your Control Module goes bad which will put your control into iman. You can also utilized the 4 digital values (HART_PV, HART_SV, HART_TV, HART_FV) to get digital information from the device that will also give you HART communication status as well. These digital status are sensitive to electrical interference.
  
  I Strongly advise to get a better understanding how these digital values and status affect you control function blocks before jumping into implementing them.
  
  DeltaV Device Alerts:
  If you only just want Alerts coming from this device, there should be built in from the manufacture recommended alerts that you can enable or disabled. I recommend you do this if you don't understand how HART works. All of the newer Emerson devices should have this. You will need to assign them to an control area and assign it to the DeltaV station you want it to show up before it gets activated.
  
  AMS Alert Monitor and Device Troubleshooting:
  If you have AMS Device Manager, the Alert Monitor capability will provide with device alerts as well. It let you know what is going on with the device. It will give you Device Diagnostics with recommended steps to troubleshoot the device. This is only if the device have the Emerson device EDDL template.
  
  Hope this help.

  • Cancel
• Andre Dicaire

  

  • 21 Sep 2015 8:59 PM

  You basically monitor the status field (.ST). From an AI block, the OUT.ST indicates the health of the field signal. The Block also sets its PV_Failure bit that propagates to the module's MStatus parameter. This is typically selected to set the Bad_ACT parameter via the MStatus Mask. This status is derived from the channel integrity. Note that the FF AI block also sets the .ST field to reflect a BAD status on the process variable, so both HART, FF and even passive 4-20 mA signals will end up setting the .ST field on a transmitter fault/failure.
  
  The DeltaV AI channel provides several mechanisms that can set the status and Overall Integrity of the channel, and thus the value for the AI/OUT.ST.
  - Loss of signal: signals above and below the maximum/minimum detection levels immediately set the Channel integrity to BAD. These are seen as Short circuit or Open circuit conditions, and are indicative of either a wiring fault or complete transmitter failure. Some transmitters can be configured to fail high or low, such as for a TC burnout failure, and use this out of range signal to tell the control system the channel is BAD. If the transmitter is configured to send its output out of range on a sensor failure, the choice to send upscale or down scale is based on how the control block will respond on its output signal if a bump in the PV value is perceived before the status switches to Bad.
  - NAMUR: The NAMUR setting uses preset limits, that if exceeded for several seconds, the channel is marked BAD. In this situation, the transmitter may be sending an over range signal that is still valid, and is not the fault level signal described above. The PV may be saturated because the process has exceeded the configured range of the 4-20 mA signal. Since the transmitter is no longer able to follow the process, the PV is set to BAD. The PV must exceed the limit for at least 3 seconds.
  - There are also the Under range and Overrange limits that are configurable. These can be used to set the Limit status of the PV. If the PV is seen as limited. The PV may still have a GOOD status but is seen as limited. The PID loop will suspend Integral action if the PV is limited, but will continue to respond with proportional action.
  - Finally, the HART_Error parameter on the channel determines if the HART status Byte will impact the signal status. The HART Byte can report if the device is PV Saturated, Out of Service, Transmitter failure, NVM fault, Configuration has changed, etc. You can choose to ignore some or all of these bits, but if the bit is not ignored and becomes true, the status of the channel and thus the PV value will be affected.
  
  The status byte in DeltaV follows the FF standard format, with BAD, Questionable, GOOD and GOODCascade, each with their four bit subgroup, and the HiLimit, LoLimit, Limited status as well. understanding how this status system works is important to take full advantage of this in your configuration. Out of the Box, DeltaV uses the status to shed the mode on PID blocks so that loops do not wind up when a signal goes to BAD status.

  Andre Dicaire

  • Cancel
• Lucky

  

  • 23 Sep 2015 12:51 PM

  In reply to Andre Dicaire:

  Andre, can you go into more detail on how to use the AI1/OUT.ST parameter? I was originally thinking of just using the BAD_ACTIVE parameter because my options are open due to it being Boolean. What is the output of the .ST parameter?

  • Cancel
• Andre Dicaire

  

  • 23 Sep 2015 3:50 PM

  In reply to Lucky:

  Lucky, The .ST field is part of the PV and OUT parameters in the AI block. Typically, this status propagates with the value to downstream blocks like PID or SELECTOR. The PID already has logic guiding its behavior on a BAD or Questionable STATUS. A CALC or CND block can read the AI1/OUT.ST value in an expression.
  
  Since I don't know what you are trying to accomplish, I can't really suggest how you might use this.
  
  The BAD ACTIVE parameter at the AI block is driven by the BAD_MASK settings. If you set this mask to capture INput Failure/BAD PV, it will be set when the OUT.ST is BAD, based on the status of the channel integrity. The BAD MASK shows things ike Out of Service, Device Fault State Set, Configuration Error, etc. Not all blocks drive these various statuses. The Configuration Error for instance is set in a CALC block if there is an error in the logic. Output Failure would apply to an AO or DO block. The BlOCK error parameter is the actual state of the conditions and all the block errors are ORed together into the Module level BLOCK Error parameter. These status are also sent to the MStatus and MError parameters which allow you to mask these to the module level BAD Active.
  
  So if you want to perform explicit logic on an input failure/bad PV, using the AI/BAD ACTIVE and setting the blocks Bad Mask will give you that control and a boolean parameter to use.
  
  The BAD status of the input comes from the channel integrity discussed in earlier post.
  
  
  So if you look at the AI Block, there is

  Andre Dicaire

  • Cancel
• Juergen Wetzel

  

  • 24 Sep 2019 9:50 AM

  In reply to Andre Dicaire:

  Hello Andre,
  
  read this info. I amdealing with a similar problem.
  
  I wanted to use the EIOC with Ethernet IP. If I read now the e.g. AI with an AI function block I can read the value comming in via Ethernet IP. What I want to accomplish is to set the ".ST" to good or bad according to a binary input comming also via Ethernet IP.
  Is there any way to link these 2 signals in an AI or DI input block together?
  
  Juergen

  • Cancel
• Andre Dicaire

  

  • 24 Sep 2019 5:40 PM

  In reply to Juergen Wetzel:

  That opens an interesting discussion. DeltaV systems fully embrace the use of signal quality by having a Status field for all process signals. Function blocks and Operator displays are designed to consider Status of a signal. We follow the Foundation Fieldbus status model with an 8 Bit word that holds status, Sub-Status and Limit Status.
  
  When integrating 3rd party data, DeltaV adds a basic status to all the signals based on communication, based on the EIOC (or PK, Serial Card etc) ability to communicate with the device. These protocols do not have an embedded Status and so this information is mapped separately.
  
  When reading a signal from the EIOC Logical Device with an AI block (or DI block) the .ST will reflect the communication status of the signal and there is no way to override this with another value. Well, there is a way. You can force the AI block to be in MAN, set this as normal mode and restrict permitted modes. Now you can write Value and Status to the AI1/OUT parameter. However, the LimitStatus could remain set as the block is in MAN. I'd have to check. But this would be confusing at best. you still need a CALC block expression to manage what you write.
  
  You could use Input parameters to read value and status registers, pass these via a Calc block to evaluate for the right status, and hold last value in case of loss of comms. The combined Status and value would be written to a Float with status parameter that could be wired to the Simulate In of the AI block. Force the Block in to simulate and disable the Bad Mask option for simulate active. This still leaves the block in an Abnormal state but on these PLC modules, you would ignore this Abnormal status. It is the new normal.
  
  You could wire this parameter into an alarm block. There you don't have the Simulate abnormal status issues, no mode issues, and you can have a scale value along with alarms. I call this my PLC input. If this an Ethernet Drive or other diagnostic value, I'm think you don't have channel status indicators. So I think we are talking PLCs
  
  Here is some sample code:
  
  REM Check status of Input value for loss of comms. If BAD, stop updating the
  REM destination parameter, holding last value in that parameter.
  if '^/VALUE.ST' = BAD then
  '^/VALUE_W_STATUS.ST' := 20;rem means BAD NoCommLastUsableValue
  else;
  '^/VALUE_W_STATUS.CV' := '^/VALUE.CV';
  if '^/STATUS.CV' = FALSE then rem Check if additional Status is indicated
  '^/VALUE_W_STATUS.ST' := GOOD;
  else;
  '^/VALUE_W_STATUS.ST' := BAD rem This sets Bad NonSpecific (0). Options are
  rem NotConnected(8)
  rem Device Failure (12)
  rem Sensore Failure (16)
  rem NoCommNUV (24)
  rem Out of Service (28)
  rem see Function block Status Values in BOL
  
  endif;
  endif;
  
  If there are more status values, you can decide if they fit one of the substatus categories and use a relevant value. In this case, I stop updating the Value_w_status if the incoming VALUE has bad status, which resulted in "holding last value". So I set status as BAD, NoCommLUV. If the communication is good, the additional status value from the PLC indicates if the value I'm reading is valid or could be questionable. You decide in the CALC block what Status value best represents the state of the data. Or simply make it BAD non-specific (ie 0, or use the keyword BAD).
  
  In my opinion, this PLC Value can be wired to an ALM block if alarms are needed and a Scale for display. Scaling of the value I expect would be done in the PLC.
  
  Or, you could skip all this, and use an AI block to read the value and communication state. Then, in the Operator Interface, modify and create a SCADA dynamo or GEM that reads the additional status value and applies appropriate indication at the console.
  
  The main reason for combining these values into the AI block PV Status is to use the same Operator display objects for these SCADA modules and the native DeltaV control Modules. We end up with a lot of extra configuration in the EIOC modules to emulate DeltaV behavior to satisfy Display objects. It's not that hard to add a group of SCADA objects that handle the data directly and simplify the whole deal.
  
  After all the difficulties I recently experienced on a PLC integration project, trying to force fit PLC Data into DeltaV data structures in order to resuse dynamos that were not designed for the PLC data, I'm of the opinion that this would have been easier to recognize the EIOC is a SCADA interface and let the HMI configuration handle much of this status data for the same end result.

  Andre Dicaire

  • Cancel
• Juergen Wetzel

  

  • 25 Sep 2019 5:43 AM

  In reply to Andre Dicaire:

  Andre,
  
  thank you for your ideas and time you to the answer my question.
  
  I will look into it. I am not the real expert in DeltaV programming but I try to understand your thoughts.
  
  But as it seem to me you are confirming my impression that there is no easy way to get a signal and a status of
  a 3rd party device into an AI, DI, AO or Do block of DeltaV.
  
  Especially the LDT of a Ethernet IP device contains a lot of signals. I am case the RIO has up to 16 LDT with 100 to 600 signals.
  Signals mean the value + a status to it.
  
  So my best guess was to have a block taking the signal and having a status input which put the block in good or bad operation.
  So the downstream signal can use all the built in feature of DeltaV.
  
  I am a bit new to the forum so I have no idea how to insert a picture here.
  
  But I will try to descript what I did:
  
  I have a AI signal with a status bit.
  
  So I used an AI block for the signal (IN1) and a DI block for the status (IN2).
  
  I combine them by a calc block with 2 input and one output.
  
  The equation in the calc block is rather simple:
  
  If IN2 = 1 Then
  
  OUT1 := IN1;
  'OUT!.ST' := 128
  
  ELSE
  
  'OUT1.ST' := 0
  
  END IF
  
  This is giving me a bad calc block output if the Di is bad(0).
  
  
  Juergen Wetzel

  • Cancel
• Juergen Wetzel

  

  • 25 Sep 2019 6:25 AM

  In reply to Juergen Wetzel:

  One additional point.
  
  If you could get a diagnostic info in the DST definition faceplate then all the signals would get already a good or bad status and the I/O block could works with this. This could also easily configured by a FHX import.
  
  But I thinks there is no way having such an easy function.
  
  It is quite nice how the EICO is designed. It allows an really comfortable import of the signal configuration of a sub system but not for the diagnostic info.

  • Cancel
• Andre Dicaire

  

  • 25 Sep 2019 9:51 PM

  In reply to Juergen Wetzel:

  When accessing raw LDT Signals, you are best to use an External Reference parameter rather than an AI or DI block. The function blocks add Alarm capabilities and scaling calculations, and mode, and that means CPU is wasted.
  
  The Signals have a native ST value, which you should be checking for because if the PLC is not communicating, you neither now the value signal or the associated status bit.
  
  The expression logic you show seems simple and should work, provided the AI and DI block parameters you've wired have a good status on them. If the Status of DI is being set to BAD when you set it to 0, the Expression will register a Block Err. I'm assuming you see a Question Mark on the CALC block when the DI is set to 0. Check the Block Error parameter for the CALC block to see what it is indicating.
  
  Your expression noted above is not quite right, but I'm assuming that is a transcription error. You are missing the end of line ; and reference OUT!.ST in one statement. But if these are in the actual expression, you would have an error indication permanently.
  
  I would use two External reference parameters to read the LDT signals and I would use explicit path references in the expression instead of wired IN1 and IN2. Especially for the DI signal as it is a discrete value that you are casting to Float vie that wired IN1 connection. Technically it should still work because a Discrete 0 is accurately depicted with a float of 0.
  
  If you select the Use rich Formatting button in lower right, then you can paste images and such.
  
  Which Protocol option are you using for your LDT's (Class 1, Class 3, UCMM?)

  Andre Dicaire

  • Cancel
• Juergen Wetzel

  

  • 9 Oct 2019 12:38 PM

  In reply to Andre Dicaire:

  Hello,
  
  sorry for my late repley I was away from the office and tied up with othe things.
  
  So I am using for the analog and digital I/O data Class1 communication and for the HART (float) variables 1-4 Class 3.
  
  Bassically I worte a small VBA in excel to generate a FHX configuration file for the EICO to import the configuration and signal allocation of our I/O system.
  
  So the last thing what I am lookung for is a smooth way to get the signal diagnostic data into the EICO.
  
  I will try the mentions External reference parameter.
  
  Jürgen Wetzel

  • Cancel
• Andre Dicaire

  

  • 9 Oct 2019 4:13 PM

  In reply to Juergen Wetzel:

  that is correct. the EIOC signal has status based on LDT communication, Good or Bad. the AI block uses this status. you would need to is Similate_in to pass a processed status and value.
  
  i think it will be better to combine the extra status at the HMI. That would be the cleanest SCADA solution.

  Andre Dicaire

  • Cancel