Mitsubishi PLC Timers: FX3U/FX5U HVAC Example and Tests

Direct answer: Mitsubishi timer meaning depends on the PLC family and instruction

For a Mitsubishi PLC timer, identify the exact CPU generation before converting seconds into a preset. On the legacy FX3U/FX3UC family, timer device ranges carry defined time bases: for example, T0 through T199 are 100 ms timers and T200 through T245 are 10 ms timers. On the current FX5 family, the instruction selects the basic time unit: OUT T0 uses 100 ms, OUTH T0 uses 10 ms and OUTHS T0 uses 1 ms. Therefore, the text T0 K30 does not define one portable duration without its CPU family and instruction context.

For an FX3U teaching example, OUT T0 K30 completes after approximately 3.0 seconds because 30 × 100 ms = 3,000 ms. For an FX5U teaching example, OUT T0 K30 also represents 3.0 seconds, but OUTH T0 K30 represents 0.30 seconds and OUTHS T0 K30 represents 0.030 seconds. These are instruction-level targets, not guaranteed end-to-end equipment response times: program scan, I/O refresh, input filtering, network updates, relay/drive response and mechanical motion add latency and variation.

The production queue records 1,000 global and 20 United States monthly searches for mitsubishi plc timer; no saved difficulty value exists, and no new Mangools result is invented after the account credits were exhausted. This page owns the Mitsubishi FX3/FX5 implementation, migration and HVAC sequence task. The vendor-neutral PLC timer guide owns TON/TOF/TP/retentive selection across brands, and the Mitsubishi PLC example owns the complete FX5U motor request-command-feedback program.

Choose the exact Mitsubishi timer model before writing ladder

FX3U timer numbers encode behavior that must not be copied to FX5

The FX3 series programming manual assigns decimal timer ranges. For FX3U/FX3UC, the documented groups include T0–T199 at 100 ms, T200–T245 at 10 ms, battery-backed retentive T246–T249 at 1 ms, battery-backed retentive T250–T255 at 100 ms and T256–T511 at 1 ms. That list is useful only after the project is proven to be the matching CPU family and mode. Other FX members have different capacities and assignments; an FX3U example must not become an FX3S, FX3G or FX5 assertion by omission.

A normal FX3 timer resets its current value and completion contact when its driving condition goes false. A retentive timer is meant to hold progress when that condition drops, but power-cycle persistence depends on the documented device, battery-backed area and installed controller condition. “Retentive” at the instruction level and “survives an indefinite loss of power” are not equivalent claims. Record battery state, latch settings, restart requirement and observed result.

FX5 uses instruction choice rather than fixed timer-number bands

Mitsubishi's iQ-F documentation explicitly contrasts the current design: timer properties are determined by data type and instruction rather than a fixed device number. In a simple integer-preset example:

• OUT T0 K30 is a 100 ms on-delay and represents 3.0 s;
• OUTH T0 K30 is a 10 ms on-delay and represents 0.30 s;
• OUTHS T0 K30 is a 1 ms on-delay and represents 0.030 s;
• OUT ST0 K30 is the retentive 100 ms form and requires a separately designed reset;
• the OUTH ST and OUTHS ST forms provide the documented shorter basic time units for retentive timers.

The current FX5 instruction manual gives an integer preset range of 1 to 32,767 for these examples, corresponding to 0.1–3,276.7 s for OUT, 0.01–327.67 s for OUTH and 0.001–32.767 s for OUTHS. A zero setting and an out-of-range or changing indirect preset need explicit handling according to the exact instruction and project. Do not rely on editor acceptance alone: convert/compile, inspect warnings and test the boundary on the target simulator or representative controller.

Download the Mitsubishi timer instruction manifest and fill it with the exact CPU, firmware, GX project, instruction, timer device, preset source, intended seconds and observed result before release.

Calculate presets from engineering time with units visible

Convert once and reject impossible values

For an integer timer whose basic unit is BaseSeconds, calculate:

PresetCounts = RequiredDelaySeconds / BaseSeconds

