Firmware and Hardware Versions: The Cross-Reference Axis Nobody Checks Until Commissioning

Firmware and Hardware Versions: The Cross-Reference Axis Nobody Checks Until Commissioning

A cross-reference between two industrial automation parts is rarely decided by the visible label, the series name, or the I/O count. The axis that decides whether a replacement works is firmware and hardware revision — and it is the axis nobody opens until the cabinet powers up at commissioning. We see this on roughly half the cross-reference requests we receive: the part number matches, the line is wired, and only then does the firmware revision fail to match the program, or the hardware revision change a register layout, or a peripheral refuse to talk to a new boot loader. Asking up front — «какая версия прошивки?» — saves a week.

This article is about that axis. It belongs to the twelve-axis framework we use when a buyer asks for a documented equivalent: form-fit-outline, dimensions, mounting and terminal layout, electrical ratings, mechanical environment, ingress and temperature, materials, certifications and lifecycle, function and I/O, firmware version, communication protocol, and software / engineering toolchain. Six of those axes are visible on a photo or a datasheet's first page. Firmware and hardware version is not. It is also the axis most likely to invalidate a comparison that looked solid on every other front.

Why this axis slips past the first review

Three patterns show up again and again when a cross-reference breaks at commissioning. None of them are exotic. They are routine, and they are exactly what a sourcing desk should warn against before a buyer commits.

First, a replacement module carries the same catalog part number but a newer hardware revision. The label still reads FX5U-32MT/DS, for example, but inside the case the PCB revision changed and with it the on-board memory map. Mitsubishi's own documentation lists several hardware versions for the FX5U series over a multi-year production run. The engineering tool detects the new revision and either prompts for a firmware update or refuses to download the existing project. A buyer who reads "FX5U-32MT/DS" as one product gets caught. The catalog record we maintain on FX5U-32MT/DS (87.46 in our internal score) lists a hardware-version field; the field exists precisely so this axis is visible before quotation.

Second, two modules at the same hardware revision run different firmware loads. Engineering stations can flash firmware separately from hardware. A "new surplus" module on the shelf may carry the firmware version the factory loaded at production; a "refurbished" module may have been flashed during bench test to clear a fault; a "used" module may carry whatever the previous owner last programmed. The buyer is not told any of this by the part-number label. They are told by the engineering software, at the moment of download.

Third, a peripheral device — an HMI, a servo drive, an analog input block — expects a specific firmware level on the controller it talks to. If the peripheral was tested and commissioned against firmware V1.040, and the replacement controller ships with V1.060, the network may still link but a function block may not resolve, an event log may not align, or a safety-related parameter may default to a different value. None of this is visible on the controller's catalog page; it is visible only in the release notes for the firmware pair. Buyers who skipped the release notes find this out at commissioning.

The common thread: every one of these failures could have been predicted by reading one document before quotation. None of them required a deeper engineering study than a five-minute check. The reason they slip past is that the visible axes — series name, I/O count, terminal layout — look identical, and the verification step is set aside for "later."

What we can verify before quotation, and what we cannot

A sourcing desk is not the engineering team that owns the program, the cabinet, or the safety case. We do not run firmware on a buyer's behalf. What we can do is make the firmware and hardware version axis visible on every line of a quotation, alongside the other eleven axes, so the buyer's engineering team has the inputs it needs to make the call before shipment, not at commissioning.

For every cross-reference we list, we pull the catalog hardware-revision field from the original record, the catalog hardware-revision field from the candidate record, and the firmware state as observed on the bench when the module was tested. We do not infer a revision we cannot see. If the bench record does not include firmware version, the line is flagged as firmware_version: unknown and the verification step is the buyer's. The line ships with a note that says so, and the buyer is asked to confirm before commitment. This is not a courtesy — it is the practice that distinguishes a cross-reference that holds up under power from one that fails when the engineering station is plugged in.

There are limits to what even a careful desk can verify:

