DeltaV Embedded module performance.

Hi All, 

Is there any downside with using embedded module blocks in a motor control module as opposed to the DI and DO function blocks? Embedded modules would be configured as "shared" I could see using embedded modules could decrease configuration time as bulk edit files would become very simple. 

I was wondering if anyone knew of potential scan time issue or additional controller loading issues with this time of configuration. I was also wondering if the same concept could be applied to PID loops by embedding AI and AO control modules into a PID control module.

Typical:

with embedded modules:

• Control Studio
• Control
• motor
• configuration
• PID
• Bulk Edit
• Controller Loading
• DeltaV

Jeremy Heidebrecht

• 27 Aug 2025 8:30 PM
• Cancel

3 Replies

• Matt Stoner

  

  • 27 Aug 2025 8:42 PM

  This biggest issue with this is you can't control when those modules blocks execute (The execution order just means that the system will read the parameters for that associated module), so the logic could run the EDC module, then STATUS AND THEN CMD modules.
  
  The modules execution order is alphabetical on total download (plus the scan rate) but then any partial downloads will pull that module and put it at the end of the execution order.
  
  With using the function block and IO directly you are ensuring that you are executing the logic essentially how you have it configured to execute (delays are now only with times in I/O scans which is msec and not some module execution order that could be slow and change)

  • Cancel
• Andre Dicaire

  

  • 27 Aug 2025 8:52 PM

  Understand that embedded modules execute indecently of the host module that references them. So this would add latency as each module has to execute to read their IO data, then it becomes available to the host, which passes it to the out module that must execute before it goes out. If latency is not an issue, it will work. If you run the border modules faster, you get to reduce the latency, but at the expense of CPU.
  
  I'm not a fan of sacrificing runtime efficiency (that runs 100% of the time for the life of the system) for some possible configuration benefit on the front end. But that's just me. T
  
  Composite blocks, which you have here, can provide configuration efficiency. There down side is they are now referenced by many modules and affect those modules on download. Each composite is downloaded to the controller and all modules in that controller use that block on their next execution. So you want to be sure of your changes. Consider altering one module instance with new composites to fully test out changes, then roll them out to the composite for the rest of the modules.
  
  There are many ways to skin a module. Embedded modules exist for a specific purpose, like cascade loops and such, where two modules execute independently. Here you are string three modules together. Up to you to decide if latency or CPU are a concern.

  Andre Dicaire

  • Cancel
• Douglas Crowder

  

  • 27 Aug 2025 10:25 PM

  I disagree with your assertion that this approach "...could decrease configuration time as bulk edit files would become very simple". You now have three modules to configure rather than one. It seems much easier to just configure the IO_IN and IO_OUT parameters and be done with it.

  • Cancel