Can a Different PLC Family Run Your Existing Program? What Actually Survives a Cross-Brand Swap

Can a Different PLC Family Run Your Existing Program? What Actually Survives a Cross-Brand Swap

Most cross-brand PLC swap questions arrive on a desk the same week: a line is down, the old family is out of production, the controller is the only spare on the shelf, and someone has typed the Russian-language equivalent of "Можно ли заменить ПЛК одного производителя на другой без переписывания программы?" into a search box. The honest answer is that a different PLC family almost never runs an existing program unchanged — but the depth of "almost never" varies by axis, and the work that has to happen anyway is usually smaller than the buyer fears. The goal of this article is to lay out which axes survive a same-platform migration inside one brand (FX3U to FX5U within Mitsubishi), which break the moment you cross brands (Siemens S7-300 to anything else, Allen-Bradley SLC 500 to CompactLogix, Omron CP1 to NX/NJ), and what a written cross-reference report from an independent China-based industrial-automation distributor and sourcing desk can and cannot certify in either case. aoctrl holds no programming tool licence, performs no engineering cutover, and does not claim that any third-party CPU will execute a third-party project file as-is. What the desk does is line up a candidate PLC, list the axes that match on paper, mark the axes that are not stated by the manufacturer, and leave the final qualification call to the customer's engineering team.

Why the question is harder than it looks on the wiring diagram

A control cabinet build looks deterministic from the outside: a CPU, a few I/O modules, a power supply, a connector block, an HMI on the door. From the inside, the same cabinet contains five categories of behaviour that have to survive the swap if the program is going to run.

First, the instruction set. FX3U programs written in GX Works2 / GX Developer against the MELSEC instruction set cannot be loaded into a Siemens S7-1500, an Allen-Bradley CompactLogix, or an Omron NX even with a translation tool in the loop. Inside a single vendor, migration tools may carry over variable names and ladder structure; across vendors, they do not. Buyers sometimes ask whether a "structured text conversion" is feasible — it is, but it is engineering work, and the result is a new program, not a moved one.

Second, the I/O addressing model. Mitsubishi uses an octal-style octal/hexadecimal device-and-address scheme; Siemens uses input/output byte addressing with peripheral addressing for distributed I/O; Allen-Bradley uses slot-based or tag-based addressing depending on the platform; Omron uses CIO/WR/HR/DM banks. The mapping is not 1-to-1. Even when the channel count is the same, the addressing discipline is not.

Third, the fieldbus and network layer. Profibus, Profinet, EtherNet/IP, CC-Link, CC-Link IE, Modbus TCP, EtherCAT — each vendor's stack ties into its own configuration tool (GX Works3, TIA Portal, Studio 5000, Sysmac Studio). EDS files, GSD files, GSDML files, ESI files — none of these are interchangeable, and the master/slave role and topology often are not either. A Siemens ET 200S remote I/O drop is not addressable from a Mitsubishi CPU without a third-party gateway, and even then the diagnostic model breaks.

Fourth, the special-function modules. High-speed counters, positioning modules, PID modules, analogue I/O with channel-to-channel isolation, temperature input modules — each vendor exposes these through its own configuration database. A FX5-4LC temperature module replacement is not the same physical or configuration fit as an FX3U-4LC; the project gains parameters that the engineering tool has to re-create.

Fifth, the firmware and engineering-software version state. Two CPUs from the same vendor, same family, same model number can still disagree on firmware revision, hardware function-state suffix, and engineering-tool version. The label says FX5U-32MT/DS; the program behaviour depends on what firmware revision is on the module and which GX Works3 build wrote the project file. The independent desk does not have visibility into firmware state from a stock photo and a label — that is a per-unit reading done at the bench.

What survives a same-platform migration inside one brand

A same-platform, same-vendor migration is the case where buyer expectations are most often met, with the most often caveat being "met, with the engineering tool rebuild the project file from scratch, then re-import the variables and re-link the I/O." The Mitsubishi FX3U to FX5U path is a worked example we can walk through because both platforms are listed in our catalogue and the engineering migration guide is on the manufacturer's public support site.

Form, fit and outline: FX5U CPU modules are physically smaller for the same I/O count than FX3U, and the backplane architecture is different. FX3U uses a base-plus-extension layout; FX5U is a compact CPU with onboard I/O plus extension modules on a different bus. A cabinet that was laid out for FX3U may not physically accept FX5U without re-arranging the din-rail. That is a mechanical axis, not a wiring one.

Interface assignment: the front connector pin-out is not identical between FX3U and FX5U. The screw-terminal arrangement, the power-supply terminal position, the I/O terminal pitch — these are not interchangeable. Re-wiring is required.

