JoeGuardian Automation

2. Moore vs Mealy State Machines in PLC Programming

When programmers begin learning state machines, two names appear very quickly:

• Moore Machine
• Mealy Machine

Both are finite state machine models, but they differ in one very important way:

A Moore machine determines outputs from the current state, while a Mealy machine determines outputs from the current state and the current inputs.

That difference may seem small.

In industrial automation, however, it can significantly affect:

• machine response,
• ladder structure,
• troubleshooting,
• fault handling,
• HMI behavior,
• and overall program architecture.

This article explains both models using practical PLC examples.

Quick Review: What Is a State Machine?

A state machine describes the operating condition of a machine.

For example, an industrial door might use:

0   Idle
10  Opening
20  Fully_Open
30  Closing
40  Fully_Closed
50  Stopped
60  Faulted

The machine exists in one state and transitions to another when defined conditions become true.

For example:

Fully_Closed
      |
      | Open_Request
      v
Opening

Then:

Opening
      |
      | Open_Limit
      v
Fully_Open

Where Moore and Mealy differ is primarily in how outputs are generated while those states are active.

Moore State Machine

A Moore state machine defines its outputs based only on the current state.

Conceptually:

Output = f(State)

The current input conditions may determine when the state changes, but they do not directly determine the output.

Moore Example: Warehouse Door

Suppose the door is in:

Machine_State = 10

where:

10 = Opening

The command is generated simply because that state is active:

Opening
   |
   v
CMD_Open = TRUE

Conceptually in Ladder:

EQU Machine_State 10
----------------------------( CMD_Open )

Similarly:

EQU Machine_State 30
----------------------------( CMD_Close )

where:

30 = Closing

The command depends only on the state.

Moore Machine Architecture

The behavior looks like:

INPUTS
   |
   v
TRANSITION LOGIC
   |
   v
CURRENT STATE
   |
   v
OUTPUTS

For example:

Open_Request
     |
     v
Transition to Opening
     |
     v
State = Opening
     |
     v
CMD_Open

The transition logic handles the input.

The state handles the output.

That separation is one of Moore’s biggest strengths.

Why Moore Is Easy to Troubleshoot

Suppose a technician sees:

CMD_Open = TRUE

If the program uses a Moore architecture, the troubleshooting question is straightforward:

What state is active?

If:

Machine_State = Opening

then:

CMD_Open = TRUE

is expected.

The relationship is direct.

This makes the program very readable.

Moore Example with Indicators

Moore logic works very naturally for machine status indicators.

For example:

State = Fully_Open

produces:

Pilot_Open = TRUE

Likewise:

State = Closing

produces:

Pilot_Closing = TRUE

This is a strong Moore-style application because indicators describe the current machine state.

Advantages of Moore State Machines

Moore machines offer several useful benefits.

Predictable Outputs

The state determines the output.

That means:

State = Opening

always corresponds to the same command behavior.

Easier Troubleshooting

The technician can inspect:

Machine_State

and immediately understand which commands should be active.

Cleaner Program Structure

Transition logic and output logic can be separated.

For example:

R04_State_Transitions

R05_State_Commands

That makes the PLC program easier to maintain.

Stable Machine Behavior

Because outputs only change when states change, outputs are less likely to fluctuate because of rapidly changing input conditions.

This can be especially useful for commands that should remain stable during a machine phase.

Limitation of Moore Machines

The biggest limitation is response timing.

Suppose the machine is:

Closing

and suddenly:

PhotoEye_Blocked = TRUE

A pure Moore model would normally need to transition into another state before the output behavior changes.

For example:

Closing
   |
   | PhotoEye_Blocked
   v
Stopped

Then:

State = Stopped

causes:

CMD_Close = FALSE

This is perfectly valid.

However, some industrial conditions require immediate reaction to an input.

That is where Mealy behavior becomes useful.

Mealy State Machine

A Mealy machine allows outputs to depend on:

Current State
+
Current Input

Conceptually:

Output = f(State, Input)

This allows a machine to react immediately to changing inputs without necessarily waiting for a state transition.

Mealy Example: Warehouse Door

Assume:

Machine_State = Closing

Normally:

CMD_Close = TRUE

But now:

PhotoEye_Blocked = TRUE

The command could immediately become:

CMD_Close = FALSE

based on:

State = Closing
AND
PhotoEye_Blocked = FALSE

Conceptually:

EQU Machine_State 30
XIO PhotoEye_Blocked
----------------------------( CMD_Close )

Now the command depends on both:

Current State
AND
Current Input

That is Mealy-style behavior.

Mealy Machine Architecture

A simplified Mealy architecture looks like:

CURRENT STATE
      |
      +--------+
      |        |
      v        v
    INPUTS   CONDITIONS
      \        /
       \      /
        v    v
        OUTPUT

The output is directly influenced by real-time conditions.

Why Mealy Can Respond Faster

Suppose:

State = Closing

and the photoeye changes from:

FALSE

to:

TRUE

