PLC

  Firmware is the operating system that runs on the controller. Project revision is the format version of the .ACD file. These two numbers are frequently confused, and the confusion is expensive. A maintenance engineer who mistakes one for the other can convert a healthy project into a file that no installed software can open, or send a running production line through an unplanned firmware download for which no backup exists. Correct terminology follows Rockwell Automation usage: Logix Designer, ControlFLASH, RSLinx Classic, FactoryTalk Linx, and the Product Compatibility and Download Center (PCDC).   1. Definitions   1.1 Controller firmware   Firmware is the executable operating system stored in nonvolatile memory on the controller. For a ControlLogix or CompactLogix controller, the firmware implements the Logix execution engine: it runs the task model, executes the routines, communicates over the backplane and the network, and provides the services that Logix Designer calls during an online session. A controller without firmware is inert. New controllers ship from the factory with firmware already loaded, and the same physical hardware can run different firmware revisions over its service life. Rockwell identifies firmware by a revision number. The revision is the number shown in RSLinx Classic or FactoryTalk Linx when the engineer browses to the controller, and it is the number that must be weighed against the software version on the PC. When this guide says "controller revision," it means that firmware revision number.   1.2 Project revision   A Logix Designer project is a single file with the .ACD extension. The file has its own format version, and that format version is the project revision. When a dialog says "project revision 32," it is describing the file format, not the controller. The project revision is written into the file by the software that created or last saved it. The project revision and the controller revision usually match in a healthy system, because Logix Designer creates a project at the revision of the controller it targets. The match is a convention, not an identity. A project at revision 32 can target a controller at firmware 32, and the two numbers happen to be equal. The confusion begins when an engineer treats the project revision as if it were the controller firmware, or the controller firmware as if it were a file property.   1.3 Software version   The software version is the version of the installed application: RSLogix 5000 for versions 1 through 20, and Studio 5000 Logix Designer for version 21 and later. Rockwell renamed RSLogix 5000 to Studio 5000 Logix Designer starting around version 21, released in 2012. The change was a rebranding and a packaging change, not a new product. The application that opens .ACD files is the same lineage, and the version numbering continued without a break. Version 20 is therefore RSLogix 5000, and version 21 is Studio 5000 Logix Designer. The name matters only near that transition point. An engineer should read "Studio 5000 version 32" and "RSLogix 5000 version 20" as the same kind of quantity. Each software version has a native project revision. Studio 5000 Logix Designer version 32 creates and edits projects at revision 32. The software can open projects at older revisions under conditions described below, and it can create projects for controllers at older firmware revisions under conditions as well. The native pairing is the relationship that matters: software version N pairs with project revision N and controller revision N.   1.4 Module firmware   The controller is not the only device with firmware. Every intelligent module in a Logix system carries its own: the 1756-EN2T Ethernet communication module, the 1756-IB16 and other discrete I/O modules, the 1756-IF8 and other analog modules, the 1756-CNB and 1756-DNB bridges, and the 5069 and 1769 I/O families. Each module has its own firmware revision, and each is updated separately with ControlFLASH. Module firmware matters for two reasons. The project stores the expected firmware revision for every module in the I/O configuration, and Logix Designer compares expectations against reality at online time. Communication modules also sit on the online path to the controller, so a module with incompatible firmware can block the connection before the engineer ever reaches the controller. Module firmware and controller firmware are updated with the same tool, but they are different operations, and an upgrade plan must treat them separately.   2. The compatibility model   The compatibility model has three inputs: the software version, the project revision, and the controller revision. The rules below describe how the three may combine. Once the rules are stated, every dialog and every failure mode becomes readable.   2.1 Project files: no forward compatibility, limited backward compatibility   A project saved by a newer version of the software cannot be opened by an older version. This rule has no exceptions in the Logix product line. If a project was created and saved in Studio 5000 Logix Designer version 33, no installation of version 32 can open it. The older software does not understand the newer file format, and Rockwell does not ship a downgrade converter for project files. Backward compatibility exists and is limited. An older project opens in newer software, and the newer software converts it. The conversion is one-way. After the newer version saves the file, the project revision has advanced, and the older software can no longer open it. A project at revision 20 that is opened in version 33 and saved becomes a revision 33 project. The original revision 20 file is gone unless a copy was kept. This is the first expensive failure mode. An engineer opens an old project to look at a routine, the software prompts to convert, the engineer accepts, saves, and the plant loses the ability to open that project with the old software that still matches the running controllers. The safe practice follows directly from the rule: keep the original file untouched, and convert into a new file name.   2.2 Software version and controller revision: the online requirement   Going online is the operation where software and controller meet directly. Logix Designer establishes a communication path through RSLinx Classic or FactoryTalk Linx, finds the controller, and compares versions. The comparison is strict. To go online with a controller, the software version must be compatible with the controller's firmware revision. The practical expression of the requirement: software at a version equal to or newer than the controller revision can go online. Software older than the controller revision cannot. A controller at revision 32 requires software at version 32 or newer. Version 31 cannot go online with that controller, and no driver setting or compatibility mode changes that fact.   2.3 Upload and download   Upload is the transfer of the project from the controller to the PC. Upload works when the software version is equal to or newer than the controller firmware revision. The software reads the program from the controller, reconstructs a project, and writes the file at the revision of the controller it read. Uploading from a controller at revision 24 with version 32 software therefore produces a project at revision 24, and that file is openable by software at version 24 or newer, including the older software the plant already owns. Uploading with software older than the controller revision is not possible: the older software cannot interpret the data structures of the newer controller. A controller at revision 32 with only version 30 software available cannot be uploaded. The fix is to obtain version 32 software or newer, not to attempt workarounds. Download is the transfer of the project from the PC to the controller. Download requires the project revision to match the controller revision, unless the engineer explicitly changes the controller revision as part of the download. When the revisions differ, Logix Designer offers to change the controller revision before it downloads the project. Changing the controller revision means flashing new firmware into the controller. There is a legitimate way to make the two sides match without a conversion: the New Project dialog in Logix Designer offers a revision list for the selected controller, and that list includes revisions older than the software version. A plant with version 32 software can create a project at revision 24 for a v24 controller, and the file is written at revision 24. This is how an OEM produces a deliverable that an older software version can open, and it is the correct tool when the project revision and the controller revision must be aligned by design. The download path is where the second expensive failure mode lives. The change-controller-revision prompt appears during a routine download, an engineer accepts it without reading it, and the controller receives new firmware. A running machine whose controller was never backed up loses its program if the flash fails partway. Even a successful firmware change can leave I/O connections and module firmware expectations in an inconsistent state, because the new controller revision may expect newer module firmware than the chassis actually runs.   2.4 What the revision mismatch dialogs actually mean   Three dialogs dominate the field reports. The first is the project open error. The software reports that the project was created with a newer version of the software and refuses to open the file. No workaround exists inside the older software. The fix is to obtain the newer software version, or to ask the source of the file for a copy at the plant's revision, which the newer software can produce for projects it can open. The second is the Go Online mismatch. The software finds the controller, sees a revision difference, and offers to change the controller revision. Accepting the offer flashes the controller. The dialog is a request for permission to change firmware, not a notice. The safe response is Cancel, followed by a decision about which side should move: install matching software, or plan a controlled firmware upgrade. The third is the download mismatch with the change-controller-revision option. It is the same operation as the second, reached through a different path. The meaning is identical: the project revision and the controller revision differ, and the software proposes to make them equal by writing new firmware to the controller. The Who-is-online list in Logix Designer shows the engineers currently connected to each controller and the controllers each connection targets. It belongs in this discussion because the Go Online sequence is where an engineer first sees the revision of the target controller, and where an unplanned acceptance of the change-controller-revision offer does its damage. The dialog appears once per online attempt, it is phrased as a routine question, and the cost of accepting it without preparation is an altered or bricked machine. The Go Online flow is also where the engineer sees whether the controller can be reached at all: if the communication path fails before the version comparison, the problem is the driver or the network, and if the comparison fails, the problem is the revision.   2.5 Why the three numbers line up   The alignment of software version, project revision, and controller revision is not accidental. When an engineer creates a new project, Logix Designer asks for the controller catalog number and for the controller revision. The project file is written at the selected revision, and that revision is stored as the target. A healthy machine runs a controller at the revision the project targets, and the project lives at the revision of the software that manages it. Drift in any one of the three numbers produces one of the dialogs above. Online edits add a second kind of drift. An engineer who goes online and edits logic changes the program stored in the controller without changing the .ACD file on the PC. The controller and the file now differ, even though every version number matches. This is why a full upload belongs in any upgrade procedure: the upload captures the actual state of the controller, including edits that were never saved to the file.   2.6 Common situations, read through the model   Four situations recur in support requests, and each one is the compatibility model in action. Situation one: an OEM sends a project file at revision 33, and the plant runs Studio 5000 version 30. The file will not open. The plant either installs version 33, or asks the OEM for a project at revision 30, which the OEM's newer software can create. Neither option changes the controllers, so the plant's existing online capability is unaffected. Situation two: a replacement controller arrives from the warehouse and the plant cannot go online with it. The replacement was flashed to a newer firmware revision than the plant's software supports. The options are to flash the replacement down to a revision the plant's software supports, if that revision exists for the catalog number, or to upgrade the plant's software. Flashing down is a firmware operation with the same risks as any other flash, and it needs the same backup discipline. Situation three: an engineer downloads a project and the software asks to change the controller revision. The engineer accepts, and after the download the I/O tree shows module faults. The controller revision moved, the module firmware did not, and the project's module expectations no longer match the chassis. The fix is a planned module firmware upgrade, which is why the procedure in section 6 treats the whole chassis, not only the controller. Situation four: an engineer cannot upload from a controller that a contractor upgraded during commissioning. The contractor flashed the controller to revision 32 and the plant owns version 30 software. Upload is impossible until the plant obtains version 32 or newer. This situation is common after third-party work, and it is why the controller revision belongs on any handover checklist.   3. Hardware firmware limits   Each controller family has a range of firmware revisions it can run. The figures below are the well-established limits. Rockwell adjusts support policy over time, and the authoritative source for any specific catalog number is the Product Compatibility and Download Center (PCDC). Check the PCDC before planning an upgrade. A firmware revision that does not exist for a given catalog number cannot be selected in ControlFLASH in any case. Controller family | Catalog numbers | Maximum firmware (typical) | Notes ControlLogix 5560 | 1756-L61, 1756-L62, 1756-L63 | approximately v20 | Rockwell ended feature development for the L6x family at that point. The exact supported range depends on the catalog number; check the PCDC. ControlLogix 5570 | 1756-L71 through 1756-L75 | approximately v24 | The L7x family tops out near v24. Check the PCDC for the exact range. ControlLogix 5580 | 1756-L81 through 1756-L85 | v24 and newer | The L8x family requires v24 or newer and will not accept older firmware. ControlLogix 5580, E series | 1756-L81E through 1756-L85E | v28 and newer (general) | The 5580 family generally requires v28 or newer. Check the PCDC for the current maximum. CompactLogix 5370 | 5069-L306ER and related 5069 catalog numbers | v30 and newer (general) | The 5069 family generally requires v30 or newer. Check the PCDC for the current maximum. CompactLogix 5370 | 1769-L16ER through 1769-L37ERM | approximately v20 to v36 | The supported range depends on the model and on Rockwell support policy. Check the PCDC for the exact figure for your catalog number. Three practical consequences follow from the table. First, an L61 at revision 20 cannot be upgraded to revision 24; the hardware does not support it, and no firmware file at revision 24 exists for that catalog number. Second, an L81 cannot run revision 20 firmware; the controller requires revision 24 or newer and will not accept older firmware. Third, the maximum firmware for the 5580 and 5069 families is a moving target: Rockwell publishes new revisions over time, and the current maximum is exactly the kind of figure the PCDC exists to state. When a plant plans a migration from an L6x to an L8x, the firmware jump from approximately v20 to v24 or newer is part of the project scope, along with the software jump from RSLogix 5000 to a newer Studio 5000 version. The same reasoning applies to a migration from a 1769 CompactLogix to a 5069 CompactLogix: the new controller family sets a new firmware floor and a new software floor, and the old project must be converted into a new project at the new revision before it can be downloaded. Hardware that has reached the end of its firmware range is often the same hardware that has become hard to source, which is why Allen-Bradley spare parts for legacy ControlLogix and CompactLogix platforms remain a normal procurement item for plants that cannot migrate yet.   4. Multiple software versions on one PC   Multiple versions of RSLogix 5000 and Studio 5000 Logix Designer can be installed on the same PC. Rockwell designed the installers to coexist, and many engineers do run version 20 and version 32 on one machine. The coexistence is workable, and it is messy. Licensing is the first complication. RSLogix 5000 and Studio 5000 use FactoryTalk Activation, and each software version needs its own activation. An activation that covers version 32 does not automatically cover version 20. A plant that keeps both installed must keep both activations valid, and an expired activation for one version surfaces as an error that looks like a software fault. Windows compatibility is the second complication. The oldest RSLogix 5000 versions predate modern Windows and do not run on Windows 10 or Windows 11. Version 20, for example, was released in the Windows XP and Windows 7 era, and running it on a modern operating system typically requires a virtual machine. The compatibility matrix in the PCDC states the supported operating systems for each software version. The honest summary: the older the software, the older the Windows it needs. Coexistence itself is the third complication. Different versions share services such as RSLinx Classic and FactoryTalk Linx, and version conflicts surface as drivers that disappear, activation errors, and projects that open in the wrong application when file associations point at the last installed version. A version that worked alone can start failing after a second version is installed. The common engineering solution is a dedicated laptop or a virtual machine per version. A plant with controllers at v20 and at v32 keeps one machine with RSLogix 5000 v20 and one with Studio 5000 v32, and does not mix them. The pattern costs hardware and desk space, and it buys certainty. A plant that keeps a v20 machine alive is usually the same plant that keeps PLC spare parts on hand for hardware Rockwell no longer sells. The virtual machine approach has an extra advantage: the VM image itself is a backup, and a corrupted installation is restored by copying the image rather than by reinstalling the software and re-entering activations.   5. Module firmware versus controller firmware   A Logix chassis contains the controller and its modules, and each module runs its own firmware. The project stores the expected firmware revision for every module in the I/O configuration. When Logix Designer goes online, it compares the expected module revisions against the actual revisions in the chassis and reports differences. Module firmware is updated with ControlFLASH, the same tool used for the controller. The operation is per module: select the module in the flash tool, select the target revision, and flash. The 1756-EN2T Ethernet module is the module most often flashed, because its firmware controls the network path and because Rockwell publishes new EN2T revisions to correct communication defects. The practical rule: module firmware upgrades belong in the same maintenance window as controller firmware upgrades, and they are verified with the same discipline. A project that expects EN2T revision 5 on a module that runs revision 3 produces a mismatch at online time, and the mismatch either blocks the connection or degrades it, depending on the module and the size of the difference. Keep module firmware consistent with the project's expectations, and change both sides deliberately, never one side by accident. A controller firmware upgrade that raises the controller beyond the firmware of its communication modules is a common source of module fault and connection failed reports after an otherwise clean upgrade.   6. The safe firmware upgrade procedure   The procedure below is ordered. Every step exists because a skipped step has caused a real failure. Follow the steps in sequence, and do not merge steps. 1. Verify the current state. Open RSLinx Classic or FactoryTalk Linx, browse to the controller, and record the current firmware revision. Record the revision of every module in the chassis as well, from the I/O configuration in the project or from module properties. The record is the baseline for the entire operation, and it is the reference for the post-upgrade verification. 2. Back up the project. Close the project, copy the .ACD file to two separate locations, and record the project revision. Do not convert the project as part of the backup. The backup must be a byte-for-byte copy of the file that matches the running system. 3. Perform a full upload. Go online with the current software, upload the project from the controller, and save the uploaded copy under a separate name. The upload is the second backup, and it is the one that matters if the .ACD file and the controller have drifted apart. Controllers can contain logic that the file does not, because engineers make online edits. The upload captures the actual state. 4. Check the compatibility matrix in the PCDC. Verify three things: the target firmware revision exists for the controller catalog number, the software version planned for the post-upgrade connection supports that firmware revision, and that software version runs on the operating system of the PC that will go online. A failure in any of the three cancels the upgrade until it is resolved. This step also identifies the module firmware revisions that the target controller revision expects, so the module list from step 1 can be checked against it. 5. Confirm the maintenance window. A firmware download interrupts the controller. The controller stops executing the program for the duration of the flash, and I/O connections drop. Confirm that the process can tolerate the interruption, that the operators have been informed, and that the machine is in a safe state. Do not upgrade a running machine outside a maintenance window, and do not upgrade a machine in the middle of a batch. 6. Run ControlFLASH. Launch ControlFLASH, select the controller, select the target revision, and start the flash. Do not interrupt the flash once it starts. A power loss or a communication break during the flash can leave the controller with a corrupt firmware image. The controller may recover through a boot mode, and the recovery is not guaranteed. Wait for the completion message before touching anything. 7. Verify the result. Power-cycle or reset the controller as the flash tool directs. Go online with the planned software version and confirm that the revision shown in Logix Designer matches the target. Check the I/O connections: every module in the I/O tree should show its expected state, and module firmware mismatches surface at this point. Confirm that the program runs: place the controller in Run mode and observe execution, task timestamps, and I/O values. Keep the pre-upgrade backups until the machine has completed a full production cycle on the new firmware. Module firmware upgrades follow the same procedure, with step 6 repeated for each module. The verification in step 7 then checks the module revisions in the I/O tree instead of the controller revision.   7. Firmware upgrade checklist   Condensed checklist for the maintenance planner: · [ ] Baseline recorded: controller revision and module revisions documented · [ ] Project backed up at its current revision, two copies, not converted · [ ] Full upload performed and saved under a separate name · [ ] PCDC checked: target firmware exists for the controller catalog number · [ ] PCDC checked: planned software version supports the target firmware · [ ] PCDC checked: software version supports the PC operating system · [ ] Module firmware expectations checked against the target controller revision · [ ] Maintenance window confirmed with operations · [ ] Machine in a safe state, no active batch · [ ] ControlFLASH run to completion without interruption · [ ] Controller reset or power cycle performed as directed · [ ] Online verified: controller revision matches the target · [ ] I/O connections verified module by module · [ ] Program confirmed running in Run mode · [ ] Pre-upgrade backups retained until one full production cycle completes   8. FAQ   Q1. Can version 30 open a project saved in Studio 5000 version 32? No. A project saved by a newer version cannot be opened by an older version. Version 30 cannot read the revision 32 file format. Obtain version 32 or newer, or ask the source of the file for a copy at revision 30. Q2. What does the controller revision mismatch message mean when I go online? It means the software version and the controller firmware revision are not compatible, and the software offers to change the controller revision, which writes new firmware to the controller. Cancel the offer unless the change is planned, backed up, and scheduled. Q3. Can I upload from a controller whose firmware is newer than my software? No. Upload requires software at a version equal to or newer than the controller revision. Install matching or newer software before the upload. Q4. Is a firmware upgrade reversible? A controller can be flashed back to an older revision if that revision exists for the catalog number. The reversal is itself a firmware operation with the same risks. A converted project is not reversible: once the newer software saves a converted file, no older software can open it. Q5. Can I run version 20 and version 33 on the same PC? In principle, yes. The practical limits are licensing, Windows compatibility, and shared-service conflicts. Version 20 does not run on modern Windows without a virtual machine. Most plants use a dedicated laptop or VM per version. Q6. What is the difference between controller firmware and module firmware? Controller firmware is the operating system of the controller. Module firmware is the operating system of each individual module, such as a 1756-EN2T. Both are updated with ControlFLASH, and both must match what the project expects. Q7. Where do I find the exact maximum firmware for my controller? In the Product Compatibility and Download Center (PCDC) at Rockwell Automation. The PCDC states the available firmware revisions for each catalog number and the compatible software versions. Consult it before every upgrade.   9. The rule that governs every case   The compatibility model reduces to one sentence: the software version, the project revision, and the controller revision must form a consistent set, and every change to one member of the set is a planned operation. A project file that will not open, an online session that will not start, and a download that wants to change controller firmware are all the same underlying condition: the set is inconsistent. The engineer's job is to identify which member is out of line, decide which member should move, and move it with a backup and a maintenance window in place. For plants that run legacy hardware, the set has a fourth member: the hardware itself. A controller whose firmware range has ended is a controller whose spares are scarce, and the planning horizon for a migration starts at the moment the firmware limit is reached. Allen-Bradley spare parts and ControlLogix spare parts keep legacy lines running while the migration is planned, and the version discipline in this guide keeps the software side of the set stable for as long as the hardware runs. The discipline costs little. The alternative costs a production line. URL Slug: studio-5000-firmware-version-management-guide ------------------------------------------------------------------------------------------- 🏢 About TZ Tech   TZ Tech is a leading supplier of industrial automation, electrical, instrumentation, and telecommunications components. We specialize in sourcing ready-to-ship distributor stock, allowing us to offer highly competitive pricing and short lead times. Thanks to our extensive inventory, we can even source rare and discontinued parts that are hard to find elsewhere.   🛡️ Our Quality Commitment   We understand that quality is your top priority. Every component undergoes a strict screening and inspection process so you can buy with absolute confidence. For legacy or discontinued parts, we believe in complete transparency and will always provide an honest, accurate report on the product's condition. Plus, all brand-new parts come backed by a full 1-year warranty.   ✉️ Get in Touch     Have a project or a part you need? Send us your inquiry today! Our team is dedicated to providing a fast response within 6 hours (excluding weekends).