PLC Simulator Guide for Beginners

Posted on by

A plc simulator lets a beginner create control logic, apply virtual input signals, and observe simulated outputs without connecting a physical controller. The practical exercise below uses a motor start sequence with a stop circuit, an overload fault, a seal-in interlock, and a timer.

The same sequence also shows where a PLC differs from a remote terminal unit (RTU). A PLC normally performs fast local control, while an RTU connects remote field equipment to a supervisory system and may also execute limited local logic.

PLC simulator: local control, inputs, and outputs

A PLC is a programmable controller that reads field inputs, evaluates logic, and changes outputs. Inputs can include push buttons, selector switches, proximity sensors, pressure switches, and fault contacts. Outputs can operate contactors, valves, indicator lamps, relays, and other control devices.

A simulator recreates some of these signals in software. A virtual push button can represent a digital input, while a simulated motor or lamp can represent an output. Depending on the product, the simulator may provide a ladder editor, a virtual control panel, a process model, or a connection to a PLC development environment.

The main roles are distinct:

  • PLC: executes the control program and exchanges signals with physical or simulated I/O.
  • Simulator: supplies virtual inputs and displays virtual outputs so the logic can be tested.
  • Process model: represents equipment behavior, such as a motor changing from stopped to running after an output turns on.

A simulator is useful for checking whether the sequence is logically complete. It can reveal an output that never turns on, a stop condition that has been omitted, or a timer that has the wrong preset. It also makes it possible to test unusual combinations, such as pressing Start while a fault is active.

Simulation does not prove that a physical controller will behave identically. Scan timing, input filtering, output response, network delays, electrical noise, wiring faults, module behavior, and safety functions can differ. A virtual motor turning on confirms the simulated logic path, not the safety or timing performance of a specific installed machine.

Core PLC code: scan cycles, tags, and logic elements

The basic PLC scan explains why plc code behaves differently from a conventional one-time script. A typical scan has three stages:

  1. The controller reads input states from its input modules or communication interface.
  2. The program evaluates instructions in its configured order.
  3. The controller updates physical or virtual outputs.

The process then repeats. A short scan time allows the controller to respond quickly, but the exact scan time depends on the controller, program size, communications, I/O configuration, and instruction types. Some platforms handle certain I/O or tasks differently, so the standard read-execute-write description is a useful model rather than a guarantee for every controller.

Tags are names assigned to values. For the exercise, tags can include:

  • Start_PB: a normally open start push button.
  • Stop_OK: true when the stop circuit is healthy. It becomes false when Stop is pressed.
  • Overload_OK: true when the motor overload has not tripped.
  • Reset_PB: a reset command for a stored fault.
  • Motor_Run: the command sent to the motor contactor.
  • Fault_Latched: an internal status bit that remains true until reset.
  • Run_Timer: a timer that confirms the motor command has remained active.

In ladder logic, a contact tests a Boolean condition. A normally open instruction passes logic when its tag is true; a normally closed instruction passes logic when its tag is false. The visual symbol does not necessarily describe the physical device. For example, a tag called Stop_OK can use a normally open logic contact because the tag is true during healthy operation.

A coil writes a result to an output or internal tag. A standard coil usually reflects the rung result during each scan. A set or reset instruction can store a state, but stored states require a clear reset path and careful fault handling.

A timer measures an accumulated interval while its input condition remains true. A common on-delay timer, or TON, changes its done bit to true after the preset time has elapsed. In a simulator, a three-second timer may complete according to simulated time, software execution, or a user-controlled clock.

An interlock prevents an operation unless required conditions are true. In this exercise, the motor cannot run unless Stop_OK, Overload_OK, and the fault condition all permit operation. Interlocks should be evaluated in the logic that controls the output, not merely displayed as status information.

The online state is the live monitoring view in which the editor shows current tag values, energized contacts, timer progress, and output states. In a simulator, online state normally means that the program is connected to the virtual controller or runtime. It does not necessarily mean that the program is connected to real equipment.

Build and run a simulated control sequence

The following exercise uses a motor that starts with a push button, stays on after the button is released, stops when Stop is pressed, and drops out when an overload occurs. A timer confirms that the motor command has remained active for three seconds.

1. Create the tags and initial conditions

Use Boolean tags for the buttons, permissives, internal states, and outputs. Set the timer preset to 3 seconds. Before starting the test, set these initial conditions:

  • Start_PB = false
  • Stop_OK = true
  • Overload_OK = true
  • Reset_PB = false
  • Fault_Latched = false
  • Motor_Run = false
  • Run_Timer accumulated time = 0 seconds
  • Run_Timer done bit = false

The simulated motor and run lamp should both be off. A ready lamp, if included, should be on because the stop circuit and overload condition are healthy.

2. Enter the control logic

Use a fault rung that stores a fault when the overload becomes unhealthy:

  • Set Fault_Latched when Overload_OK is false.
  • Reset Fault_Latched when Reset_PB is true and Stop_OK is true.

Use a motor rung with a seal-in path. The logical relationship is:

Motor_Run = (Start_PB OR Motor_Run) AND Stop_OK AND Overload_OK AND NOT Fault_Latched

