Emerson Exchange 365

• Not Answered

Equipment module with embedded control module download warnings

I have a question regarding download warnings I am seeing when using a class based equipment module with embedded control modules.  Specifically I have a soft AI module that is taking two inputs and calculating a differential pressure.  In the class control module I have a placeholder added to the specific inputs as a reminder of what specific AI's to connect.  I know this deviates from the class module approach slightly, however it was setup this way intentionally to allow for additional future systems where only the area prefix changes.  Basically these class modules are specific to a limited subset of identical equipment.  These systems are run external to phase logic and not unit based.  Anyway what I am finding is when I update the embedded control module instance to point to the actual tags, and try downloading the EM I get the warning message shown below.  The CM instance is pointing to the correct AI tags and if I ignore the warning and download the EM everything works as intended.

If I only download the CM (either embedded or a separate instance), I do not get the warning (see below).  What I believe is occurring is the EM instance is essentially looking at the class CM when verifying the download, not the instance where inheritance has been broken.  This is not the end of the world, however I am concerned it will drive complacency when it comes to reviewing and correcting download warnings (when are they real or not).  Any thoughts from the experts on how to address this?  Is there a better way to handle the class CM reminder / note that doesn't flag a download warning??

Jesse Delanoy

• 1 Feb 2023 4:55 PM
• Cancel

3 Replies

• Matt Forbis

  

  • 1 Feb 2023 7:52 PM

  Your observations are correct in that it checks against the class when doing a verify. Your options are to set the Ext Reference to #IGNORE in the class, make a module that exists in the database somewhere that will allow those to resolve, or have an error message. Usually we would set to #INGNORE in most of our projects.

  • Cancel
• Jesse Delanoy

  

  • 1 Feb 2023 8:57 PM

  In reply to Matt Forbis:

  Thanks Matt. I was hoping there might be another option, such as a comment character (//, (* *), etc..) that could be used to have something more descriptive than #IGNORE, and still prevent the download warning. I guess we have to re-think our approach.... maybe leave the #IGNORE and pre-build some bulk edit sheets instead to help guide the other engineers who will deploy logic for the next system.

  • Cancel
• Steve Linehan

  

  • 1 Feb 2023 9:38 PM

  In reply to Jesse Delanoy:

  You can configure a DUMMY-EXT as a floating point in the module class. The external references can be pointed at that when not required. That should prevent verification errors.

  • Cancel