Emerson Exchange 365

Module Error alarm

Hello,

I have similar alarms on several modules. The only common point is the same module class, and they are using an external reference from the slot on the PD (measurement of VSP power).

Do you know how I can fix that?

Regards

• Fieldbus #wiring
• configuration

Nayel

• 16 Jul 2024 1:16 PM
• Cancel

7 Replies

• Nayel

  

  • 19 Jul 2024 12:38 PM

  Any help please ?

  • Cancel
• Brian Hrankowsky

  

  • 19 Jul 2024 12:52 PM

  In reply to Nayel:

  Please send a screenshot showing which bits of MERROR are on either from the detail display or control studio.

  • Cancel
• Matt Stoner

  

  • 19 Jul 2024 1:06 PM

  In reply to Nayel:

  Module Error is 40 which is IO Input Error and Input Transfer Error.
  
  That is coming from JT_1840_0 (Block, Parameter or what?) but unsure if there is more data that would be shown in the Desc1 field, expand that to see if there is more information. You are getting a value that is not a valid value for where it is being wired.

  • Cancel
• Andre Dicaire

  

  • 19 Jul 2024 1:16 PM

  The alarm message indicates a value of 40. So fourth and sixth bits are set in M_ERROR. Don’t have access to look those up at the moment.
  
  The e journal shows Input transfer and IO input errors. So it would point to how the module is configured.
  
  Consider converting one instance to classless and work with this to identify what is causing IO Input error.
  
  Are you seeing any status issues in diagnostics on the referenced signals? The input transfer error is likely a consequence of the IO input error as the parameter is wired to a block.

  Andre Dicaire

  • Cancel
• Nayel

  

  • 19 Jul 2024 2:27 PM

  In reply to Andre Dicaire:

  I'm using a DST IO from the DP card, the motor is connected through profibus to deltav, please do you need further information to help ?

  • Cancel
• Nayel

  

  • 19 Jul 2024 2:31 PM

  In reply to Matt Stoner:

  this is the description of Desc 1

  

  • Cancel
• Andre Dicaire

  

  • 19 Jul 2024 5:58 PM

  In reply to Nayel:

  The issue is intermittent, or at least appears so. You indicate this is seen only on modules from the same class used to interface with VSD's. The AI block and DeltaV module themselves do not appear to be the issue. The AI block is generating a Block error which propagates to the M_ERROR based on the Bad_Mask of the AI block. If it was an issue with the module/AI block, we'd see much more of this on all modules.
  
  This tells me the issue is with the Profibus segment or the VSD's. Can you identify any common behaviors, beyond the same class? Are all affected modules on the same Profibus card/segment? Have you looked at Diagnostics to observe if there are intermittent integrity flags set on devices or card?
  
  If the controller flags the device signals as bad, the AI block would in turn flag an error. The Profibus card scans its segment writing and then reading values from each device in turn, and continually repeating this. The card is then scanned by the IO bus of the controller for data exchange. This is a separate asynchronous task that moves the data to the controller IO map. Then modules execute at their scan rate to read the latest available data and write new values as needed. The Profibus scan and IO scan happen  much faster than 1 sec. a transient no response could periodically occur and set a bad status, which clears on the next scan of the bus, resulting sporadic bad status seen by the module.
  
  This is all speculation. do you have multiple segments? Is this seen on devices on all segments or just one? What is common and what is not common between modules that have this behavior and those that don't? Check diagnostics and device status as well as signal status.
  
  You might want to trend the status of this signal to observe is status is being affected somehow? If you are trending with DVCH, it should show status. You should be able to extract raw .CV and .ST using Report Writer or enabling PHV to mark status on trend lines. IO_IN status propagates to PV and OUT of the AI Block.
  
  Assuming you do identify an issue on the input data side, it looks like you have a custom alarm on module BAD_ACTIVE. You could use a CND block to detect the BAD_ ACT and then put a delay on the out value so that an error has to last a few scans before it flags the alarm. The IO Input failure messages will still generate, but the chattering alarm can be addressed without suppressing it.
  
  I can't think of anything with the AI Block itself causing this error. However, the L_TYP and the signal data type can be checked. Are you scaling an integer? Is this a 32 bit integer? The AI Block is a 32 bit float for Field_Value and PV and OUT. Even if using a 32 bit integer, I don't think this would cause an intermittent issue.

  Andre Dicaire

  • Cancel