With Mealy-style logic, the output can react in the same PLC scan.

For example:

Closing
AND
PhotoEye_Clear
--------------------> CMD_Close

When the photoeye becomes blocked:

PhotoEye_Clear = FALSE

and the output command disappears immediately.

No intermediate state transition is required first.

Mealy Example: Conveyor

Consider a conveyor operating in:

State = Running

The motor command might depend on:

State = Running
AND
Downstream_Clear

If the downstream photoeye becomes blocked:

Downstream_Clear = FALSE

the motor command turns off immediately.

That is a classic Mealy-style response.

Advantages of Mealy State Machines

Fast Response to Inputs

Outputs can react immediately to:

Sensors
Interlocks
Process Conditions
Requests

without first requiring a new state.

Fewer States May Be Required

A Moore design may require separate states for certain conditions.

For example:

Running
Blocked
Waiting

A Mealy implementation might remain in:

Running

while output behavior changes based on an input.

Good for Event-Driven Behavior

Mealy logic works well for conditions such as:

Photoeye blocked
Part detected
Pressure lost
Downstream unavailable
Operator release

where immediate response is useful.

Limitation of Mealy Machines

Mealy behavior can become harder to troubleshoot.

Consider this command:

State = Running
AND
Sensor_A
AND
NOT Sensor_B
AND
Permissive_C
AND
Interlock_D
----------------------------( Motor_Command )

Now knowing:

State = Running

is not enough.

The technician must also inspect several inputs.

The output no longer corresponds directly to the state.

This can make machine behavior less obvious.

Moore vs Mealy: Industrial Comparison

Example 1: Door Opening Command

Moore Version

State = Opening
--------------------> CMD_Open

The output is purely state-driven.

Mealy Version

State = Opening
AND
Open_Permissive
AND
NOT Motor_Overload
--------------------> CMD_Open

The output depends on state plus current conditions.

Example 2: Conveyor

Moore Version

State = Running
--------------------> Conveyor_CMD

If downstream becomes blocked, transition:

Running
   |
   | Downstream_Blocked
   v
Stopped

Then the command turns off because the state changed.

Mealy Version

State = Running
AND
Downstream_Clear
--------------------> Conveyor_CMD

If the downstream condition becomes false, the command immediately drops.

Example 3: Indicator Light

For indicators, Moore is usually more natural.

For example:

State = Faulted
--------------------> Red_Pilot

Why?

Because the light represents the machine state.

It does not need to depend directly on dozens of inputs.

Example 4: Motion Command

Motion commands often benefit from hybrid behavior.

For example:

State = Closing

generates:

State_Close_CMD

Then:

State_Close_CMD
AND
Close_Permissive
AND
NOT Interlock_Active
AND
NOT Motor_Fault
--------------------> Final_Close_CMD

This separates:

State Intent

from:

Execution Permission

This is very useful industrially.

Why Pure Moore Is Rare in Real Machines

A completely pure Moore machine can become impractical in industrial automation.

Consider all the conditions that may need immediate influence:

Emergency Stop
Safety Gate
Photoeye
Motor Overload
Pressure Switch
Drive Fault
Downstream Ready
Product Jam

Creating a new state for every possible input condition would produce too many states.

For example:

Running
Running_NoPressure
Running_PEBlocked
Running_DownstreamBlocked
Running_MotorFault
Running_SafetyOpen

That would quickly become unmanageable.

Why Pure Mealy Can Also Become Messy

The opposite extreme is also problematic.

Suppose every output depends directly on:

State
Inputs
Permissives
Interlocks
Faults
Operator Requests
Sensors

Then outputs become complex logic expressions.

Example:

State = Running
AND
Auto_Mode
AND
Safety_OK
AND
Pressure_OK
AND
Downstream_Ready
AND
NOT Jam
AND
NOT Motor_Fault
AND
Product_Enable
--------------------> Motor_CMD

Technically this may work.

But now the state machine has lost much of its diagnostic simplicity.

The Industrial Solution: Hybrid State Machine

For many PLC applications, the best approach is a hybrid.

The state machine determines intent.

Other logic determines whether that intent is allowed to become a real command.

For example:

State = Opening
--------------------> State_CMD_Open

Then:

State_CMD_Open
AND
Open_Permissive
AND
NOT Open_Interlock
AND
NOT Fault_Active
--------------------> CMD_Open

Finally:

CMD_Open
--------------------> Physical_Output

This architecture provides a clean separation.

State Intent vs Final Command

This distinction is extremely important.

The state machine says:

The machine wants to open.

That can be represented by:

State_CMD_Open

The permissive and interlock logic says:

Is opening currently allowed?

Then the final command becomes:

CMD_Open

This is a strong industrial design pattern.

Example Architecture

A structured PLC program could look like:

R00_Input_Mapping

R01_Requests

R02_Permissives

R03_Interlocks

R04_State_Transitions

R05_State_Commands

R06_Final_Commands

R07_Feedback_Diagnostics

R08_Faults

R09_Alarms

