Ladder Logic 301: Toggle
Today’s post is the first “advanced” topic I have covered in this blog. By advanced, I mean that rather than covering basic information on Ladder Logic and program structure like I did in my 100 Series, or general programming routines as I did in the 200 Series, I am going to cover some of the “tricks” and techniques that are used in PLC programming. They may not seem advanced to everyone who reads this blog, but these 300 level topics will be things that as far as I know aren’t really covered anywhere else.
The simple logic above performs an important function that is often needed in a PLC program. It replicates a toggling pushbutton that may be either hardware or software based. The generic pushbutton, IN 2.0, might be a hardware (momentary pushbutton) or software (HMI momentary PB) button. Momentary pushbuttons, as opposed to maintained pushbuttons, are only in the ON state as long as you hold your finger on the button. A toggling or maintained button on the other hand changes from ON to OFF or vice-versa every time the button is pressed, maintaining its condition until pressed again.
Since maintained pushbuttons are already available in both hardware and HMI versions, why would you want to use a circuit like this to turn a momentary button into a maintained one? One important reason is that you can use software to reset all buttons to the off state under certain conditions, such as E-Stops or start-up. Another might be that maintained hardware buttons generally cost more than momentary ones.
The circuit above introduces a new element that I haven’t covered in previous ladder logic posts, the one-shot. I have mentioned before that my goal for this series is to use a generic language to describe my ladder logic diagrams so that they might be used for any platform. In some cases such as this, there is no way to make the diagram reflect all PLC software programs. For instance, Allen-Bradley has two different methods of showing one-shots. One is the OSR (One Shot Rising) bit which is similar to the one I have shown above in that it is placed in series with an output instruction. When the program is scanned, if the contact or conditions before the OSR are true (a “rising” or on pulse), the instruction will be on for one scan. It will then turn off the next scan and not re-energize until the condition goes from off to on again. Since a scan is very short period of time (usually 5-30 ms or so), a one shot is not useful for physical outputs but is often used in a latching or counting application.
In the case of Omron, a one shot is called a DIFU (Differentiate Up) or DIFD (Differentiate Down). The instruction is placed at the right end of the rung next to the rail as an output coil. Siemens uses a P (Pulse) or N (Negative Pulse) instruction, while Allen-Bradley’s ControlLogix platform also has a ONS coil that uses two bit addresses, one for storage and one for the output. The idea behind the one-shot is the same in every case, it just has a different method of implementation.
The previous information explains how the first rung works; it generates a one-scan pulse every time the pushbutton is pressed. What about the second rung? OK, here goes: during the first scan after the one shot is active, the PB_TGL_ON bit is in the off condition, so the rung becomes true, activating the PB_TGL_ON bit after evaluating all of the preceding instructions. On the next scan, the PB_ONESHOT_OUT bit is off, the PB_TGL_ON bit is still on, which keeps the bit latched using the bottom part of the parallel logic. (This is also known as a hold-in branch as described in my Ladder Logic 205: System Routine post from mid-May).
The next time the button is pressed, the upper and lower parallel branches both become not true, unlatching the PB_TGL_ON bit. Whether the physical pushbutton is held or released, on the next scan the PB_ONESHOT_OUT bit will be in the off condition. The state of the rung is therefore just as it was at the beginning of this description.
A few notes on what I am working on: I am hoping to create a software program that uses the generic programming language shown here for training. As I have mentioned previously, I am trying to transition out of the contracting work I have been doing and more into the consulting and training business. As part of this effort I will no longer be doing contract programming and design after August 1, 2013 but will be concentrating on book promotion and developing training and consulting materials, primarily on my other website. I expect to formally launch that site on September 1, 2013.
If anyone who reads this blog either programs using Windows API based software or knows someone who does, I am looking for someone to help develop this training software. If you have any suggestions on what kind of programming platform (C#? Java? Other?) to use in writing this software I would appreciate it. Ultimately I would like to not only use it to draw logic, but also to emulate the program and maybe even drive Ethernet-based I/O. I am willing to invest whatever is necessary to get this done as I plan to use it extensively in my programs.
I will also be creating a number of training videos on PLC programming, hardware, automation, troubleshooting, pneumatics, servos, vision and whatever else comes to mind. This is in addition to training and consulting in person. If anyone has suggestions on any of these projects please leave a comment or e-mail me directly. For those not familiar with the content of my book Industrial Automation: Hands On, that will be the outline of the overall course materials I plan to generate.