EthernetJP (Customer) asked a question.

February 12, 2026 at 2:07 AM
User-Defined Instruction Performance

I have been trying to diagnose what I consider unexpectedly high scan times with the Productivity 2000 PLC, specifically the P2-550, though based on specs I suspect nothing in the Productivity family will perform much differently.

 

I'm not blaming the User-Defined Instruction. I will not be surprised to learn that this is operator error. Either way, what I can say with certainty is that my use of the UDI results in drastically slower scan times when compared to the same logic just running in a task.

 

CPU: P2-550 running firmware version 1.3.0.6

Productivity Suite Programming Software, version 4.6.0 (37)

 

I have 24 instances of the same UDI in one of my Tasks.

 

With the "UDI Task" in the Run Every Scan folder, my average CPU scan time is 73 ms. With only 12 instances of the UDI in that same task, average CPU scan time drops to 38 ms. With the entire Task moved to the Disable Task folder, average CPU scan time is 3.6 ms.

 

First idea: split UDIs into groups and conditionally enable each group so that every scan only a subset of the UDI instances are executed.

This improved scan time but hosed up the timers in the UDI.

 

*Skip past some ideas that didn't bear fruit.

 

Latest idea: recreate the UDI ladder in a Run Every Scan folder.

Directly address array indices e.g. DataArray(1)

Scan time increased from 3.6 ms to 3.8 ms.

 

Now create 10 copies of this task and place them in the Run Every Scan folder.

Scan time increased from 3.8 ms to 5.1 ms.

 

Now modify task to leverage indirect addressing e.g. DataArray(Index).

Scan time increased from 5.1 ms to 8.6 ms.

 

Now increase number of Task copies from 10 to 24, still using indirect addressing.

Scan time increased from 8.6 ms to 14.8 ms.

 

Is anyone else seeing performance hits with the UDI instruction?

 

 

  • 7 answers
  • 266 views

  • ADC Community_02 (Automationdirect.com)

    We are currently testing new firmware intended to address the lag observed in Data View and while monitoring tasks.

     

    The increase in scan time depends on several factors, including the number of UDI instances, the depth of nested calls, and the number of parameters being assigned. The use of indirect addressing for communication instructions within UDIs can further increase scan time.

     

    To help minimize scan time growth, we recommend limiting the number of assignable UDI parameters, reducing the use of nested calls, and avoiding large structures as parameters wherever possible.

     

    Because scan time is especially important in your application, it may be best to avoid using UDIs at this time. We will continue investigating and share additional updates as they become available.

    Expand Post
    Selected as Best

  • PouchesInc (Customer)

    Out of curiosity, how many rungs is your UDI and how many total instructions within it?

     

     

    Either way, having the same set of code in 24 tasks at 14.8ms scan time vs 24 UDIs at 73ms scan time is pretty crazy sounding.

    • EthernetJP (Customer)

      The UDI is 23 rungs and contains about 140 instructions

  • EthernetJP (Customer)

    For what it's worth, I did some more adjusting to try and get the non-UDI version of the logic as close to the UDI definition as I could.

     

    Still a very large performance delta:

    *24 copies of the "UDI mimic" task runs at 16.6 ms

    *single task with 24 instances of the UDI runs at 73.6 ms

     

    ADC tech support reached out and I have submitted a system report for analysis.

    Expand Post

    • PouchesInc (Customer)

      If I just had to guess, without truly knowing how these things are working behind the scenes, my guess is that the switching from a main already scanning task to "preparing special task memory" running the UDI task, then "closing the special memory" take a significant amount of time to do the loading and unloading. But that is just an off the wall theory I had thinking about how things could be processing through the PLC CPU. If each loading and then unload took 1ms each, that adds up quick on a lot of UDIs.

      Expand Post

  • ADC Community_02 (Automationdirect.com)

    @EthernetJP (Customer)​ Thanks for reporting this! We appreciate you sharing your project details. We were able to run some initial tests using UDI and also observed the increase in scan times you described. We’ve notified our development team and they’ve started investigating. We’ll share an update as soon as we have more information.

    • EthernetJP (Customer)

      Checking in. I am at a fork in the road with this project. Looks like I will need to forego use of the UDI for the time being.

      • ADC Community_02 (Automationdirect.com)

        We are currently testing new firmware intended to address the lag observed in Data View and while monitoring tasks.

         

        The increase in scan time depends on several factors, including the number of UDI instances, the depth of nested calls, and the number of parameters being assigned. The use of indirect addressing for communication instructions within UDIs can further increase scan time.

         

        To help minimize scan time growth, we recommend limiting the number of assignable UDI parameters, reducing the use of nested calls, and avoiding large structures as parameters wherever possible.

         

        Because scan time is especially important in your application, it may be best to avoid using UDIs at this time. We will continue investigating and share additional updates as they become available.

        Expand Post
        Selected as Best

 

Did this information resolve your issue?