Omron Ladder Logic

[Azalee Freas]

Thisdocument provides 28 examples of ladder logic programs for common functions using an Omron CP1E PLC. The examples cover basic logic instructions, timers, counters, latching circuits, and button controls. Each example includes a ladder diagram and corresponding instruction list to demonstrate how the logic is programmed in the PLC.Read less

My colleague shared with me a whole bunch of PMAC programs backed up from the machine. However, I didn't know where to start with those programs. I didn't see an explicit "MAIN" program to start, like in the traditional C program or real PLC program. I also have difficulties to map the I/O in the program to the physical sensors.

PLCs are logic PLCs which when enabled scan continuously until disabled by the user explicitly or from a program or PLC. In the Power PMAC script, there is no main, the user chooses which PLC or group to initialize first. They scan quasi-simultaneously. Often, PLCs are launched automatically from the startup.txt under the Configuration folder in the IDE.

Also, the I/O naming convention is bugging me a lot. The program has a macro definition for all the used I/O in the device. However, not being able to do the I/O cross reference in Pewin32PRO makes the programs really difficult to read.

First off, this post is in the 'Power PMAC' area. Since you have a Turbo UMAC be sure you do not use any Power PMAC or the original PMAC(1) documentation. You should download the Turbo PMAC2 info from

Get familiar with the I variables - they are used to configure or Initialize the card and axis. They are arranged in blocks of 100 (xx0-xx99) for each motor with the first block I0-I99 for universal card/system configuration.

Memory can be referenced in absolute addresses as 24 bit X: or Y: locations, and sometimes as both combined for a 48 bit Double, 48 bit float, single bit, etc. Check how to reference memory definitions using M pointers starting on pp 353 of the SRM.

Q0-Q8191 coordinate system variables. Partitioning of these is a function of how many coordinate systems are defined. Allows multiple instances of the same variable with each unique to its' coordinate system. Can be used as general purpose but some features reserve specific Q vars.

Both are essentially structured text, no ladder logic or FB is supported. IEC 61131 has come and gone over the years and was never popular, you really don't need it. Just think of the PMAC as structured text.

Please, post this under Turbo PMAC. I believe you're going to have to go through some training, no one can help you with your machine code. Machine builders should keep documentation of their configurations. The flow of PLCs start with PLC 1 typically, and is controlled by I5 on power-up.

Ladder programming has been the de facto standard for PLC and Machine controller programming for decades. It evolved from a circuit diagram, where the left hand vertical rail was positive and the right hand rail was negative. Traditionally relay logic was drawn between the two vertical rails. We still consider the program execution in Ladder from left to right, just like the power flow of a physical circuit (well "conventional flow", not electron flow!).

Ladder programming is very popular, because the IDE such as CX Programmer or Sysmac Studio draws the "power flow", an activated line from left to right and this conveys a lot of information. It can easily be seen why an output is not on, the "power flow" is interrupted for instance by a contact or a comparison that is not true. This visual feedback of the state of the program allows electricians to quickly visualize and interpret the state of the system. It is almost second nature because it emulates circuits very well.

However, as Machines, Programs, Functions and Function Blocks become more complex, we are hiding more complicated code inside of modules: programs are more modular, and Function Blocks wrap a lot of code into a single entity that the maintenance person only needs to be concerned with the outside of. The inside should be very well tested and robust and what we put inside a Function Block or Function can be either Ladder, or Structured Text. No matter what is on the inside, we can call the function or Function Block from Ladder or Structured text based programs.

I would have loved to have today's controllers 30 years ago when the applications were challenging for that days technology. Today's controllers, with the modern programming concepts would have solved the control requirements so easily, we would hardly be challenged. But as capabilities have advanced, so have the applications, and no matter how capable the controller becomes, applications constantly challenge what is possible. The edges of capability are on speed, complexity and data handling.

As Machine Controllers become more advanced, there is more technology merging from the IT space into the machine. OMRON machine controllers can directly interface with SQL databases and read and write data at high speeds. This was the realm of the PC as a middle man for a PLC, now this capability is built into the controller. They are also motion controllers, handling high speed trajectory calculations, they can control robots and execute the kinematics in real time, while also controlling the whole machine with dozens of high speed synchronous and independent axis control at the same time.

All the above is challenging which is the best language to use in Automation today. I grew up with Ladder, loved Ladder and hated Structured Text when I first started. Now I love Structured Text and do not enjoy programming in ladder anymore. I only write program samples for others in Ladder, any serious program, including the inside of any Function or Function Block I write is Structured Text.

Firstly what is challenging about Structured Text is interpreting it when it doesn't work as first expected, finding bugs is more challenging. It is a more intellectually challenging activity than looking at power flow on a Ladder diagram. But having said that, working with Structured Text requires a more disciplined approach. Untidy code stands out in Structured Text. Conversely, well structured code in Structured Text looks elegant and "correct". When you get the hang of Structured Text, you are probably going to prefer it. This is a very subjective statement however.

Performing math in ladder is generally quite messy. An operation is performed and the result is output, stored and reused in the next ladder instruction as an input. What can be done in a single line of Structured Text takes many, even dozens of lines of ladder to accomplish. As the code is more compact, you can see more of your machine control code on a single screen. We also work more with strings, and assemble complex operations for interfacing with web devices. Ladder is cumbersome for this, Structured Text has a clear advantage for any complex programming.

Structured Text is also more portable between controllers from different vendors, it is as simple as copy and paste being text based. Trying to copy Ladder code from one controller brand to another will never work. Structured Text is very handy for this.

In OMRON C series PLCs (eg CJ, CS, CP etc) the Structured Text implementation is not full IEC61131, they were developed prior to this standard and based in the days of proprietary instruction sets. Ladder contains the full programming instruction set while Structured Text does not. In these controllers, I would recommend always sticking with Ladder programming, otherwise you will not have the full instruction set at your fingertips.

However, Sysmac Studio is a completely different story being designed in an era of IEC61131-3 (a standard relating to Industrial Controllers), every Function and Function Block is available for use in Ladder or Structured Text. Sysmac Studio even allows the programmer to combine the best of both worlds: Ladder programs with blocks of Structured Text. Typically a programmer can get away with math or setting variable values in a Structured Tect block, even when maintenance staff demand Ladder code. There are circumstances where Structured Text is more readable and actually easier to understand than Ladder. So Structured Text is creeping into programs, even when by rights, the Maintenance Staff would object to it.

One of the concepts that all programmers should be using is State Model. State Model defines that the machine should be in one or more states that are clearly defined. For instance, the machine should be in Manual Mode or Auto Mode. It should be Idle or Starting, Running or Stopping while in Auto Mode. There are many different modes it could be in, but they should be very well defined and clear transitions from one state to another.

3a8082e126