R10_HMI_Status

R11_Output_Mapping

The state machine does not need to perform every task itself.

Instead, it becomes one component of the overall control architecture.

Troubleshooting a Moore Machine

Suppose:

Motor_CMD = FALSE

The first question might be:

What is Machine_State?

If:

Machine_State != Running

then the command is expected to be off.

The technician then investigates why the machine did not transition into Running.

This creates a very clean diagnostic path.

Troubleshooting a Mealy Machine

Suppose:

Machine_State = Running

but:

Motor_CMD = FALSE

The technician must inspect the additional conditions:

Downstream_Clear
Motor_Ready
Pressure_OK
Interlock_Clear

The state alone does not explain the command.

Troubleshooting a Hybrid Machine

A hybrid design can preserve the best of both approaches.

For example:

Machine_State = Running

therefore:

State_CMD_Motor = TRUE

but:

Final_Motor_CMD = FALSE

Now the technician knows:

1. The state machine is requesting motor operation.
2. Something downstream is blocking execution.

Then inspect:

Permissive
Interlock
Fault

This is extremely useful diagnostically.

A Practical Troubleshooting Pattern

For a hybrid machine:

Current State
      |
      v
State Command
      |
      v
Permissive
      |
      v
Interlock
      |
      v
Final Command
      |
      v
Physical Output
      |
      v
Feedback

When the equipment fails to operate, check this chain from top to bottom.

For example:

State = Closing       TRUE
State_CMD_Close       TRUE
Close_Permissive      TRUE
Close_Interlock       FALSE
Final_Close_CMD       FALSE

The problem is immediately isolated to the interlock layer.

Which Should You Use?

Use Moore-style behavior when the output represents the machine state.

Good examples:

State indicators
Mode indicators
Current phase status
HMI machine status
State commands

Use Mealy-style behavior when an output must react immediately to an input.

Good examples:

Photoeye stop
Downstream blocking
Process inhibit
Motion interlock
Sensor-dependent commands

For most real machines:

Use Moore for normal state intent and Mealy-style logic for permissives, interlocks, and immediate process reactions.

That creates a hybrid architecture.

Important Note About Safety

Mealy-style PLC logic should not be confused with machine safety.

For example:

State = Closing
AND
Safety_OK
--------------------> Motor_CMD

may be useful standard-control logic.

However, safety functions such as:

E-Stop
Light Curtain
Guard Interlock
Safe Torque Off

must still use the appropriate safety-rated architecture.

A standard PLC state machine should never be considered a replacement for required functional safety systems.

Moore and Mealy in Studio 5000

In Studio 5000, both models are relatively easy to implement.

A Moore-style state command:

EQU Machine_State 30
----------------------------( State_CMD_Close )

A Mealy-style final command:

State_CMD_Close
Close_Permissive
XIO Close_Interlock
XIO Motor_Fault
----------------------------( CMD_Close )

This combination is extremely practical.

Why Naming Matters

Clear tag naming helps reveal the architecture.

For example:

State_CMD_Close

means:

The state machine wants to close.

While:

CMD_Close

means:

The final control logic allows closing.

And:

DO_Motor_Close

means:

The physical output is being driven.

This creates three clearly defined layers:

State Intent
Final Command
Physical Output

That separation makes troubleshooting much easier.

Example: Complete Warehouse Door Flow

Consider the door in:

Machine_State = Closing

The state command becomes:

State_CMD_Close = TRUE

Then evaluate:

Close_Permissive
PhotoEye_Clear
Motor_Healthy
Safety_OK

If all conditions are valid:

CMD_Close = TRUE

Then:

DO_Close = TRUE

Feedback should confirm motion:

Motor_Feedback = TRUE

Conceptually:

Closing State
     |
     v
State_CMD_Close
     |
     v
Close Permissive
     |
     v
PhotoEye Clear
     |
     v
No Fault
     |
     v
CMD_Close
     |
     v
DO_Close
     |
     v
Motor Feedback

This is much closer to how a professional industrial control program should be structured.

Final Comparison

Moore and Mealy are not competing philosophies where one must always replace the other.

They solve different problems.

Moore provides:

Predictability
Clear state behavior
Easy diagnostics
Stable outputs

Mealy provides:

Responsiveness
Input-dependent behavior
Fast process reaction
Flexibility

In practical industrial automation, combining them is often the best solution.

Final Thoughts

The most important distinction is simple:

MOORE

Output = State

while:

MEALY

Output = State + Input

But industrial PLC programming adds another important idea:

STATE
  |
  v
INTENT
  |
  v
PERMISSIVES / INTERLOCKS
  |
  v
FINAL COMMAND

This hybrid structure allows the state machine to remain clear while the control system remains responsive to changing process conditions.

That is often the most practical architecture for real industrial machinery.

In the next article, we will take the next step:

Hybrid State Machines in PLC Programming

We will examine how state logic, permissives, interlocks, commands, feedback, and fault logic can be combined into a professional industrial control architecture.