Packaging automation standards: what's under the hood?

Standards reduce learning curve while encouraging innovation

There was a time when a packaging machinery operator interface or controls salesperson could explain their unique advantage in a 5-minute ‘elevator speech.’ No longer. With the widespread adoption of international standards the control systems used to automate machinery are looking more and more alike.

On the one hand that’s a good thing because it reduces everyone’s learning curve -- especially since there’s so much technology to learn these days. But neither users nor suppliers will benefit from commoditizing machinery or control innovations.

Standards developers understand this too. That’s why they make provisions to encourage innovation while maintaining a beneficial degree of uniformity.

All this freedom of choice puts a slightly different burden on the buyers of systems. A proliferation of look-alike control systems doesn’t mean they all perform alike. Only now it’s harder to recognize the better solution without looking under the hood.

Borrowing proven standards from IT…

The new drive for standards has had an unanticipated benefit. The desire to avoid reinventing the wheel has opened our eyes to standards developed for other applications that fit the needs of manufacturing and packaging perfectly.

For example you wouldn’t want to buy a controller without CompactFlash Ethernet USB and DVI ports and onboard Web server. All are mainstream IT standards.

…and adapting others

Similarly industrial standards-bearers are using other mainstream IT architectures as the foundations for industry-specific adaptations. These include OPC and XML schema for getting data out of machines.

The Pentium class processor is also hands-down the processor of choice for industrial automation controllers. It leverages the enormous R&D spending necessary to make advanced processors. These represent economies of scale far beyond the largest selling processors used for niche applications. That’s why proprietary PLC and motion controller processors are always behind the performance curve.

Looking under the hood

It’s easy enough to recognize an Ethernet port when you see one. But certainly you do not need to learn every component on the circuit boards. You really should however request some time with a control supplier’s ‘technology evangelist’ who can translate technology features into practical advantages.

So before this discussion heads too far into technospeak let’s back off and look at what a maintenance technician or programmer sees when he/she opens up a packaging machine.

If the control supplier has standardized on IEC 61131-3 conforming programming the tech should see similar screens from machine to machine. That's on purpose.

(IEC 61131-3 is the international programming language standard. It should be listed as a requirement in your specification for PLC and servo control. For specification language click here.)

Indeed all IEC programmers have the same constructs available if the control vendor chooses to support them – such as Function Blocks Ladder Diagram symbols Sequential Function Charts. This is the highly prized common look and feel.

What’s inside that Function Block?

But look inside the Function Block that performs the electronic cam and you may discover a powerful 5th degree polynomial equation – or you may not.

Outside on the machine the difference will be apparent because unstable bottles are being filled at faster rates than ever before on the machine with the better cam function.

It’s fascinating to see how many segments a software cam can be divided into to increase cycle rates. There may be a gentle ramp up followed by a fast acceleration short decel period and minimal dwell time as the servo-controlled filling piston works its own magic.

And it all happens inside the Function Block. It’s all transparent to the operator and even the machine programmer because a format or material change is simply entered as new parameters in a recipe.

It’s all in how you put the building blocks together

A knowledgeable programmer might appreciate how the application was cleverly nested to orchestrate multiple groups of master and slave servo axes. Perhaps a servo axis is a master to some servos and a slave to others.

Back in the real world this equates to a machine with 50 servos spinning in unison making and packaging cushioned blister bandages dosed with a soothing ointment now – but scheduled to be making a surgical dressing in an hour’s time.

Why the ‘elevator speech’ won’t cut it

In other words huge differences in bottom-line performance are owed to some very esoteric things. Such as a gigabit-fast Pentium borrowed from a laptop. A mathematical equation buried deep in software. Or a juggling act between dozens of precision motors the brilliance of which doesn’t need to be understood by those who use or maintain the machine.

This is why the ‘elevator speech’ doesn’t cut it any more. If a vendor says they’re using IEC languages it doesn’t mean they support the most important ones. Even if they do that doesn’t mean they have a pre-tested high-performance software library to go along with it.

The good news for end users is all you need to know is how well the machine works and that the control system conforms to international standards such as those defined in the OMAC Packaging Guidelines.

For machine builders it means there’s no substitute for due diligence when selecting the best automation supplier. Learning what’s under the hood of standards-conforming control systems puts you back in charge of your own destiny.