66460eada5933f5c86bd6d9d Shutterstock 782843047

A history of packaging machine control

May 16, 2024
The evolution of PLCs and PACs and the acceptance of newer programming languages have opened doors for industrial automation

As many of you know, I live and breathe consumer products packaging, specifically the packaging machinery itself. I have managed to eke out an existence for more than 35 years in this fascinating part of the industry, and I would have to say I am rather passionate about the subject matter.

Controllers in packaging machinery are my focus pretty much every day. The world around packaging and automation is changing, and a fair evaluation of what goes into controlling a packaging machine might deserve a broader stroke of the brush.

Coming immediately after graduation from college in Ontario, Canada, my first job was with an integrator that is now one of the largest in North America. They were newly formed when I joined, and, while I cannot take credit for what they are today, that early practical introduction to the world of automation literally changed my life.

Like most interns and post-graduates, I started out doing computer-aided drafting (CAD) for the three engineers that I worked with. It was an excellent way to learn best practices for design while perfecting CAD skills that I use to this day.

Feeding my youthful thirst for knowledge, I soon found myself working with Omron processors, the little brick variety, to come up with programs for a company just down the highway that built heat exchangers for, primarily, the automotive industry. This was a great way to get into programming and test instrumentation. Back in those days, the Omron was programmed by a handheld unit that worked with Boolean logic entered in mnemonic code. Using LD (load), AND, OR, OUT were how we made programs.

Following closely on that first programming experience, my boss sent me out on a job at an onion pickling plant that produced the little version that one might find in a cocktail. I used to eat them right out of the bottle. The process was to harvest the onions mechanically and run them through various stations that would first wash and then chop the tops and roots off the onion ball and then send them through further processing that would result in onions in a pickling brine in bottles.

This was my first introduction to the Allen-Bradley family of processors. Now some of you that are familiar with Allen-Bradley might be thinking of a 1747-series SLC product or the 1771-series PLC-2 or PLC-5. Well, this product preceded those venerable products. This particular product was based on the 1741-series I/O system and the controller was a 1742-LP120A modular automation controller (MAC). Like the Omron controllers, this also used mnemonic code but had a rudimentary disk operating system (DOS) software that permitted some very basic ladder logic editing. I wonder if any of you remember the 1742 MAC. It happened long before Apple came up with its own Mac—the Macintosh computer.

Over the next five years, I gained experience with the SLC-500, PLC-2, PLC-3 and PLC-5, each one a generation newer in processing capabilities. As everyone can attest, life happens, and, with it, comes new opportunities. I moved on to an original equipment manufacturer (OEM) and continued to expand my experiences with the SLC-500 and PLC-5 platforms. By this time, we were approaching a new century, and it came with a significant shift in the type of processor that I would work with.

In 1997, the ControlLogix family of processors from Allen-Bradley was brought to life. The most significant change in this new series was a switch from memory-based to tag-based programming.

In memory-based tags, the base memory of the processor was broken up into files. Each programmable logic controller (PLC) had pre-defined files, as well as user-defined files. The two base files are Output and Input. Additional files of Status, Binary, Timer, Counter, Control, Integer and Float complete the base files. Each file is an array of the data type specified by the file type. User-defined files can be any of the base file types. Files come with a pre-defined starter size and can be grown or shrunk to suit the actual use of the array of tags for each data time. Memory files have a finite size, however. All of the data files are added together to make up the total size of data memory in the processor. A file can only have one data type, and all of the elements in that file must be of that same data type, as well.

In a tag-based system, the data types can have custom names to make the use of them more user friendly. For instance the Binary file B3 can be described simply as Binary and the reference to B3:3/1 (file 3 of type binary, word 3, bit 1) would be referenced in the tag-based system as Binary[3].1 since Binary replaces the B3 in the memory-based system.

Unlike the memory-based system, a tag-based system can have multiple data types in the same tag. For instance, a tag defined as Motor can have an array of binary bits, an array of integer words, a string element, an array of timers and an array of counters, all defined in the same base tag called Motor. These are commonly called user-defined tags (UDTs). This can simplify the tag structure of a program by creating a base UDT and then defining multiple instances of that same UDT. In the program we might have Motor104, Motor 113 and Motor 126 that are all of UDT-type Motor.

This evolution of the PLC clearly helps with organization and definitions, but it all gives a nod to the future of PLCs. Traditionally, we have seen the evolution from mnemonic code—Boolean gate logic—to graphic-based ladder diagram (LD), but this also evolved into function block (FB) and structured text code. Function blocks are custom blocks of code, much like a user-defined tag, that can be used in multiple instances to perform the same logic but with different tags/devices. A single function block could be defined to match up with the UDT to control the three motors but re-using the same generic code for all three. Structured text is a more robust version of mnemonic code, resembling Basic or C- programming languages.

This has all been leading is to a point where information technology (IT) and operational technology (OT) meet. Structured text has been the common way to program in the IT world for decades. Structured programming languages like Basic, ForTran, C, C+, C++, HTML, Python and many more use tag-based memory and are the basic building block of every software application.

Home computers and smart phones all use code that starts out as structured text. The OT side of things—the PLC of yesterday and the programmable automation controller (PAC) of today—has used the ladder, function block and structured text forms of programming for the same years. Now these different approaches to programming are coming together.

The PAC takes into consideration that the ladder-logic programmer may soon be a thing of the past. I hate to think of myself as obsolete, but I don’t really see many following in the traditional path. What we do have, however, are many people coming out of college and tech schools with great skills in software application development. HTML and Python programmers, to name just two, are highly in demand. The switch to processors in automation that accommodate programming in these languages is a natural evolution that certainly helps to leverage the popular OT application developers coming out of educational institutes to fill a steady need for software developers in automation.

The question of how to control a packaging machine is not as simple as it once was. While my initial response to the question would have been based solely on my own journey through automation and control, the real answer is whatever makes sense to the person writing the code. PLCs and PACs sending commands to devices on a network might work for those of us who came into this in the 1980s, but it might be just as right to start with a servo amplifier architecture where there is a built-in processor using a structured text programming language. Each is good and will give an excellent result but is entirely based on the skillset of the programmer.

The great thing about automation is there is more than one way to get the correct outcome, and, in many cases, taking an alternative path can yield unexpected and fortunate results. With the recent trend to combine control and safety into the same hardware platform, there is even more to be gained by embracing the newer technologies. So, how do you control a packaging machine? Any way you want. And you might even learn something new by trying something a little outside your comfort zone.

About the Author

Rick Rice | Contributing Editor

Rick Rice is a controls engineer at Crest Foods, a dry-foods manufacturing and packaging company in Ashton, Illinois. With more than 30 years’ experience in the field of automation, Rice has designed and programmed everything from automotive assembly, robots, palletizing and depalletizing equipment, conveyors and forming machines for the plastics industry but most of his career has focused on OEM in the packaging machinery industry with a focus on R&D for custom applications. 

Sponsored Recommendations

Power Distribution Resource Guide

When it comes to selecting the right power supply, there are many key factors and best practices to consider.

Safe Speed and Positioning with Autonomous Mobile Robots

Here are some tips for ensuring safe speed and positioning for AMRs using integrated safety technology – many of these tips also apply to automated guided vehicles (AGVs).

Faster, Accurate and Reliable Motion Control With Advanced Inductive Technology

This white paper describes new technology offering improved position measurement capabilities in reliability, speed, accuracy and more.

The Value of Dual Rated AC/DC Disconnect Switches

Why is it necessary for me to have a disconnect switch installed in my application?