Function and I/O: the FX5U-32MT/DS in our catalogue is a 32-point transistor-output CPU. The FX3U-32MT/DS that it most often replaces has a similar headline spec but a different output-driver topology. The match is "functionally and electrically rated at or above the original" on the axes that matter for a general-purpose machine; the verification clause below still applies.

Firmware and engineering software: the FX3U project must be opened in GX Works2 (or imported into GX Works3 with conversion). The conversion is mechanical for ladder logic with no special-function instructions; it is non-trivial for any program that uses structured text, SFC, or FX3U-specific positioning blocks. The cross-reference desk can line up the candidate CPU; the engineering team has to do the conversion.

Communication protocol: FX5U supports Ethernet natively through the FX5-ENET module; FX3U relied on FX3U-ENET or on serial Modbus. The move from serial to Ethernet changes the network segment, not just the module. A line that ran on RS-485 Modbus is not a line that runs on Ethernet Modbus TCP without a topology change.

Special-function modules: the FX5-4LC temperature module is the FX5 generation of the FX3U-4LC. The terminal layout, the channel assignment, and the engineering-software configuration block are not identical. Project files written against FX3U-4LC do not import directly into FX5-4LC; the configuration has to be re-entered.

The honest summary is that a same-vendor migration reduces the work from "rewrite the program" to "rebuild the project file, re-import variables, re-link the I/O, re-enter special-function configuration, re-test." That is still engineering work — a day or two on a typical machine — but it is not a rewrite from scratch.

What breaks the moment you cross brands

Cross-brand is the harder case, and the buyer prompt «Можно ли заменить ПЛК одного производителя на другой без переписывания программы?» is best answered with a flat "no" followed by a list of which axes break and which survive.

Form and outline break first. Siemens S7-300 and Allen-Bradley ControlLogix have different module widths, different mounting rails, different connector styles. The mechanical rework alone can match the cost of the new CPU.

Interface assignment breaks next. S7-300 uses front connectors with screw or push-in terminals; SLC 500 uses 1746-style removable terminal blocks; FX5U uses European-style screw terminals. Wiring has to be re-done.

Function and I/O break at the addressing level. S7-300 I/O is addressed by byte and bit within an input/output process image; SLC 500 is slot-based; FX5U is device-and-address octal/hex. The translation is not algorithmic.

Firmware and engineering software break entirely. TIA Portal project files do not load into Studio 5000. GX Works3 project files do not load into Sysmac Studio. The engineering team is building a new program, not migrating one.

Communication protocol breaks at the master/slave role level. A Siemens Profinet master cannot address an Allen-Bradley EtherNet/IP scanner without a third-party gateway, and even then the role topology is awkward.

Special-function modules break at the configuration level. Siemens S7-300 FM350 counter modules, Allen-Bradley 1756-HSC modules, Mitsubishi FX5-4LC modules — none of these are interchangeable, and even modules with similar headline functionality (high-speed counting, PID, analogue I/O) expose configuration through vendor-specific blocks.

Certifications and lifecycle break in a less obvious way. The new CPU is current; the project file is legacy. The cabinet as built may have been qualified to a particular standard under the old controller; the swap may require a re-qualification depending on the end-use market. The independent desk does not have authority to declare that re-qualification is or is not required.

Twelve-axis worksheet for a PLC swap decision

The same twelve-axis framework used for any industrial-automation cross-reference applies to a PLC swap. Below is the worksheet as a buyer would walk it, with each axis shown at claim ladder level 1 — that is, "mounting and terminal interface matches on paper, subject to verification against the original manufacturer datasheet."

The two columns above are not predictions of cutover success; they are the axis-by-axis accounting that the cross-reference report will deliver. The buyer still has to do the engineering. Verify against the original manufacturer datasheet and your own qualification process.

When the desk will not propose a swap at all

Three cases in this category warrant calling out, because they are the situations where an independent distributor saying "we can do this" would be doing the buyer a disservice.

Operator-protection loops and rated protection equipment. A machine whose operator-protection loop is implemented in the PLC — through a dedicated safety PLC, or through a standard PLC with a dedicated safety I/O slice that participates in a rated protection loop — is outside the desk's scope of recommendation. The desk does not hold functional-safety certification, does not run a protection lifecycle audit, and will not propose a substitute for a rated controller or a rated I/O module. That decision belongs to the customer's protection engineer and to the certification body that will audit the line.

Process-critical or regulated end-use. Pharmaceutical, food-and-beverage under GAMP or 21 CFR Part 11, high-assurance process control, non-implantable medical devices above Class I and implantable medical devices — these end-uses have documentation requirements that an independent distributor cannot fulfil. The substitution qualification belongs to the manufacturer's quality system, not the desk. The desk will not propose a substitute into a regulated workflow without the customer taking ownership of the qualification, and any sterilization or biocompatibility assessment belongs to the equipment owner.