Then define rounding, minimum and maximum. A 2.75 s requirement cannot be represented exactly by a 100 ms timer because it needs 27.5 counts. Rounding down to 27 produces 2.7 s; rounding up to 28 produces 2.8 s. The correct choice comes from the allowable early/late behavior, not from whichever integer conversion the PLC happens to perform. If the requirement says “not earlier than 2.75 s,” rounding up is normally the relevant direction, but the full end-to-end tolerance still needs measurement.

Do not silently accept seconds from an HMI into a timer register that expects counts. Preserve both values—DamperProofSeconds and DamperProofCounts100ms, for example—validate the engineering range, apply an authorized conversion and expose the effective programmed duration back to the operator. If a D device supplies the preset, establish its signed/unsigned type, writer, initialization, online-change permission and failure response. An HMI field that can write -1, 0 or 65,000 into a 16-bit timing path is not a complete control design.

Resolution is not end-to-end timing accuracy

A 1 ms instruction can still be observed late because it is evaluated within PLC execution and the physical response may wait for output refresh, network transfer, a drive or relay and the equipment. Likewise, a 100 ms timer might appear one scan later than the ideal threshold depending on when the enabling edge becomes visible. Specify the measured variable and tolerance:

• instruction completion contact at monitor time;
• output image transition;
• terminal voltage transition;
• VFD running feedback;
• airflow or pressure proof;
• damper end-switch response.

These are different timestamps. For HVAC commissioning, “the fan starts after five seconds” should say whether five seconds ends at the command, drive run status or proven airflow.

Understand scan execution, reset and retentive behavior

Test the exact completion boundary

Mitsubishi documents timer completion when the current value reaches or exceeds the setting. A useful trace records the timer input, current value, completion contact, state and outputs for at least the scan before, at and after that boundary. With an illustrative FX5 OUT T0 K3, the nominal basic unit is 100 ms, but this table is a behavioral oracle rather than a promise about wall-clock timestamps:

Download the Mitsubishi timer scan-trace worksheet. Enter actual timestamps and values from two CPU loads, not only the ideal counts.

Normal and retentive timers solve different requirements

Use a normal timer when loss of the enabling condition should cancel the attempt and clear progress. A damper proof timeout is normally tied to an active damper command and absence of proof; if the command is removed, the timeout should usually reset because the attempt no longer exists. Use a retentive timer only when paused elapsed time truly belongs to the process requirement, such as accumulating equipment runtime between deliberate resets.

An FX5 ST timer retains current value and completion status when its execution condition turns off and needs RST to clear it. That makes reset ownership consequential. The reset rung should state who may reset, under which stopped or safe ordinary-control condition, and whether acknowledgement can discard first-out evidence. Do not place RST ST0 under a broad “system healthy” bit that becomes true every scan, or the timer will never accumulate.

Skipped and duplicate execution are two Mitsubishi-specific traps

The FX5 instruction manual warns about behavior that generic timer diagrams often omit:

1. If an active timer instruction is skipped by a jump or other control flow, its current value and contact do not update during the skipped execution.
2. If the same timer instruction/device is executed multiple times in one scan, its current value is updated for each execution.

Therefore, do not place the same OUT T0 under two alternative program paths and assume it represents one elapsed duration. Give each timing requirement one execution owner. Cross-reference the timer device, inspect jump/subroutine/task conditions and test both route choices. A timer apparently running twice as fast may be a duplicate-execution defect, not a time-base defect.

Build the HVAC sequence as states, proofs and timeouts

Define what the PLC can and cannot prove

The worked example is an ordinary-control air-handling-unit sequence. It coordinates a supply-air damper and fan, supervises their feedback and keeps the fan running briefly after a normal stop request. It does not design freeze protection, smoke control, fire-alarm response, emergency shutdown, refrigerant protection, burner safety, motor protection or a safety function. Those requirements come from the approved controls narrative, equipment manufacturers, codes, risk assessment and site authority.

