We have several modules that have serrors such as INPUT_TRANSFER_ERROR and COMPONENT_ERROR.
Control studio show the MERROR and MSTATUS values but does does not show any Xs or ?s in the graphic diagram.
Is there any DV application or log file that can give more specifics on where or what in the module, function block or parameter the error is occuring?
My suggestion is to place the module in debog mode, stop execution, then step through each block until you see changes in the status that indicate which block is causing the issue.
I realize this may not be possible on a running system, so if you have a sim system, or if you can either create a duplicate module on-line (that does not drive output) that would give you ability to test this.
Another suggestion (along with Youssef's ):-
Usually INPUT or OUTPUT transfer errors can occur because of problems with Field Devices and their ability to communicate with the DeltaV module. If this is a new installation, may be the field instruments are not fully configured or wired completely. An IOF error would show that there is no wiring continuity with an Instrument or it has completely failed.
If you launch DeltaV diagnostics and go to the I/O channel where the field instruments are wired to, you may be able to see more information. Some times if a HART enabled instrument is located on this channel and it is unable to transmit HART data (even when it is able to send 4-20 ma signal O.K.), the DeltaV module might indicate this status. While in Diagnostics, you should be able to right click and get the properties of the field Instrument (make, model number etc details) and also be able to see if it is communicating its HART variables.
In summary:- the DeltaV module is indicating that it is having trouble to read the signal (from a transmitter) or send the signal out (to the control valve).
In reply to Youssef.El-Bahtimy:
Eddie,
The event log will show you the block(s) having the problem. You can find which blocks are having the issue by looking in the Desc1 column when the input transfer error occurred.
Matt Stoner | Senior Technical Consultant, NA Projects | Process Systems and Solutions, Kansas City Engineering CenterEmerson Process Management | 9300 West 110th Street | Bldg 55, Suite 300 | Overland Park | KS | 66210T +1 913 529 6539 | F +1 913 529 4207Matt.Stoner@Emerson.com
In reply to Matt Stoner:
Hi Eddie,
Do you have any CALC/ACT blocks in these modules?
These errors are seen, when the CND / CALC / ACT blocks are trying to do some actions that are not allowed. (e.g.: trying to write value or status to a input parameter like PV_D, trying to write status to a parameter type without status, trying to write a numeric parameter with string value, trying to write a null value to a named set parameter (transfer related errors), trying to perform math functions on string parameter (incorrect component in function), & so on.....)
Generally, these blocks show yellow question mark, if the write or read itself has failed. But if the error is due to parameter type mismatch, then sometimes the question mark is not shown on the expression block.
Go through the expression & verify you are not doing any 'illegal' actions there..... :-)
If error is still not found, see if you can upload the module snap & expressions in used blocks in the forum.
We might be able to check the code, if it is not too complex.
Regards,
Amod.
In reply to amodbobade:
The modules in question are simple PID loops with an AI, PID and AO block. Both AI and AO are charms I/O and have no diagnostics problems.
NOTE: It was noticed that all the MERROR and MSTATUS errors happen when the PID is in AUTO and disappear when in MANUAL.
The PID is linked to AO block (OUT>CAS_IN) and the AO block is linked to the PID (BKCAL_OUT > BKCAL_IN).
Here are some module parameters:
PID Control_Opts = Track_Enable, Direct_Acting, SP-PV Track in Man
Modes Permitted = Manual, Auto,
Normal Mode = Auto
Target Mode = Auto
AO IO_OPTS = SP-PV Track in Man
Mode Permitted = Out Of Service, Manual, Cascade
Normal Mode = Cascade
Target Mode = Cascade
Thanks for the assistance.
In reply to Eddie Villarreal:
Well I stumpled into someone who has seen this problem where an Input Transfer Error and Component Error occurs when the PID block is placed in AUTO and not in MANUAL.
The problem was the wire between AI block OUT_SCALE and the PID PV_SCALE. Once this wire was removed, the error disappeared. If someone can explain the reason this wire did not work, please do so. Thanks.
The pv_scale parameter fields of a pid block are not writable at run time unless the function block is in out of service mode.
If you have wired the parameters for consistency between the ai and pid to reduce configuration discrepancies, you will have to instead have the module load the function blocks as oos, write the pv_scale during the first scan with a one shot using a calc block (not wired). this may not be a worthwhile strategy though, because it means a partial download to your module will be more disruptive than necessary. If you are trying to change scale dynamically at runtime, I would consider using two statically configured loops that are selected for final element control instead.