• Not Answered

Do class based modules allow unneeded block deletion as a configuration?

During a conversation at exchange, someone mentioned that some structural changes such as the deletion of unneeded blocks from module could be set up as configurable in a class based module. I could not find any hints to that in BOL for v13.3.1. Is this, in fact, possible?

5 Replies

  • In v13 there are new function blocks [Analog Tracking (AT) under Analog Control and Discrete Control Condition (DCC) under Logical] that allow you to configure conditions in the module (class based or not) but then limit what will be downloaded to the controller. This is comparable to removing condition blocks in pre-v13 non-class based configurations (couldn't remove in instance of class).

    You can look at Books Online for documentation of the blocks and they both have example configurations of the module templates documented using these blocks.

    The use of these blocks has shown to have significant reduction in controller loading compared to configurations where these conditions were configured but not needed in pre-v13 systems. These are the only blocks at the moment that have this ability to affect what is downloaded to the controller.
  • In reply to Matt Stoner:

    Thanks Matt,

    I definitely have those new blocks in the back of my mind. Some templates have been designed to be pretty flexible such as allowing the PID to be changed to FF or replaced with a FLC; adding a splitter and second analog output for split range, swapping the output block to a composite that works with devicenet; adding or deleting a BKCALC wire to change between a slave loop and a master loop; etc.

    so it sounds like I heard wrong?
  • In reply to Brian Hrankowsky:

    Yeah there is nothing to support all but maybe one of those examples in the system now or in the up coming v14 release.

    • Master/Slave BKCALs can sort of be supported using external refs or dynamic refs today
    • v13 allows the dynamic refs to be configured to default paths
    • v13 allows external refs to be configured with #IGNORE if you don't have a Master Loop, we have Slave External Ref wired to PID/CAS_IN that is defaulted to #IGNORE and Master has BKCAL_IN wired to PID/BKCAL_IN left blank as it has to be configured. 
    • But yes you still have to pick the correct module type (Master or Slave) to have the proper parameters already.

    There have been many wanting support for things you listed but I'm not aware of any plans of supporting this at the moment.

    Suggest you hit up UDEP on this one, http://www.userideas-emerson.com/

  • In reply to Matt Stoner:

    Thanks Matt,

    I'll have to explore the new features in v13 you mentioned. are they described in BOL?
  • In reply to Brian Hrankowsky:

    There is a little documentation on the External Reference Parameter in BOL which is located at:
    Configuration -> Function Blocks -> Function Block parameters -> External Reference Parameter

    The Dynamic Reference documentation doesn't look like it got updated for the default configuring but if you edit a dynamic reference parameter there is an Initial Reference Path along with Browse for Internal and External parameter buttons.