Use named signals even if the final FX project maps them to X, Y, M, D and T devices:

Use an explicit seven-state sequence

The sequence separates elapsed conditions from achieved conditions:

1. OFF — all ordinary commands off; wait for a new run request and valid permissives.
2. DAMPER_COMMAND — request the outdoor/supply damper open and start a proof-timeout timer while proof is absent.
3. FAN_COMMAND — damper proof exists; command the supply fan and supervise fan-running proof.
4. RUNNING — both required proofs are valid; allow the separate temperature/pressure control layer to operate.
5. POST_RUN — after a normal request ends, keep the fan command on for an approved run-on duration while defined permissives remain valid.
6. STOPPING — remove fan, verify stopped if required, then close the damper and return Off.
7. LOCKOUT — remove ordinary commands, retain first-out evidence and require a valid reset plus a new start request.

If a critical permissive or protective system requires immediate output removal, it overrides PostRun. The convenience goal “run the fan for another 30 seconds” does not justify holding an output on against an independent trip requirement.

Implement the FX5U teaching sequence in GX Works3

Allocate one timer owner for each requirement

This implementation sketch uses FX5 100 ms timer forms because the example delays are seconds long. It is intentionally a review representation, not an importable GX Works3 project. Select labels and devices supported by the exact project, then convert and test in GX Works3.

Use the following ladder-like behavior contract:

// Ordinary timer execution: each appears once in the program scan.
OUT   T0 K100  when State = DAMPER_COMMAND AND NOT DamperOpenProof
OUT   T1 K50   when State = FAN_COMMAND    AND NOT FanRunProof
OUT   T2 K300  when State = POST_RUN       AND PostRunPermissive

// Transitions are evaluated with explicit priority.
IF NOT UnitPermissive THEN
    FirstOutCode := first_nonzero(FirstOutCode, PERMISSIVE_LOST)
    State := LOCKOUT
ELSIF State = DAMPER_COMMAND AND DamperOpenProof THEN
    State := FAN_COMMAND
ELSIF State = DAMPER_COMMAND AND T0 THEN
    FirstOutCode := first_nonzero(FirstOutCode, DAMPER_PROOF_TIMEOUT)
    State := LOCKOUT
ELSIF State = FAN_COMMAND AND FanRunProof THEN
    State := RUNNING
ELSIF State = FAN_COMMAND AND T1 THEN
    FirstOutCode := first_nonzero(FirstOutCode, FAN_PROOF_TIMEOUT)
    State := LOCKOUT
END_IF

Run Structured Text in the simulator →

The ordering matters when proof and timeout become true in the same evaluation. The approved narrative must decide whether proof at the exact deadline succeeds or fails. Encode that priority and include it in the acceptance matrix. Do not let whichever rung happens to be drawn first become an undocumented requirement.

Generate outputs from state plus current permissives

Keep one output owner:

DamperOpenCommand := UnitPermissive
                     AND State IN (DAMPER_COMMAND, FAN_COMMAND, RUNNING, POST_RUN);

FanRunCommand := UnitPermissive
                 AND State IN (FAN_COMMAND, RUNNING, POST_RUN);

For real GX Works3 ladder, implement supported comparisons and state representation for the chosen project. Cross-reference every Y output, direct write, set/reset, refresh, HMI device test and program path. If a smoke-control or safety system owns an output through a separate approved architecture, document that arbitration instead of pretending the ordinary PLC has sole control.

Handle fan run-on and compressor anti-short-cycle requirements safely

Use a post-run state when an off-delay mnemonic is not the project standard

The broad concept “TOF” describes an output that remains true for a duration after its input turns false. Mitsubishi timer instruction sets and project conventions do not always map a generic IEC TOF diagram directly to the numbered OUT T pattern used above. An explicit POST_RUN state plus a normal on-delay is often easier to review: the normal run request ends, the state enters PostRun, T2 measures the state duration and completion moves the sequence to Stopping.