• A module that has never been powered on since leaving the original channel has no observed firmware state. The catalog will say "as shipped," not "verified." That is an honest reading; it is also not a substitute for the buyer's engineering tool.
• A replacement peripheral that is itself a cross-reference (the HMI panel we offer instead of the discontinued one) has its own firmware version, its own release notes, and its own compatibility matrix. The cross-reference is two-dimensional: controller-to-peripheral and peripheral-to-firmware. We surface both, but the buyer must clear the second.
• A safety-rated function — operator-protection circuits, emergency-stop chains, guard-monitoring relays — cannot be cross-referenced on the firmware axis by us at all. That determination belongs to the buyer's functional-safety process. We refuse the substitution rather than attempt it.

The verification clause that travels with every cross-reference quotation is this: verify against the original manufacturer datasheet and your own qualification process. We include it because the datasheet is the only document that tells the buyer, definitively, which firmware load and which hardware revision are compatible with which program. No amount of catalog discipline can replace that step.

The twelve-axis verdict on a firmware-version-driven substitution

To make the framework concrete, here is how a typical firmware-version-driven substitution looks when written across the twelve axes. The example is illustrative — it does not name a buyer's program — and it covers the same fields we use internally.

Eleven axes match on paper. The firmware axis is the only one that differs, and it is the only one that decides whether the substitution is fit for purpose on the buyer's program. The verdict is not "rejected" — the substitution may well work after the buyer flashes V1.040 onto the candidate, or after the engineering tool re-converts the project. The verdict is "buyer to verify program compatibility," and the quotation line carries that wording.

We keep the same three-state verdict (matched / differs / unknown) on every cross-reference we issue. The honest answer when a firmware state is not observable is unknown, not "should be fine." A buyer who sees firmware_version: unknown on a quotation line is being told the truth: the axis could not be checked, and the engineering tool is the place to clear it.

Where this axis does not apply, and where it does more than usual

Firmware-version-driven failures are most common in three families in the catalog: PLC CPUs, servo drives, and HMI panels. They are least common in passive components — terminal blocks, contactors, circuit breakers, cable assemblies — where the firmware axis is not present at all. The buyer who cross-references a Phoenix Contact QUINT power supply against a functional equivalent does not face this axis; the buyer who cross-references an FX5U-32MT/DS against another FX5U-32MT/DS at a different production batch does.

Within PLC families, the axis is most active across model transitions. A cross-reference from a discontinued FX3U to a current FX5U is, on the visible axes, a viable engineering choice. On the firmware axis, it is a porting exercise: the program must be re-imported into GX Works 3, instructions must be re-resolved, and the engineering tool must reconcile tag mapping between the two platforms. The cross-reference is real, but it is not invisible. We list this kind of transition in the substitution-claims ledger as similar specification rather than pin compatible — the language matters because the engineering work that follows is real work, not paperwork.

Cross-brand transitions are heavier still. A request to cross a Mitsubishi FX5U program onto a Siemens S7-1200 CPU, or vice versa, fails on at least three axes at once: firmware version, communication protocol, and software / engineering toolchain. We do not attempt that transition. The cross-reference is documented as requires redesign, the buyer's engineering team is told that the program must be rewritten, and the substitution-claims ledger records the refusal. The refusal is itself a service: a buyer who learns at the quotation stage that the cross-reference fails on three axes saves a week of engineering that would have ended in the same conclusion.

What this means for the first message you send us

A cross-reference request that names a part number, a series, and a program is enough for us to start. A cross-reference request that also names the firmware version, the hardware revision, and the engineering-software revision is enough for us to give a verdict on the substitution before shipment. The five-minute cost of including those three fields up front is the single highest-leverage action a buyer can take on the firmware axis.

When the buyer does not have the firmware version — because the module has never been powered on, or because the original paperwork is missing — the line goes into the quotation with firmware_version: unknown, and the buyer is asked to confirm. We do not guess. We do not back-fill "typical" values. We do not write "should be compatible" on the line and hope the buyer's engineering tool agrees. The honest unknown is cheaper than the confident mistake.

We screen end users and end uses, classify before quoting, and decline transactions that cannot be screened.

