Optimizing Single-Run PLC Bits and Tasks for Startup Processes

Executing a PLC program is a bit different than the way other programs generally process code. In typical environments, the first line is run, followed by each line of code under it. When a conditional statement or a looping subroutine is encountered, the program will pause in that section to handle whatever is requested. If possible (not inhibited by some program logic), the program will then pick up where it left off and proceed.

In a PLC using ladder diagram logic, all the lines are examined quickly during each cycle, which is extremely fast. The input conditions are scanned, and if any are true, the output signals on those lines are correctly energized.

 

Advantages and Disadvantages of Ladder Logic

A continuous scan is excellent for processes that run in cycles where system behavior is dependent on the condition of external properties. This includes pressure, level, object presence, and more. However, if a process is to run once or, if the process needs to run step-by-step, such a constant scan of the ladder may be less helpful. 

One key problem lies in the initial startup of a machine center. In most cases, right at power-up, the PLC must read the value of sensors, obtain data from a batch recipe, or examine external devices for network faults before beginning the process. This initial startup can be a logical challenge in the confines of ladder logic, but fortunately, there are a few options to help out.

 

Startup Bits or Flags

Nearly every PLC program has a built-in status bit that is energized on the first scan cycle. The startup bit can be attached to outputs or subroutines to examine any process information that is important before the program officially begins running. Perhaps all outputs in a module must be de-energized at the start of a program, or counters reset to zero to initialize the variables. This is all done via the startup bit.

Use caution to never place any instructions after this bit that is intended to perform a function sometime after startup, as it will not happen again. Additionally, use caution whenever attaching this bit to functions targeted for networked devices. If there is a network delay of more than one scan cycle (which is very likely), the commands may not execute at the end device. 

Examples of this startup bit or tag include:

• Allen-Bradley (Rockwell): S2:1/15 (for RS500) or S:FS and the Power-Up Handler task (for Studio/Logix Designer5000)
• Siemens: SM0.1 (for S7-200), organization block OB100 (for S7-300/400/1200/1500). This is not a bit itself, but rather an entire startup routine.
• Mitsubishi: M8002 (for FX series)
• Automation Direct: SP0 (for DirectLogic DL series), SBR-001003 or use the ‘First Scan Run’ task property (for Productivity series)
• Omron: 253.15 (C200 series), A200.11 (CJ series), P_First_Run (NJ/NX series)

 

Figure 1. Examples of startup bit (or task) strategies for various controllers: Logix families from Rockwell (top), TIA Portal from Siemens (middle), and Productivity from Automation Direct (bottom). Image compiled by the author

 

Get Your Startup Routines Right From the Start

This is similar to a startup bit, or flag. That single bit is only energized for one scan cycle, so it can be used to jump into one subroutine. On some PLCs, there is already a first scan routine (like the OB100 for Siemens), or a task type that can be set to “first scan only” (see the Automation Direct Productivity series). For Logix processors from Rockwell, a "Power-Up Handler" task can contain programs and routines dedicated to certain functions like clearing faults at startup.

Note that these flags or routines are always internal memory addresses, that is, they exist in the memory of the PLC. That means they will be energized the moment the PLC starts, regardless of the connection to the computer, any I/O devices and modules, or external equipment, so this is reliable. 

Depending on the PLC, this task set or single bit may also energize when the CPU is switched from Stop (or Program) to Run mode, which also indicates the starting point of the program. So if you expected it to only energize on a full power cycle, this may take you by surprise and cause unexpected results.

If you want to diagnose or verify this behavior, you can simply use the startup bit or flag to increment a counter or run an off-delay timer for a short duration. That counter or timer current value should be visible for sufficient time to verify that the startup bid did, indeed, energize for a moment.

 

Look for Conditions, Not Program Timing

In reality, the best solution may not be found in the startup timing of the PLC itself. Instead, think about the event you are trying to detect. When attempting to scan the network for faulted devices it’s likely best to design a specific routine for locating and handling faults any time they occur. For example, a network VFD may present a fault due to network dropout during the power cycle. That fault can trigger a subroutine which can likely identify the source of the fault and send a reset command. This has the added benefit of immunity to network lag which may prevent inputs and outputs from reaching connected devices within a single scan.

 

Figure 2. Realistically, the best programming solution may not be found in PLC startup timing. Try thinking about the event you are trying to detect. Image used courtesy of Adobe Stock

 

Plan First, Then Program

Engineers are often tempted to jump right into the programming phase without understanding exactly what steps you will need to include. And certainly, one will always have some troubleshooting and editing to accomplish. However, a careful planning phase to know exactly what you need to accomplish is prudent and necessary.  Engineers and technicians can save time and effort by programming initial routines right the first time.

 

Featured image used courtesy of Adobe Stock