Appearance
Y305 PLC I/O Modules Programming Guide
Start with a program that follows one digital input in an internal bit. Then add the states, timers, parameters, and interlocks needed for the application.
The exercises are logic designs, not ready-to-download projects. Compile and test each one on the intended Y305 hardware and firmware. Keep actuators and other controlled equipment disconnected during testing.
Contents
- First program: observe an input
- Define the control requirement
- Understand PLC devices
- Organize the program
- Design a simple sequence
- Review timers and retention
- Test before connecting loads
- Use official learning material
1. First program: observe an input
The exercise uses X0, a physical input, and M0, an ordinary internal bit. Closing the input contact makes M0 ON; reopening it makes M0 OFF. It needs no Y-output, analog-output, or serial write instructions and applies to the digital input present on Y305-4400, Y305-4421, Y305-8800, and Y305-8821.
1.1 Prepare the computer and connection
Before creating the project: have the setup supplied for your unit's hardware and firmware: GX Works2 release, project/CPU selection, programming interface and cable pinout, driver, and transfer settings. If that setup is missing, ask the supplier for it before connecting. An FX3U-style device model does not identify the correct CPU entry in GX Works2.
Obtain a licensed GX Works2 package through Mitsubishi Electric or an authorized supplier. Use the installer and license information supplied with that package. Check the Windows edition/version on the computer against the installation instructions for that software release.
Mitsubishi Electric's April 2026 installation instructions list Windows 11, require .NET Framework 3.5, and call for administrator access during installation. The installer uses the Product ID from the license certificate. These are software installation requirements, not a tested Y305 software/firmware combination.
Identify the programming cable or adapter by its actual make and model. Install its matching driver from the device manufacturer or the supplied authorized package. In Windows Device Manager, check that the interface appears without a driver warning; if it presents a COM port, record that port for the supplied transfer settings. Do not identify the driver from the connector's shape.
On hardware fitted with a designated USB Type-C programming port and RUN switch, identify both before connecting. Use a data-capable cable for that port. The connector shape does not identify the USB interface chip, driver, or transfer protocol. Use the unit-specific RUN/STOP procedure rather than treating the switch as electrical isolation.
| Connection | Purpose |
|---|---|
| Programming interface and cable specified for the unit | GX Works2 project transfer and online monitoring |
| USB-to-RS485 adapter | Serial tests with a Modbus tool on a fitted RS485 port |
A USB-to-RS485 adapter used for Modbus is not automatically the programming interface. Disconnect external masters during the first exercise so that another device cannot issue commands.
1.2 Create the logic offline
- Create and save a new ladder project using the supplied project settings. Record the software, hardware, and firmware versions with the project.
- Reserve M0 for this exercise. In an existing project, check that no other logic, host, or force uses it.
- Add a normally open ladder contact addressed X0 driving an ordinary coil addressed M0. Do not use a latched SET coil.
- Add comments such as “test input” and “input observed.” Compile/convert the project and resolve diagnostics before transfer.
The rung has one contact and one coil:
text
|----[ X0 ]----------------( M0 )----|This is the ladder relationship to enter, not an importable project. M0 is an internal bit; the rung does not command a Y output or DA0.
| Logic element | Meaning |
|---|---|
| Normally open contact X0 | True while the monitored X0 input is ON |
| Ordinary coil M0 | Follows the contact condition each time the rung executes |
A ladder contact reads a bit; it does not specify how a physical switch must be wired. Use the dry-contact wiring in the User Manual: S/S at +24 V, with the switch between X0 and 0 V.
1.3 Transfer and observe
- Keep output loads isolated. With permission to replace the existing program, back up the readable project and parameters and check that the new project contains only the intended test logic.
- Connect to the intended unit and follow its supplied transfer and STOP/RUN procedure. Compare or read back the transferred project where supported.
- Place the CPU in RUN for the exercise and monitor X0 and M0 together. Do not force either bit.
- Operate the switch and check each result.
| Action | X0 | M0 |
|---|---|---|
| Leave the contact open | OFF | OFF |
| Close the contact | ON | ON |
| Reopen the contact | OFF | OFF |
Unoperated inputs should remain unchanged. If X0 changes but M0 does not, check CPU state, the loaded project, rung logic, duplicate M0 writes, and forces. If X0 does not change, return to the input wiring check. A successful compile alone does not establish correct transfer or execution.
Stopping or closing the online monitor does not stop the PLC program. Finish with the unit's specified CPU STOP procedure and verify its state; isolate power before removing test wiring. Record the observed results and tested project revision before extending the program.
Do not erase PLC memory to fix a connection. Erasure deletes the program. Password changes need a backup and recovery plan; the documented special protection mode can require program erasure to remove it.
2. Define the control requirement
Write observable behavior before drawing ladder rungs. For a fan or pump controller, specify the start condition, stop condition, permissives, fault response, and restart permission. Separate ordinary control from functions that need an independent safety system.
List each input's terminal, signal name, electrical type, normal state, active state, and response to a failed wire or sensor. A normally closed contact can help detect some wiring failures; it does not make a standard PLC input a certified safety input.
For each output, record the load, output hardware, voltage, current, inrush, common-terminal grouping, and command in each operating mode. Check the load against the hardware's electrical limits. Interpret “Output OFF” at the equipment level: de-energizing a relay or valve is not necessarily the safest process action.
Keep the project revision, I/O assignments, and parameter allocations with the requirements. Use only programming languages, online-change functions, and instructions supported by the unit's setup. Simulation for another target can help check logic but does not establish Y305 compatibility.
Pair each requirement with a test. For example: “A start request received while the permissive is false must not energize the output; restoring the permissive requires a fresh start request.” This gives a specific result to test instead of the vague requirement “add an interlock.”
3. Understand PLC devices
| Device | Typical role | Allocation rule |
|---|---|---|
| X | Physical digital input | Map fitted terminals; X7 is followed by X10 |
| Y | Physical digital output | Use one final control path per output |
| M | Internal bit/state | Check retention and special areas before allocation |
| D | Numeric data | Record units, width, signedness, and ownership |
| T | Timer | Match the time base and instruction behavior to the delay |
| C | Counter | Check width, input assignment, reset, and rollover behavior |
| S | Sequence state | Use the target's supported range and retention behavior |
| Special D/M | Communication, analog, clock, system functions | Keep these out of ordinary scratch storage |
Use K for decimal constants and H for hexadecimal values. H10 is hexadecimal 0x10, or decimal 16. X/Y terminal labels follow octal-style sequencing; a Modbus protocol address is a separate numerical value. State the convention in comments and test records where confusion is possible.
A ladder contact reads a logical condition, not the electrical construction of a field contact. A normally closed ladder contact tests a false condition; it does not instruct the installer to wire a normally closed switch.
3.1 Match instructions to application tasks
Select instructions by the operation the program needs. The documented families provide building blocks; parameter management, buffers, and operating sequences still require application logic. Check operand types, device ranges, execution conditions, and scan effects on the target firmware.
| Application task | Instruction family | Design check |
|---|---|---|
| Load settings, initialize a data area, or keep working and backup values | MOV, FMOV, XCH, SMOV | Choose the required transfer operation; check widths and destination overlap. A transfer does not validate settings. |
| Test a threshold or operating window before a state transition | CMP, ZCP | Define equality at each boundary, units, and any hysteresis. |
| Build a status word, mask flags, test a bit, or count active bits | WAND, WOR, WXOR, BON, SUM, CML | Define each bit and its owner. Mask reserved bits; an inverted word can set them. |
| Scale a reading, calculate an average, or convert numeric types | ADD, SUB, MUL, DIV, MEAN, FLT and floating-point operations | Check intermediate width, overflow, division by zero, and rounding. See analog scaling. |
| Accept one event from a changing signal | LDP/LDF, ANDP/ANDF, PLS/PLF | Test power-up with the signal already active, contact bounce, and pulses shorter than the scan. |
| Shift a sequence pattern or maintain a register buffer | SFTR/SFTL, WSFR/WSFL, SFWR/SFRD | Verify length, shift order, reset, and full/empty behavior before using a queue. The instruction list does not establish those behaviors. |
| Alternate a command, generate a ramp, or combine timing conditions | ALT, RAMP, STMR | Define reset and interruption behavior. A ramp instruction alone does not establish motor acceleration or stopping performance. |
| Separate reusable logic, process a bounded batch, or enable a logic section | CALL/SRET, FOR/NEXT, CJ, MC/MCR | Limit loop work per scan and test skipped logic. MC/MCR does not replace an independent safety cutoff. |
| Compare a time window, read or set the clock, or accumulate operating time | TCMP/TZCP, TRD/TWR, HOUR | Time-of-day functions need the optional RTC hardware. Verify time validity and restart behavior; clock accuracy and backup duration need unit-specific data. |
4. Organize the program
A small program can follow this sequence:
- Read inputs and communication requests.
- Derive named conditions, including signal validity and faults.
- Update the operating mode and sequence state.
- Calculate output requests.
- Apply permissives, limits, and restart rules.
- Write physical outputs through one final output-control section.
- Publish status and diagnostics to the host.
Test instruction order and scan effects on the target. Avoid writing the same Y or output-register destination in unrelated sections.
Keep a host request separate from the actual output state. The host writes a command register; PLC logic decides whether to act on it. Report the request, the commanded output, and the reason for rejection. See the Modbus Integration Guide.
4.1 Switch parameters and report status
For a controller with selectable setpoints and limits, reserve separate pending and active parameter blocks. The host writes the pending block; PLC logic owns the active block and the acknowledgment. Define each field's units, range, width, and revision before assigning addresses.
| Stage | Application behavior | Status reported to the host |
|---|---|---|
| Receive a complete request | Host writes the pending values and a new request sequence, then commits. It leaves that block unchanged until acknowledgment. | Request pending |
| Validate | PLC checks ranges and relationships, such as lower limit ≤ setpoint ≤ upper limit. Reject an invalid set without changing active values. | Pending or rejected, with a reason |
| Wait for an inactive boundary | Apply changes only in the defined stopped or otherwise inactive state, after required feedback and permissives agree. | Pending; current active revision remains visible |
| Copy the accepted set | Prevent control logic from consuming a partly updated block. Copy the fields and finish the transfer before enabling their use. | Update in progress |
| Acknowledge | Publish the active revision and acknowledge the request sequence after the complete set is available. | Applied, or rejected with the previous revision still active |
Neither a multi-register host write nor a sequence of PLC transfers should be assumed atomic relative to the program. Define the commit and consumer-inhibit logic explicitly, including what happens if power or communication fails during an update. Use the Modbus command handshake to distinguish a retried request from a new one. Applying parameters must not act as a start request.
One application-defined status word could assign bit 0 to request pending, bit 1 to request rejected, bit 2 to active parameters valid, and bit 3 to fault inhibiting operation. Keep result codes, request acknowledgment, and active revision in separate fields. PLC logic owns the word: clear pending only after applying or rejecting the request, clear the previous rejection when taking a new request for validation, and update validity and fault bits from their actual conditions. A valid parameter set does not mean that the output is running.
For PID settings, keep the manufacturer PID block separate from host staging fields and ordinary scratch data. Retained settings also need startup validation; retention is not permission to resume the previous process step.
5. Design a simple sequence
The fan/pump sequence uses five states. Assign PLC addresses and implement each transition in the project before testing it.
| State | Output request | Transition rule |
|---|---|---|
| Inhibited | OFF | Remain until required permissives are valid and reset conditions are met |
| Ready | OFF | A fresh start request with valid permissives enters Starting |
| Starting | ON, subject to final interlocks | Feedback within the allowed time enters Running; timeout enters Fault |
| Running | ON, subject to final interlocks | Stop enters Ready; loss of required permissive or feedback enters the defined fault state |
| Fault | Process-dependent, normally OFF for this example | Remain latched until the cause clears and an operator resets the fault |
Stop and loss of a required permissive take precedence over normal transitions in every active state, including Starting. Specify whether each event returns to Ready, enters Inhibited, or latches Fault. Apply its output action through the final output-control section.
In this example, normal stop disarms run control and resets active timers. Ready waits for a fresh start; releasing stop cannot restart the output.
Specify whether a start request is a maintained level or a one-time event. A held start button must not restart the sequence after a stop or fault. Where a rising edge is required, test the instruction's startup behavior with the input already active at power-on.
Keep “stop requested” separate from “feedback proves stopped” when the process needs both states. Set feedback timeouts from the equipment's response, not the PLC scan speed.
6. Review timers and retention
Timer groups have different time bases. Check the selected group's behavior on the delivered firmware. Express the required delay in engineering units, then convert it to that timer's preset.
For an ON delay, decide whether a false condition resets the timer. For an OFF delay, decide whether a new start cancels the pending stop. Ordinary control logic must not delay a safety-related stop unless the independently assessed safety design permits that delay.
A retained bit or register can restart a sequence if the program treats it as a fresh command. Define initialization separately for configuration, counters, machine state, and remote commands. Test cold power-up, short interruption, STOP/RUN, and program transfer. Retention labels do not establish the unit's complete restart or output behavior during these transitions.
6.1 Two small bench exercises
Five-second delay. T0–T199 use a nominal 100 ms time base. Five seconds therefore corresponds to 50 time-base units, written as decimal K50. This is a preset calculation, not a ladder program. Indicate completion in a free ordinary internal bit. On the target firmware, test the timer instruction, reset behavior, and measured delay. Include continuous permission for five seconds, interruption before expiry, stop after expiry, and a new start that begins a fresh interval. Scan and I/O delays affect the measured time.
Ten-event counter. Choose a free ordinary counter such as C0 after checking the project's allocations. Count one validated input edge as one event, give reset priority, and indicate completion at ten events. Test that a held contact counts once, bounce does not add events, and reset clears the intended state. C0–C99 are ordinary counters. Measure whether the input pulse width and spacing allow the program to detect each edge at its actual scan time. If ordinary scan counting cannot meet the signal timing, use high-speed hardware and instructions with documented limits for the target.
7. Test before connecting loads
Test with outputs isolated:
- Normal start and stop
- Start held during power-up or reset
- Conflicting start/stop requests
- Loss of a permissive in each sequence state
- Late, absent, or stuck feedback
- A timer interrupted just before its threshold
- Communication loss and return with a stale command
- Partial parameter writes, invalid ranges, and a repeated request sequence
- A parameter update requested while the sequence is active
- Power loss during a parameter transfer and validation after restart
- Release of a forced output back to normal logic
Record expected and observed transitions. Compilation does not test the machine requirement. Repeat affected tests after a logic change and save the tested program revision.
8. Use official learning material
Mitsubishi Electric's GX Works2 Beginner's Manual for Simple Projects explains project editing, compilation, and monitoring. Its example CPU and connection choices belong to the illustrated Mitsubishi hardware; do not copy them as Y305 settings.
The FX3 programming manual for basic and applied instructions explains general instruction concepts. Use the Y305 device reference and PID parameter layout for implementation. Mitsubishi PID parameters, special registers, electrical limits, and device capacities are not substitutes for Y305 data.