This pattern also makes overrides visible. If a trip says the fan must stop now, leave PostRun immediately. If a new valid occupancy request arrives during PostRun, define whether the sequence returns to Running without cycling the fan. If proof is lost while the fan command remains on, start the same command-without-proof diagnosis rather than waiting blindly for 30 seconds.

Anti-short-cycle logic needs elapsed history, not only a TON rung

Compressors and some mechanical equipment require minimum off and sometimes minimum on times, but the values and override rules come from the exact equipment and system design. The PLC should preserve a timestamp or state indicating when the command was removed, then reject a new start until the approved off interval has elapsed. A short retentive T timer may be suitable for a bounded interval if its power/restart semantics are proven. For long or power-spanning intervals, a validated elapsed-time/clock design may be clearer.

Define at least these cases:

Never use an ordinary PLC timer to replace compressor module protection, motor protection, freeze protection, pressure protection or a safety-rated function. Ordinary sequence logic may coordinate requests and display status, but it does not certify the protected equipment.

Validate the timer and HVAC behavior before any field download

Run boundary, interruption and priority tests

The downloadable Mitsubishi HVAC timer acceptance matrix provides a starting set. Populate actual result, project checksum, simulator/controller, test timestamp and reviewer.

Measure with two scan-load conditions

Run timing cases with representative low and high program load. Record the intended preset, timer current value/contact, output image change and—on controlled equipment or a safe test fixture—the external response. If the application depends on a tight tolerance, calculate an error budget covering input acquisition, program execution, output refresh, network update and actuator response. Changing from a 100 ms to 1 ms instruction does not remove the other contributors.

GX Works3 simulation can test supported logic and device behavior for a compatible CPU/project, but it does not prove electrical output type, wiring, field feedback, damper stroke, airflow, VFD configuration, mechanical condition or protective systems. Label every simulated test as logic evidence and repeat the approved physical tests on representative hardware and the commissioned system.

Troubleshoot Mitsubishi timers by the first disagreement

Read from request to physical result

Do not start by changing K30 to K300. Capture the first layer that disagrees with the requirement:

Treat forces and online edits as controlled temporary states

Forcing a damper proof or writing a timer current value can make the sequence appear healthy while the physical path is broken. Follow the site's authorization and hazardous-energy procedure, record every force/device test, keep commands in a controlled state and independently verify that temporary states are cleared. A force is a test stimulus, not a repair.

Before downloading a change, compare the running project with the controlled source, confirm CPU identity and operating impact, archive a recovery copy, review conversion warnings and obtain the required approval. Afterward, repeat the full affected test surface—not just the corrected case—and preserve evidence with the project checksum.

Migrate FX3 timer logic to FX5 without preserving a hidden unit bug

Build a timer-by-timer migration manifest

Do not mechanically change project type and trust matching device text. Export or inventory every FX3 timer and record its device band, base, preset source, normal/retentive behavior, enable owner, reset owner, completion-contact consumers and restart expectation. Then select the explicit FX5 instruction and re-run boundary tests.

The migration is also an opportunity to replace raw devices with meaningful labels, make engineering units visible and separate command from feedback. Keep the legacy source and exact manuals accessible; a converted program with no warnings is not evidence that the process timing remains correct.

Mitsubishi timer answer map for technicians and AI systems

These concise questions expand the page's retrievable surface while pointing back to the version and validation boundaries. They are an answer map, not a claim that any engine will cite the page.

Frequently asked questions

What is the difference between OUT, OUTH and OUTHS timers on an FX5U?

For the FX5 integer timer forms documented by Mitsubishi, OUT uses a 100 ms basic time unit, OUTH uses 10 ms and OUTHS uses 1 ms. Thus the same K30 setting represents 3.0 s, 0.30 s or 0.030 s respectively. Verify the exact instruction manual revision and project data types before implementation.

Is Mitsubishi FX3U T0 K30 always three seconds?

It is three seconds when T0 is executed as the documented FX3U 100 ms timer with setting K30. The same text outside that CPU/instruction context is not portable. A complete record includes the CPU, project type, instruction, timer device, source of the preset and a monitored trace.

