Decoding Mode Priority and Control Logic in Legacy Custom Motor Blocks in SIMATIC PCS 7

In SIMATIC PCS 7 systems operating with customized or legacy function blocks (such as FB 750 from older MFL libraries), internal mode priority and interlocking behaviors between inputs like EXT_MAN, EXT_AUTO, and Auto_ON cannot be assumed from standard Advanced Process Library (APL) documentation. Because custom blocks lack standardized feature bit definitions, determining whether EXT_AUTO overrides EXT_MAN requires inspecting the SCL/STL source code in the Master Data Library or analyzing live signal responses using CFC Dynamic Display and test mode in an offline simulation controller.

Architectural Evolution: Legacy Custom Blocks vs Modern APL

During migrations from legacy systems (such as PCS 7 V7.0 or custom Step 7 projects) to modern releases (PCS 7 V8.1/V8.2), engineering teams occasionally retain proprietary or third-party block libraries (such as 'MFL' or custom FB numbers like FB 750) to avoid redesigning existing WinCC faceplates.

Unlike standard Siemens libraries—such as the Advanced Process Library (APL) where motor control block MotL (FB 1850) strictly adheres to documented mode hierarchies governed by parameter bits (e.g., Feature.Bit0 and Feature.Bit1)—proprietary blocks follow custom boolean logic programmed by original equipment manufacturers (OEMs). In such blocks, inputs labeled EXT_MAN, EXT_AUTO, and Auto_ON may utilize mutually exclusive latches, priority overrides, or specific edge-triggered handshakes.

Techniques for Decoding Custom Block Logic (FB 750)

When documentation for a proprietary block is missing, engineers can reverse-engineer its internal operation using two proven methodologies:

Method 1: SCL / STL Source Code Inspection:
In SIMATIC Manager, expand the Sources folder of the Master Data Library or AS project.
Look for source files named FB750, MFL_MOTOR, or similar.
If available, open the source in the SCL/LAD/STL editor and trace the boolean assignment statement for mode evaluation (e.g., checking whether IF EXT_MAN THEN Mode := Manual; ELSIF EXT_AUTO THEN Mode := Auto;).
Method 2: CFC Dynamic Display and Test Mode:
Instantiate an isolated instance of FB 750 in a temporary test CFC chart.
In the CFC block properties, make all input and output pins visible.
Download the test chart to an offline PLC or S7-PLCSIM.
Open the CFC chart in Test Mode (Debug > Test Mode) and open the Dynamic Display window (View > Dynamic Display).
Add pins EXT_MAN, EXT_AUTO, Auto_ON, and the resulting motor outputs to the dynamic watch table to observe truth-table responses in real time.

Analyzing Mode Selection Priorities: EXT_MAN vs EXT_AUTO

In traditional industrial motor logic, manual intervention almost universally overrides automated sequencing to protect personnel and machinery:

Safety Interlocking Precedence: EXT_MAN = 1 typically forces the block into manual control, ignoring Auto_ON = 1 commands from upper-level batch sequencers or interlocking charts.
Override Behavior: In most legacy libraries, EXT_AUTO = 1 does NOT override an active EXT_MAN = 1. For the motor to run automatically via Auto_ON, EXT_MAN must return to 0, allowing EXT_AUTO to set the internal mode flip-flop to Automatic.
Faceplate vs Logic Commands: In custom blocks, EXT_MAN often represents an external hardwired field switch or DCS override that locks out faceplate commands from the WinCC operator station.

Comparison: Legacy MFL Block vs Modern APL MotL

The following table contrasts legacy custom motor block architectures with standard APL MotL:

Architectural FeatureLegacy Custom Block (FB 750)Standard APL Motor (MotL / FB 1850)Mode Selection MechanismDirect boolean pins (EXT_MAN, EXT_AUTO)Structured interconnection pins (AutModLi, ManModLi)Priority GovernanceFixed internal code logicParameterized via Feature bits (e.g. Feature.Bit0)Automatic Run CommandSimple boolean (Auto_ON)Dynamic command inputs (AutModOp, StartAut)Signal Status SupportStandard BOOL (No quality code)Structured STRUCT with value and Quality Code (ST)OS Faceplate IntegrationCustom proprietary .pdlModular standardized APL popups (@PG_MotL_...)

Recommendation: Migrate proprietary blocks to standard APL blocks during plant revamps to reduce lifecycle engineering costs and eliminate unverified code dependencies.

Verification

Verify custom block truth-table logic using S7-PLCSIM:
1. In the test CFC chart, set EXT_MAN = 1 and verify the block reports manual status (ManAct = 1).
2. Force Auto_ON = 1 and EXT_AUTO = 1 while keeping EXT_MAN = 1.
3. Observe motor run outputs; confirm that the motor remains stopped and does not start automatically.
4. Set EXT_MAN = 0 while keeping EXT_AUTO = 1 and Auto_ON = 1; confirm that the motor transitions to Automatic mode and starts cleanly.

Limitations and Operational Precautions

Key precautions when working with custom legacy blocks:
- Modifying custom block interfaces in a running plant requires a CPU STOP download if interface structures or instance DB lengths change.
- Never assume two different custom motor blocks in the same facility share identical priority rules; always verify each FB author and version.
- When migrating to newer PCS 7 releases, custom blocks may experience timing anomalies if compiled without validating organization block execution groups.

Engineer FAQ

Why did the previous engineering team use FB 750 instead of standard blocks?

Integrators often used custom blocks to replicate legacy DCS behaviors, interface with proprietary third-party motor control centers, or reduce Process Object licensing costs in older versions.

Can I view the internal logic of an FB if the source code is missing?

If the block is not protected with KNOW_HOW_PROTECT, you can open the compiled FB directly from the offline block folder in the STL/LAD editor to inspect the logic.

How does APL MotL handle manual and automatic mode priority?

In APL MotL, ManModLi takes precedence over AutModLi by default, but this priority can be reversed by setting Feature.Bit0 (Set mode via input or operator).