Contact Us

If you still have questions or prefer to get help directly from an agent, please submit a request.
We’ll get back to you as soon as possible.

Please fill out the contact form below and we will reply as soon as possible.

  • Contact Us
  • Home
  • Products
  • Automation Systems
  • Machine Automation Controllers

Avoiding Output Conflicts in Sysmac Studio User-Defined Functions

Written by Arlo D'Cruz

Updated at April 8th, 2025

Contact Us

If you still have questions or prefer to get help directly from an agent, please submit a request.
We’ll get back to you as soon as possible.

Please fill out the contact form below and we will reply as soon as possible.

  • Products
    Automation Systems Control Components Motion & Drives Quality control & Inspection Robotics Safety Sensing Services Software Switching Components
  • Amplify e-Store
    e-Store public
  • Public CSC
+ More

When working with Sysmac Studio to create user-defined functions, developers might encounter a confusing behavior: calling multiple instances of a function results in unexpected interactions between their outputs. Specifically, the output from one function instance appears to affect another. This can lead to bugs that are difficult to trace.

The Root of the Problem

This behavior often occurs because not all output variables are explicitly assigned during function execution. If an output is left unset, it retains a value that may have been used by a different function instance—resulting in cross-contamination of logic.

According to the Software User's Manual (W501):

“The values of the output variables of user-defined functions must always be set in the algorithms of the functions. If the output variables are not set in the algorithms of the functions, the values of the output variables are undefined.”

In other words, if you don't assign a value to every output in every code path, you risk inheriting residual values from previous executions.

How It Looks in Structured Text (ST)

Imagine a function like this:

IF input = TRUE THEN
    output := TRUE;
END_IF;

If input = FALSE, the output is never assigned. When this function is called multiple times, the output of one instance may seem to “leak” into another because the variable is never cleared.

How It Looks in Ladder (LD)

In LD, the same problem arises when output pins are not explicitly driven in every possible execution path. If the logic does not energize a coil or move a value into the output every cycle, the last written value may persist.

Symptoms in Your Program

The below example shows what you will see after setting only Function2Inputto TRUE.

This leads to function blocks producing misleading or shared outputs—even when their inputs are different. It may look like outputs are linked, when in fact they're just retaining old values due to incomplete assignments. 

Best Practices to Avoid This

To prevent this issue:

In Structured Text

Always assign a value to the output, even with default logic:

output := FALSE; // default value
IF input = TRUE THEN
    output := TRUE;
END_IF;

In Ladder

Ensure that each rung with the function block drives the output variable every scan. Use logic to move default or calculated values to the output pin under all conditions.

Conclusion

Whether you're writing in ST or LD, Sysmac does not automatically clear output variables in user-defined functions. Outputs behave like persistent memory unless you explicitly assign values every cycle. Always ensure that each output is handled in all logic paths to avoid cross-instance interference.

sysmac output issue

Was this article helpful?

Yes
No
Give feedback about this article

Related Articles

  • Create Shared Variables Between NJ-R PLC and Omron Robot
  • Serial Communication in CP1L and CP1H PLCs
  • How to Create Character Literals in Sysmac

Definition by Author

0
0
Expand