The short answer
Studio 5000
Studio 5000 Logix Designer, the successor to RSLogix 5000, is the software that builds every ControlLogix and CompactLogix application. Its defining rule is that a project has a version equal to the major firmware revision of the controller it targets, so a plant with controllers on several revisions needs several versions of the software installed side by side, which the software supports. A project is one file that holds the controller configuration, the I/O tree, the tags, the user-defined types, the add-on instructions, and the programs; it exports to text for comparison and version control. The choices made at download time, whether to store the project documentation in the controller and whether to protect source, decide how recoverable and how maintainable the site is later. The compare tool and the emulator are the two utilities that separate a controlled change from a hopeful one.
Key points
- Project version equals controller firmware major revision; install the versions the plant needs side by side.
- One project file per controller; text export for compare and version control.
- User-defined types and add-on instructions are the site library; build them once and reuse them.
- Download with project documentation stored in the controller so the next engineer can upload comments and descriptions.
- Use the compare tool before and after every change, and the emulator for testing logic offline.
Versions
A controller at firmware revision thirty-something runs projects of the same major version, and the software at that version is what opens and downloads them. Installing a newer software version does not remove the older ones, and a plant keeps every version its controllers use. Updating a controller to a newer firmware is a project conversion: the project opens in the newer software, is saved at the new version, and is downloaded after the firmware update, with the original kept. Communication modules and I/O modules have firmware of their own, and the compatibility lists say which combinations are supported. The version record per controller is part of the asset inventory.
| Item | Notes |
|---|---|
| Project file | The working file; one per controller; keep dated copies |
| Text export | A complete text form of the project; used for comparison, for version control, and for importing pieces into other projects |
| Partial export | Routines, add-on instructions, and data types exported individually and imported elsewhere |
| Compare tool | Shows the differences between two projects or between a project and an upload, rung by rung |
| Emulator | A software controller that runs the project on a computer for testing without hardware |
| Activation | Licensing through the activation manager; editions differ by features; keep the activation details with the software record |
Building a site library
A user-defined type for a pump holds its command, its feedbacks, its alarms, its runtime, and its mode in one structure; an add-on instruction for a pump takes that structure and implements the start, stop, fail-to-start, fail-to-stop, and alternation logic once. Every pump in every controller on the plant then uses the same instruction with the same behavior, the SCADA graphics bind to the same structure, and a change to the pump logic is one edit in one place followed by a documented update. The same applies to valves, analog inputs with scaling and alarms, and PID wrappers. The library is exported, versioned, and stored in the engineering library.
Online editing
Logic can be edited while the controller runs: a rung is modified, tested in place while the original still executes, and then assembled to replace it, or cancelled. Structural changes, new tags of some kinds, I/O changes, and add-on instruction definition changes usually need a download, which stops the controller. Every online edit at a running plant is preceded by a saved copy of the project and followed by an upload and a compare, because the edit exists only in the controller until the project on the laptop is saved.
Documentation in the controller
Tag names travel with the download; comments, tag descriptions, and rung comments do only if the project is downloaded with the documentation stored in the controller, an option on recent revisions that uses controller memory. With it, an upload from the controller gives a maintainable project; without it, the upload has logic and names but no explanation. Set it, and keep the archive anyway.
Source protection
Routines and add-on instructions can be protected so that the logic cannot be viewed or edited without a key. It has its uses for a vendor package, and it is a liability for a plant that owns its own controllers: the key is lost, the vendor is gone, and the logic is a black box. A plant that accepts protected logic gets the key in escrow, or refuses the protection.
Frequently asked questions
- Can I open a project from a newer version in an older version?
- No. A project saved at a newer version opens only in that version or later. Keep the version record and the installed versions in step with the plant.
- The upload has no comments.
- The project was downloaded without the documentation stored in the controller, or the controller revision does not support it. Find the project archive from the integrator or the site records, and download with documentation next time.
- How do I keep two engineers from overwriting each other?
- One master project per controller in the engineering library, checked out for a change and checked back in with a dated archive and a compare report. The controller is the truth in between, and an upload with compare before any change catches an edit that was not checked in.
- Should the plant standardize on one version?
- As far as the hardware allows. Controllers of one generation can often be brought to one firmware revision in a planned program, which reduces the versions to maintain. Older controllers that cannot run newer firmware stay on their version until they are replaced.
Related topics
- ControlLogixField notes on the Rockwell Automation ControlLogix, the chassis-based controller of larger water plants: chassis and modules, tag-based memory and tasks, EtherNet/IP and older networks, controller redundancy, version matching, and what to check on site.
- CompactLogixField notes on the Rockwell Automation CompactLogix, the smaller Logix controller behind most lift stations and small plants: families and I/O, the two Ethernet ports, what it shares with ControlLogix and what it lacks, and what to check on site.
- Program OrganizationStructuring a controller program so that someone else can maintain it: a layout that follows the plant, one routine per job, standard device blocks, I/O mapped in one place, a fixed execution order, naming that means something, and comments that say why.
- PLC Program BackupsWhat a complete controller backup contains, how often to take one, where to keep it, why the upload from the running controller is not the master, and the verification that turns a folder of files into a recovery plan.
- Controller Program IntegrityKnowing that the program in the controller is the one that was approved: checksums and change counters, the scheduled compare against the trusted backup, signed and protected projects, what an unexplained difference means, and making the check routine.
- Documenting Firmware VersionsWhy the firmware version of every controller, module, drive, switch, radio, and instrument belongs in the inventory with the date it was read: advisories are issued by version. Where to read each one, the several versions one controller has, and the cadence.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.