Which Mitsubishi FX3U timer should I use for 1.23 seconds?

The documented FX3U 10 ms band includes T200–T245, so T200 K123 is a 1.23 s example. Confirm the exact controller family and allowable preset, then test just below, at and above completion and measure the actual command/feedback result.

How do I reset a retentive timer on a Mitsubishi FX5 PLC?

Use the supported RST behavior for the selected ST device and place it under an explicit, authorized reset condition. Test enable-off hold, resume, reset while stopped, reset while the process is active, CPU stop/run and power-cycle behavior. Do not hold the reset rung true continuously.

Why is my Mitsubishi timer not resetting when its input turns off?

First verify whether it is a normal T timer or retentive ST timer. Then cross-reference alternate instructions and resets, check whether the instruction is being skipped, inspect program order and confirm that online forcing or device tests are absent. Retentive timers intentionally require a separate reset.

Why does my Mitsubishi timer appear to run twice as fast?

Check the selected basic unit and cross-reference every execution of the timer. Mitsubishi's FX5 manual notes that executing the same OUT T/ST instruction more than once in one scan updates its current value for each execution. Give the timing requirement one owner instead of compensating with a different preset.

Can I use a Mitsubishi PLC timer instead of an HVAC damper proof switch?

No. A timer proves only that programmed execution reached a duration. It does not prove damper position, airflow or safe operating conditions. Command the damper, supervise a validated proof signal and use a timeout to diagnose the disagreement.

What is the clearest way to create HVAC fan run-on on an FX5U?

Use an explicit PostRun state and a normal on-delay timer to measure how long the state has existed. This makes re-request, permissive loss, feedback loss and immediate-trip overrides reviewable. The exact duration and allowed overrides must come from the approved system narrative.

How should a Mitsubishi PLC enforce compressor anti-short-cycle time?

Record the off transition, block a new request until the manufacturer/site minimum-off interval has elapsed and define what happens across CPU restart, power loss and invalid clock data. For long or power-spanning intervals, use a validated elapsed-time design rather than assuming a paused process timer measures real downtime.

Does GX Works3 simulation prove my timer's real response time?

No. It can provide logic-level evidence for a compatible project. Real response includes input filtering, PLC execution, I/O refresh, network update, relay/drive behavior, actuator travel and process response. Measure the required boundary on representative hardware and during controlled commissioning.

What happens if a Mitsubishi FX5 timer instruction is skipped?

The FX5 instruction manual states that when an active timer instruction is skipped, its current value and contact do not update during that skipped execution. Inspect jumps, subroutines, tasks and state paths; do not accept an accidental pause as designed timing.

How do I safely change a timer preset from an HMI?

Keep the engineering value and timer count distinct, define units and rounding, validate minimum/maximum and invalid values, restrict who may write it and decide whether a change applies immediately or next cycle. Log the effective setting and regression-test changes at representative boundaries.

How do I move Mitsubishi FX3U timer logic to FX5U?

Create a manifest for every FX3 timer device, base, preset, enable, reset, consumers and restart behavior. Choose the corresponding explicit FX5 OUT/OUTH/OUTHS and T/ST form, convert the project, resolve warnings and repeat interruption, simultaneous, restart and physical-response tests.

Can a standard Mitsubishi PLC timer be used in a safety function?

Not by itself. The examples on this page are ordinary control and diagnostics. Safety functions require a risk-assessed architecture, suitable safety-rated controller/I/O and final elements, validated wiring and measured performance under the applicable standards and site procedures.

Primary sources and review trail

The implementation claims above were checked against direct manufacturer and standards/authority sources. Resolve the current revision from the official index when the controlled project is released:

• Mitsubishi Electric, FX3S/FX3G/FX3GC/FX3U/FX3UC programming manual JY997D16601 revision R. Timer device ranges, time bases, normal and retentive behavior.
• Mitsubishi Electric, FX3U official beginner programming text JY997D26101. Worked OUT T0 K30 three-second example and retentive distinction.
• Mitsubishi Electric, MELSEC iQ-F FX5 Programming Manual (Instructions, Standard Functions/Function Blocks) JY997D55801 revision AB. OUT/OUTH/OUTHS, T/ST, preset, completion, skipped and repeated-execution behavior.
• Mitsubishi Electric, MELSEC iQ-F FX5 Programming Manual (Program Design) JY997D55701 revision M. Device, program, timer and retentive data design boundaries.
• Mitsubishi Electric, iQ-F timer-feature overview. Current explanation that timer properties follow instruction/data type rather than a fixed timer number.
• Mitsubishi Electric, MELSEC iQ-F manual index. Current hardware, program-design, instruction and module revisions.
• Mitsubishi Electric, GX Works3 manual index. Current operating, programming and simulator documentation.
• Mitsubishi Electric, GX Works3 Operating Manual SH-081215ENG revision AT. Project, conversion, monitoring, simulation and online-operation workflow.
• Mitsubishi Electric, FX5 simulation support FAQ 22327. Model-specific GX Works3 simulation support boundaries.
• Mitsubishi Electric, MELSEC iQ-F product specification search. Exact model and current product specifications.
• IEC, IEC 61131-3:2025 publication page. Current programming-language standard scope; it does not make vendor timer implementations source-identical.
• ASHRAE, Guideline 36-2024 title, purpose and scope. High-performance HVAC sequence context; the approved project sequence and jurisdiction control.
• ASHRAE, Standard 135 BACnet resource page. Supervisory communications context; a BMS request/point does not replace PLC field proof.
• U.S. Department of Energy, Operations & Maintenance Best Practices guide. Maintenance and performance-evidence context for facilities equipment.
• U.S. National Institute of Standards and Technology, Guide to Operational Technology Security SP 800-82 Rev. 3. OT change, architecture and security context.
• U.S. Occupational Safety and Health Administration, Control of hazardous energy. Hazardous-energy boundary for maintenance and commissioning in applicable jurisdictions.
• PLC Programming IO, Mitsubishi FX5U programming guide. Local broad FX5U setup owner with its independent primary-source trail.
• PLC Programming IO, Mitsubishi PLC example program. Local request-command-feedback pattern, device map, trace and acceptance evidence reused here.
• PLC Programming IO, PLC timer programming guide. Vendor-neutral TON/TOF/TP/retentive selection and cross-platform source trail.

Manufacturer documents, the approved controls narrative, equipment instructions, risk assessment and jurisdictional requirements take precedence over this independent teaching guide. Mitsubishi Electric product names and marks belong to their owner.

Implementation and handoff checklist

• Exact CPU model, firmware, GX Works version and project type are recorded.
• Each timer has one requirement, one execution owner and one documented unit.
• FX3 device band or FX5 OUT/OUTH/OUTHS choice is verified from the controlled manual.
• Engineering duration, raw preset, rounding and allowable tolerance are explicit.
• Indirect/HMI presets have types, ranges, authorization, initialization and change rules.
• Normal versus retentive behavior matches the requirement.
• ST reset ownership and power/restart persistence are specified and tested.
• Jumps, subroutines and duplicate timer executions are cross-referenced.
• Command, physical proof, timeout and first-out fault are separate signals.
• Proof-at-timeout priority is documented and tested.
• PostRun and anti-short-cycle overrides follow equipment/protective requirements.
• Sixteen normal, negative, simultaneous, interruption and restart tests retain evidence.
• Simulation evidence is labeled; I/O and equipment response are validated separately.
• Ordinary PLC timing is not claimed as a safety function.
• Forces, device tests, bypasses and temporary settings are cleared and checked.
• Project, manual revisions, downloads, trace, test results and recovery copy are archived.

The portable lesson is simple: a correct Mitsubishi timer is not “T0 plus a number.” It is a versioned instruction with a known unit, one execution owner, a declared reset and restart policy, an observed boundary trace and a physical result that is validated separately from elapsed logic.