1. Considerations for Using Function Blocks (FB) with Enable Inputs (EN/ENO)
Function Blocks with EN/ENO behave more “intelligently” but are also more complex, requiring attention to their execution mechanism.
1. Understand the meaning of “not executing”
Core note: When EN = FALSE, the internal code of the FB is completely skipped and not executed at all. This means:
All OUT output parameters retain their last value (i.e., they remain unchanged and will not be reset or cleared).
All IN_OUT parameters also remain unchanged.
The states of internal timers, counters, edge detection instructions, etc., will also be maintained.
Risk: If you expect an output to automatically reset when conditions are not met, you must implement this in the internal logic of the FB and cannot rely on the EN input. For example, in a motor control FB, you may need to reset the Running state internally when EN=FALSE.
2. ENO State Management (Critical!)
As a developer of the FB, you must correctly set the value of ENO within the FB. This is not done automatically.
Best practice:
At the end of the FB, set ENO := EN by default. This means that as long as it has executed without errors, ENO will be TRUE.
At the error handling point in the internal logic, explicitly set ENO := FALSE.
structured
// ST language example: Managing ENO internally in the FB
IF EN THEN
// Main functional logic
IF … THEN // If an error occurs
ENO := FALSE; // Explicitly indicate an error
ELSE
// Function executes normally
ENO := TRUE; // Can be omitted since it is already set by default
END_IF;
END_IF;
// If EN is FALSE, ENO will also be automatically set to FALSE by the system, no need for handling
3. Logical Clarity in Chained Calls
Advantage: Connecting the ENO of multiple FBs to the EN of the next FB can create an intuitive “energy flow” where a failure prevents all subsequent executions.
Note: Ensure that this “chain reaction” is what you want. Sometimes, a failure in one device should not stop all subsequent operations, and may need to trigger a bypass or alarm. Do not blindly chain.
4. Avoid Conflicts in Enable Signals
Ensure that the logic controlling the EN input is clear, without competition or glitches. A common mistake is using a state output of the FB itself as part of the condition for its EN, leading to execution order issues or unintended latching.
2. Considerations for Using Function Blocks (FB) without Enable Inputs (EN/ENO)
These FBs behave more “directly”, requiring all control logic to be explicitly implemented.
1. Executed Every Scan Cycle
Core note: It runs every scan cycle regardless of need. This means:
Performance: If the internal logic of the FB is very complex, it will always consume CPU time, even if its functionality is not currently needed. For large projects, attention must be paid to the performance overhead this brings.
Logical Safety: You must ensure that the internal operations of the FB are safe in the “disabled” state (e.g., it does not accidentally reset data or trigger unintended actions).
2. Must Customize Enable Logic
Responsibility: You need to create one or more custom Enable input variables internally and check this variable throughout the internal logic.
Example: In a valve control FB ValveCtrl without EN, you must write internally:
structured
// Inside the FB
IF internalEnable THEN
// Logic to open/close/hold the valve
ELSE
// Logic for the disabled state, such as: stop actions, hold state, reset outputs, etc.
END_IF;
Disadvantage: This increases the complexity of the internal code and the testing burden of the FB.
3. Error Handling Must Be Implemented Manually
There is no standard ENO output, so you must define custom error state output variables (e.g., Error : BOOL; ErrorCode : WORD;).
The program calling this FB must actively query these error state outputs, as errors cannot be automatically passed through a chained structure.
4. Output States Must Be Clearly Defined in All Cases
Since it executes every time, you must clearly define the behavior of each output variable in both “enabled” and “disabled” states. For example:
When disabled, should the Command output retain the last value or be forced to 0?
When disabled, should the internal fault latch be cleared?
If not explicitly defined, behavior may become uncertain, leading to program bugs.
3. General Considerations and Best Practices
Consistency Principle: In a project or team, standards should be established to uniformly use one style (recommended with EN/ENO) to maintain code readability and maintainability.
For FBs with EN/ENO, it is essential to document the output states when EN=FALSE (whether they are held, cleared, or exhibit other behaviors), and what conditions will lead to ENO=FALSE.
For FBs without EN/ENO, it is crucial to clearly state their custom enable inputs and error outputs, as well as their behavior in each cycle.
Impact on “Retained” Data:
Static variables (Static) in both types of FBs will retain their values when EN=FALSE or custom enable=FALSE. This is fundamental to the design functionality.
The key is to handle external outputs (OUT) properly. FBs with EN will automatically “hold” outputs, while FBs without EN require you to program whether to “hold” or “reset” outputs.
Initialization:
For FBs with EN, it is common to use the FALSE state of the EN signal at system startup to naturally hold the initial output values.
For FBs without EN, you may need to execute an initialization sequence on the first call (using edge detection), otherwise, it will start working from the first cycle.
Summary:
Prefer using FBs with EN/ENO: They align better with structured programming principles, allowing for better control of execution flow and error propagation, and are the recommended practice in modern PLC programming.
Use FBs without EN/ENO only in special cases: For example, when a background task must run every cycle, in performance-critical loops, or for compatibility with legacy code.