The discipline is the same as it is on every other axis: what the catalog says the part is, what the bench record shows the part does, and what the original manufacturer datasheet confirms the part supports. When all three agree, the cross-reference holds. When one of them is silent, the silent one is named, and the buyer makes the call.

By aoctrl sourcing desk, independent industrial automation distributor and cross-reference desk.

Dateline: Data through September 2026

Independent distributor notice: aoctrl is an independent China-based industrial automation distributor and sourcing desk. We are not an authorised distributor for any brand listed in the catalog. We do not hold EAC, TR CU, ISO 13485, UL, CE, SIL, or ATEX certification. Condition (new surplus, refurbished, used), test status, and warranty are stated per line before commitment.

Data Notes: Internal catalog scores cited from aoctrl-manager cli.py score --brand mitsubishi (cycle 2026-09-20). Substitution framework from automation-substitution-axes.json (twelve axes, three-state verdicts). Russian buyer prompts X03 and X11 from the in-house prompt bank. No external URLs were used in research; original manufacturer documentation referenced by name only.

FAQ

What does "firmware version" actually mean on an industrial automation part?

Firmware is the software that runs on the module itself — not the program you download from the engineering station, but the operating layer beneath it. It controls how the module boots, how it talks to peripherals, and how it interprets the project file. Two modules with the same catalog part number can carry different firmware loads if one was flashed during bench test, or if the manufacturer issued a revision between production runs. The catalog label rarely shows the firmware version; the engineering software does.

How do I find the firmware version before I send an inquiry?

Connect the engineering station to the module and read the firmware state from the diagnostic or module-information screen. For Mitsubishi FX5-series CPUs, GX Works 3 lists the firmware version in the module information dialog. For Siemens S7-1500 CPUs, TIA Portal shows it under Online → Accessible Nodes. For most servo drives and HMI panels, the engineering tool of the same brand reads the firmware version automatically. If the module has never been powered on, the firmware version is whatever the factory loaded at production, and the catalog record usually states "as shipped."

Can a replacement module with a newer firmware version be used without changing the program?

Sometimes yes, sometimes no. Most engineering tools will load an older project onto a newer firmware without complaint if the instruction set is unchanged. Some firmware revisions introduce breaking changes — a renamed register, a default value adjusted, a peripheral handshake revised — and the project must be re-saved under the new firmware before download. The only way to know is to read the firmware release notes for the candidate module against the program you intend to run. The substitution is not free; the verification step is.

What if I cannot read the firmware version because the module is unpowered or undocumented?

The firmware version is then unknown, and the substitution line is flagged accordingly. We do not infer a version. The line ships with a note asking the buyer to verify before commitment, and the engineering tool becomes the source of truth. This is the case where the substitution-claims ledger records firmware_version: unknown as the verdict rather than matched or differs.

Does the hardware revision axis interact with the firmware axis?

Yes. A new hardware revision can introduce a new on-board memory map, a new boot loader, or a peripheral interface revision that the existing firmware does not support. Mitsubishi's own documentation lists several hardware versions for the FX5U series over its production run, and each hardware version pairs with a specific firmware range. A buyer who reads the catalog part number alone and ignores the hardware revision field will discover the pairing at commissioning, not before.

Can you cross a Mitsubishi FX3U program onto an FX5U without rewriting it?

No. The FX3U is programmed in GX Works 2 with its own instruction set and tag layout; the FX5U is programmed in GX Works 3. The program must be re-imported, instructions must be re-resolved, and tag mapping must be reconciled. The cross-reference is viable as a hardware substitution; it is not a program-porting substitution. We list this transition in the substitution-claims ledger as similar specification rather than pin compatible, because the engineering work is real work, not paperwork.

What is the fastest way to clear the firmware-version question before shipment?

Send the part number, the series, the program name (if available), the firmware version currently on the installed module, the hardware revision of the installed module, and the engineering-software version you intend to use. Five fields, five minutes. The quotation that comes back will already have the firmware axis verdict on it, and the buyer's engineering team will know whether to flash, port, or hold before the package leaves the warehouse.