OEM-locked systems. Some machine builders (bottling line OEMs, packaging OEMs, CNC builders) lock the PLC type at a level into the machine warranty. A substitute into an OEM-locked system is a warranty decision the OEM has to make, not a parts decision the desk can take.

In each of these cases the desk's role is to be honest about the boundary, not to find a workaround. Verify against the original manufacturer datasheet and your own qualification process.

What a written cross-reference report from this desk contains

The cross-reference report is the deliverable that lets the engineering team decide whether to commit to the swap. It is not a certification, not a guarantee, and not a substitute for the engineering team's own qualification. It is a written record of which axes match on paper and which do not.

The report opens with the candidate controller, the candidate I/O configuration, and the candidate special-function modules, each tied to a manufacturer part number. It then runs the twelve axes against the original configuration and states matched, differs, or unknown for each axis. It calls out axes that the manufacturer does not publish — typically firmware-version state on a stock unit and certification-scope state on a unit pulled from a decommissioned line — as unknown, not as inferred.

The report closes with a verification clause: every recommendation must be confirmed against the original manufacturer datasheet and the customer's own qualification process. The desk performs the cross-reference; the customer's engineering team performs the qualification.

The report also identifies axes the desk will not certify. Functional-safety integrity is one. Medical-device qualification is another. Anything that requires the desk to hold a certification it does not hold is listed as outside the scope of the report. Verify against the original manufacturer datasheet and your own qualification process.

The substitution-claim ladder, plain language

Most published PLC swaps fall into one of three categories on the claim ladder, and the language used in any cross-reference document should reflect the actual category rather than the language the buyer wants to hear.

Visually similar outline. Two CPUs that look similar in a stock photograph are at this level. Most FX3U and FX5U photos fall here, and the buyer prompt about "cross-brand PLC swap without rewriting the program" usually starts here. The honest answer is that visual similarity is not evidence of interchangeability.

Mounting and terminal interface matches on paper. The two CPUs share the same DIN-rail mounting, the same screw-terminal style, the same front-connector pitch. This is the level at which a same-vendor same-platform migration starts to be feasible, and it is still subject to verification against the original manufacturer datasheet.

Functionally and electrically rated at or above the original. The candidate CPU has at least the same I/O count, the same output-driver topology, the same supply voltage, the same communication interfaces, and at least the same special-function capability as the original. This is the level at which a same-vendor migration typically lands, and it is the level at which a cross-brand migration becomes a re-engineering project rather than a parts swap.

Anything beyond this ladder — including language of the form "the candidate executes the program as-is" or "100 percent compatible," or any wording that implies the program will execute without re-engineering on the candidate CPU — is forbidden by the cross-reference discipline. The substitution-claim ledger filed alongside this article lists every candidate controller by axis and marks the verdict accordingly. Verify against the original manufacturer datasheet and your own qualification process.

A fail-safe case worth calling out

A fail-safe case is the situation where a desk that says "we can do this" would be doing the buyer a disservice. The cleanest example for this article is the following: an OEM-warrantied bottling line whose current PLC type is locked into the machine warranty, where the line is mid-production run, and where the buyer is being told by the field engineer that "FX3U is the same as FX5U." It is not. The form factor differs, the wiring differs, the engineering tool differs, and the OEM warranty does not extend to the new platform without an OEM service engagement. In that situation the desk's role is to refuse the substitute, point the buyer back at the OEM service channel, and not offer an independent swap into a warranty-locked line. The right call here is to do not substitute; better to keep the original controller and route the request through the OEM service channel. Verify against the original manufacturer datasheet and your own qualification process.

What the desk does after the cross-reference is signed off

Once the customer's engineering team has accepted the cross-reference report and the axis-by-axis verdict, the desk moves into the sourcing workflow. The candidate CPU and any companion modules are pulled from stock with the condition written on every line — new surplus where applicable, refurbished where refurbished is what is on the shelf, used where used is what the line item carries. Pre-dispatch photos are recorded so the buyer can verify the label, the connector condition, and the firmware-sticker revision before shipment. The shipment is then consolidated with any other lines on the buyer's bill so the buyer receives one consignment.

Quotations carry the verification clause verbatim and state that the cross-reference is a paper exercise that the customer must close with their own qualification. The desk does not represent the engineering cutover, the program conversion, or the on-site commissioning; those are the customer's engineering team's work.

When to skip the cross-reference and ship the original

The cross-reference report exists for the cases where the original part is not available and the engineering team has to decide whether to substitute. In cases where the original PLC family is still current, the stock is on the shelf, and the engineering team has no reason to migrate, the right answer is to ship the original and not write the report. The desk's catalogue includes current-production Mitsubishi FX5U, FX5-ENET, and FX5-4LC entries, and the report is unnecessary when the buyer's call is "more of the same." The cross-reference report earns its cost when the engineering team has to make a decision it would otherwise be making without written input.

