Packaging automation integration advice from Avanceon

Automation and controls can help packaging implementations, and Avanceon offers project-related advice below by answering questions from Control Engineering. A packaging system filled 20 cases per minute from seven bakery lines. Controllers, code and networks required upgrading. The project had to be implemented during a three-day weekend.

Question: Can you please describe a recent packaging-related project? 

Answer: Over the past three years, Avanceon noticed a trend in packaging projects addressing system technology obsolescence. Packaging lines are traditionally an area of the factory that has to run 24/7/365 days a year, and, as a result, there’s often a feeling of “if it isn’t broke, don’t fix it.” In recent years, technology obsolescence has driven manufacturers to force packaging system upgrades. Common constraints and concerns are twofold.

1. There is never a good window of downtime.
2. The system needs to look and perform exactly like the system did before the outage to ensure that the operators accept the system.

A recent bakery packaging upgrade addresses those concerns. Avanceon helped upgrade Rockwell Automation-based PLC5/25 control systems that control and orchestrate the packaging area for a bakery. The packaging system consisted of 7 lines running at over 20 cases per minute. Due to the high number of lines that converge into this packaging area there was no room for errors in a very limited downtime window.

Q: What was the scope of the project and goals?

A: The scope of the project was to replace the PLC5/25 with 4 racks and over 60 modules connected via remote input/output (I/O) and antiquated data highway communication protocol to the rest of the plant. The old processor and system was to be replaced with a Rockwell Automation ControlLogix processor and Ethernet-based I/O. The project included the software conversion, update to existing (and very tattered) electrical design documentation. The goal of the project was to replace all hardware (the existing processor was so full that it no longer could be edited), test new I/O and ensure existing functionality before a startup, without a ramp up curve. (Full production was required at the “go live” point, Tuesday, 6 a.m.)

Based on the hardware and lack of human-machine interface (HMI) screens, this type of project could not be completely simulated for total testing before go live. To reduce risk to the startup, the project team took special care in code conversion and with cross checking code and drawing reviews for quality throughout the project.

Q: What types of automation, controls, or instrumentation were involved? 

A: The vast majority of the controls (A-B PLC5 to CLX) converted were discrete inputs and outputs for photo eyes and conveyors as well as line speed references and additional communications over message instruction routines to upstream and downstream processors.

Q: What were particular challenges outlined in the project?

A: The main challenge with this project was the small startup window (a three-day holiday weekend) and the small margin for error after production began. Based on the execution process and quality control procedures, the project finished earlier than expected, which left a buffer day for additional testing time.

Q: How were those issues resolved?

A: The issue was resolved and mitigated with a strong quality plan for the execution, a rigid checkout schedule and detailed site-acceptance test (SAT) checkout list.

Q: Can you share some positive project metrics?

A: Downtime window was the three-day Labor Day weekend. The electrical contractor team began wiring Saturday morning at 12:01 a.m. and finished Sunday at 5 a.m. On Sunday, the controls team completed a I/O check out and then moved into functional testing. Testing of the code went smoothly (due to quality control efforts), and the team finished up after a long day. As a result, Monday was left as a buffer for more testing and the chance for the team to take some rest.

The system was commissioned within the startup ramp (0 to 60 mph in 2 seconds) with only 20 minutes of total downtime associated with the project.

Q: What were the resulting lessons learned or advice you’d like to share?

A: The biggest lesson learned (and this is typical for obsolescence projects especially in packaging areas where timing is everything) is to closely watch the sequence timing. The new processor and communication protocols typically will run considerably faster than the older processing speeds. The small downtime that was experienced was a result of timing out of phase from prior logic cycle times. This logic was rewritten to address the faster processor. We spent additional time focusing on the areas where timing was important. As the line was run at full speed we tweaked the timers and scans accordingly.

Robert Herman is program manager – senior engineer, Avanceon, a CFE Media content partner. Edited by Mark T. Hoske, content manager, Control Engineering, CFE Media, mhoske@cfemedia.com.

KEYWORDS: Packaging automation, case study, code quality

Seven bakery lines fill 20 cases per minute.

Packaging automation controllers, code and networks needed upgrading in three days.

Testing happened during and after development; simulation wasn’t an option.

CONSIDER THIS

Does your next machine or line redesign consider next-generation automation?

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.