V15LTS "References" on FunctionBlockTemplate - Analog Control - PID behaving strangely

I am trying to dump a list of all modules or classes containing the PID function  block.

Historically, I would have done this by navigating to PID in FunctionBlockTemplate - Analog Control - PID and right clicking and selecting "references" (BTW a typomatic hot key would be lovely for this function)

When I perform references, I only return 46 hits in the references dialog. I know for a fact  that we have over 1200 PID loops at this facility.

stranger still, I get references to a "PIDWCALARM", which has a type "Function Block Template", location PIDWCALARM, but there is no such template to be viewed.

Has anyone seen anything like this before. I know I have searched for all "DC" function blocks in this manner before and do not see why this should not work with "PID".

  • Two ways that I use for this sort of activity: 1. Parse Fhx file, 2. User-defined export (UDE).  #1 is a long and winding rabbit hole you don't need and probably don't want to go down anyway.  I would recommend #2.  Create a user-defined format file that contains (at a minimum) module name and any parameter on a PID1 block (e.g., PID1/PV).  Then perform an UDE on all modules.  The ones with a PID block will have a numeric value (probably zero) while those that do not will have <NULL>.  You can then open in Excel and sort/filter.  If you have both class based and non-class based modules, you will need an extra column (PID1$PV.CV for class based and PID1/PV.CV for non-class based)... if either has a numerical value then it contains a PID1 block, if both are null... then it does not.

    This only gets PID1.  If you have any modules with PID2 or something else, you need to add more columns to your format file.

  • The PIDCWALARM function block provides Conditional alarm functionality. the PID block does not. Under the hood, DeltaV switches out the PID for the PID CWALARM block when conditional alarming is enabled. There is an AICWALARM and ALMCWALARM. This allowed for migration of systems, where the original PID block would exist in controllers, and suddenly downloading a module with a modified PID block would create issues in online migrations. So we have both as a means of allowing for added functionality.

    The issue you are describing is that because the PIDCWALARM block is not exposed in the library, you can't ask for references on that block, which is likely the one you have in your 1200 modules.

    I would likely punt to an Excel VBA script that reads the FHX file and searches for the PIDWCALARM block definition. It's not that easy because you have to search for a module ("Module Instance name = " MY PID MODULE") store than and then search each line until you either find your Block name definition, or the next module. If you find the block, you output the module name and maybe some other data.

    I know, not that helpful. But I'm not sure there is another option.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Douglas Crowder has a better answer....

    Andre Dicaire

  • In reply to Douglas Crowder:

    A cool trick I just learned this week while UDE on a customer system with over 19,000 modules:

    From Knowledge Base Article AK-1400-0008, select just the areas with the modules you want to export rather than "Expand All" or “'Select All” on the tree in the User Defined Export dialog window.

    In modifying an existing fmt file, perform the following steps:
    a. Open the folder D:\DeltaV\DVData\Bulkedit.
    b. Launch Notepad and drag the fmt file from the Bulkedit folder to that Notepad window.
    c. In the first line of the fmt file, change the word “Module” to “MODULEAREA”, as follows:
            Original: begin_format_defn Module
            Revised: begin_format_defn MODULEAREA
    d. Go to File menu and select Save. Close Notepad.

    Proceed with the user-defined export of the modules in DeltaV Explorer. You may now just select the Plant Areas that the Modules are located.

    Notes
    - Selecting “Expand All” or “Select All” is not required or recommended for large systems
    - Only the Control Modules under a selected area will be exported. For example, it does not work for unit modules, but control modules inside a unit module will be exported.
    - If the system has many Areas with thousands of Control Modules, the entire system still needs to be broken into two or more exports to avoid reaching 8000 modules per export.

  • Personally, I would open DVexplorer, Press "CTRL+F", In the name field: *PID1* , click find now --> at the bottom: Print.
    I just hope that you didn't rename any Fb from PID1 to another name.
  • In reply to CPitsaer:

    Good idea if you only need to get the module names. Now if only the Print to PDF resulted in an easily usable output... one can only wish.
  • In reply to Douglas Crowder:

    Doug, thought of parsing the FHX and you are right, even running that XML converter make that a no-go. You nailed the UDF search, and i do that alot, and even get crafty with the advanced setting. generally i use wild cards with node IDs to limit the list to module counts that wont crash DV Explorer. But everyone's response prompted me to look at the Module Instance definition, and using the advanced UDF fields, specifically the "TYPE" and looking for "* PID *" did return about 1214 records, and I can believe that may be accurate. So thanks for all the contributions you make to this site. You did help me get there, and hopefully this will help the next guy.
  • In reply to CPitsaer:

    Oh, and I did try that, funny that I never stumbled onto that trick over the years, will definitely be using that going forward
  • In reply to Andre Dicaire:

    Andre, thanks for that explanation, was hoping you'd have seen this post. Always appreciate all your contributions to this site!