The Start_PB contact provides the initial start command. The Motor_Run contact in parallel with it provides the seal-in path, allowing the motor command to remain true after the operator releases Start. Stop_OK, Overload_OK, and the non-fault condition are series interlocks. If any one becomes false, Motor_Run must turn off.

Connect the motor output and run lamp to Motor_Run. Then connect Run_Timer as an on-delay timer with Motor_Run as its input and a three-second preset. Use the timer done bit for a Run_Confirmed lamp or status tag.

3. Run the normal sequence

  1. Start the simulator and place the controller in its online state.
  2. Confirm that all initial tag values match the list above.
  3. Set Start_PB to true for at least one scan, then return it to false.
  4. Watch Motor_Run. It should turn on and remain on after Start_PB returns to false.
  5. Observe Run_Timer. Its accumulated value should increase while Motor_Run is true.
  6. After approximately three seconds, Run_Timer done should turn true and Run_Confirmed should turn on.
  7. Set Stop_OK to false. Motor_Run, the motor output, the run lamp, and Run_Confirmed should turn off.

The expected states can be checked as follows:

  • Idle and healthy: Motor_Run off, motor output off, Run_Timer reset, and ready status on.
  • Start pressed: Motor_Run on during the next program evaluation, motor output on, and timer accumulating.
  • Start released: Motor_Run remains on through the seal-in contact, provided every interlock remains healthy.
  • Three seconds elapsed: Run_Timer done is on and Run_Confirmed is on.
  • Stop pressed: Stop_OK becomes false, the motor command drops out, and the timer is no longer complete.
  • Overload trip: Overload_OK becomes false, Motor_Run turns off, and Fault_Latched turns on.
  • After the overload clears: Motor_Run remains off because Fault_Latched is still on.
  • After a valid reset: Fault_Latched clears, the system returns to a healthy ready state, and a new Start command is required.

4. Force inputs and test failure behavior

Use the simulator’s force or override feature to test conditions that are difficult to reproduce with ordinary buttons. Record the original value before forcing a tag, and remove every force when the test is complete.

  • Force Start_PB false: verify that the motor cannot start from a false start command.
  • Start, then release Start_PB: verify that the seal-in path maintains Motor_Run.
  • Force Stop_OK false while running: verify that the motor turns off on the next relevant logic evaluation.
  • Force Overload_OK false while running: verify that the motor turns off and Fault_Latched becomes true.
  • Return Overload_OK true without resetting: verify that the motor does not restart automatically.
  • Force Reset_PB true while Stop_OK is false: verify that the reset is blocked if that condition is part of the design.
  • Restore Stop_OK and apply Reset_PB: verify that the fault clears and the motor remains off until Start is pressed again.
  • Change the timer preset: verify that Run_Confirmed follows the new value, but do not treat the simulated timing as proof of physical motor acceleration or process timing.

Failure checks should include a stuck-on output, an output that restarts after a fault, a timer that does not reset when its input goes false, and a fault bit that cannot be cleared through the intended reset path. These checks distinguish a complete sequence from one that only works during the normal case.

What is an RTU? Compare the same sequence remotely

For readers asking what is rtu, an RTU is a remote terminal unit: a field controller designed to gather signals from equipment at a remote site and exchange data with a supervisory system. It commonly handles digital and analog inputs, digital outputs, local status, alarms, timestamps, and communications over a telemetry network.

The PLC and RTU can both use Boolean logic, timers, tags, and interlocks. The important difference is the control context:

  • PLC: usually provides fast, continuous local control for a machine, skid, production cell, or process area.
  • RTU: usually interfaces with geographically distributed equipment and communicates status or commands to a central system.
  • PLC simulator: usually tests controller logic and virtual process responses without reproducing every physical I/O and network characteristic.

The motor exercise can be mapped to an RTU by assigning the field signals to remote tags:

  • Start_PB and Stop_OK become digital inputs at the remote station.
  • Overload_OK comes from the motor starter or protection device.
  • Motor_Run becomes a remote digital output to the starter.
  • Fault_Latched and Run_Confirmed become status points sent to the supervisory system.
  • Reset_PB may come from a local panel or an authorized supervisory command.

There are two common designs. The RTU can execute the motor sequence locally, allowing the motor to stop when a local stop or overload signal changes even if communications with the control center are unavailable. Alternatively, the supervisory system can issue a start command while the RTU applies local permissives and safety-related interlocks.

For a remote implementation, the design should define communication-loss behavior explicitly. A lost link might inhibit new starts, retain a safe existing state, or stop the motor, depending on the process requirements. A watchdog, command timeout, stale-data flag, and local fail-safe state can help prevent an old remote command from remaining active indefinitely.

An RTU simulator may model remote tags and communication status, but it may not reproduce radio delays, packet loss, protocol retries, timestamp quality, power interruptions, field wiring, or the exact behavior of a selected RTU. Likewise, a PLC simulator does not establish that the completed application meets the response time, electrical, or safety behavior of the physical installation. The simulated test confirms the intended logic states; hardware and site testing are needed to validate the complete control system.