Closing — send the part list, not the question

The fastest path from "Can a different PLC family run my existing program?" to a written verdict is to send the desk the original CPU model, the I/O configuration, the special-function modules in use, the communication network in use, and a one-line description of the end-use. The cross-reference report comes back in three to five working days, with each axis marked matched, differs, or unknown, and with the substitution-claim ladder stated in plain language. The engineering team then takes the report into their qualification process. The desk's role ends at the boundary of the written report; the engineering cutover belongs to the customer.

Send your BOM and our sourcing desk will quote you on the candidate PLC, I/O, and any special-function modules. Send the part list through the inquiry form on /inquiry or attach it to a BOM at /baojia. aoctrl is an independent China-based industrial-automation distributor and sourcing desk — we line up the candidate PLC and write the cross-reference report, and we do not represent the engineering cutover, the program conversion, or the on-site commissioning that the swap requires.

Data Notes

Dateline: as of September 2026. Byline: by the aoctrl sourcing desk.

Catalog grounding: FX5U-32MT/DS (aiDemandScore 87.46), FX5-4LC (87.44), FX5-ENET (87.28), FX3U-32MT/DS (legacy reference), R60DAI8 (87.68). Each candidate is sourced from the aoctrl catalogue with per-line condition (new surplus / refurbished / used) and per-line lead time stated on the quote. aiDemandScore is a directional planning figure, not a market price or stock count.

Methodology: the twelve-axis cross-reference framework used in this article is documented in automation-substitution-axes.json (claim ladder level 1 default). Every cross-brand recommendation is closed with the verification clause against the original manufacturer datasheet and the customer's own qualification process.

Out-of-scope axes explicitly declined by the desk: functional-safety integrity, non-implantable medical devices above Class I and implantable medical-device qualification, high-assurance process control, weapons-platform and export-controlled end-uses, and any axis that would require the desk to hold a certification it does not hold. Substitution-claim ledger filed with seven requires-redesign entries; no claim rises to drop-in, pin-compatible, or functionally equivalent on cross-brand cases.

Independent-distributor disclaimer: aoctrl is an independent distributor, not an authorized distributor of any manufacturer mentioned in this article. Manufacturer names, series names, and part numbers are cited for cross-reference purposes only.

FAQ

Can I drop in a different PLC family without rewriting the program?

No. Cross-brand, cross-family drops do not execute an existing program as-is. Inside a single vendor, same-platform migrations (FX3U to FX5U within Mitsubishi) reduce the work to rebuilding the project file, re-importing variables, and re-linking I/O, but the program is still re-engineered. The cross-reference report lists which axes match and which do not.

What survives an FX3U to FX5U migration inside Mitsubishi?

Electrical supply voltage, output-driver topology, and the general-purpose I/O count survive in matched form. Form factor, front-connector pin-out, engineering software (GX Works2 to GX Works3), serial-to-Ethernet communication transition, and FX3U-4LC to FX5-4LC special-function configuration all change. Project files require conversion, not direct load.

What breaks the moment I cross from one PLC brand to another?

The instruction set, the I/O addressing model, the engineering software, the fieldbus/master-slave role, and the special-function module configuration all break. Wiring and mechanical layout typically break as well. The cross-brand reference is a re-engineering project, not a parts swap.

Is there any case where a PLC swap is declined by this desk?

Yes — operator-protection loops and rated protection equipment, process-critical or regulated end-uses (pharmaceutical GAMP, non-implantable medical devices above Class I and implantable medical devices, high-assurance process control), weapons-platform or export-controlled end-uses, and OEM-locked systems. In those cases the desk declines to propose a substitute and refers the decision back to the customer's protection engineer, certification body, or OEM. Sterilization, biocompatibility, and quality-system qualification belong to the equipment owner, not the desk.

What does a written cross-reference report actually contain?

The candidate controller and I/O configuration tied to manufacturer part numbers; the twelve axes run against the original configuration with matched, differs, or unknown stated for each; the substitution-claim ladder stated in plain language; a verification clause requiring the customer to qualify the swap themselves; and an explicit list of axes the desk will not certify (functional safety, medical qualification).

How long does the cross-reference report take?

The desk quotes a turnaround per order, based on the candidate set and the depth of the axis-by-axis accounting required. Send the part list to /inquiry with the original CPU model, I/O configuration, special-function modules, communication network, and end-use description, and the desk will respond with a candidate set and a quote.

What if the original PLC family is still in production?

The desk will ship the original and not write the cross-reference report. The report is only useful when the engineering team has to make a substitution decision; if no substitution is required, no report is required. The catalogue includes current-production Mitsubishi FX5U, FX5-ENET, and FX5-4LC entries, and the same logic applies to any other vendor.