Tubestacker

As an employee at Barth Industrial Automation, I had a leading role in developing the software for the so-called "Tubestacker." This machine was developed for a customer who wanted to move the production of beams for fencing in-house. The machine is at the end of the line and stacks the product into crates or bundles.

Challenges

The mechanical challenges were the great variety of product sizes and types, and the speed at which products needed to be handled. This required some creative solutions using some positioning axes and a novel end-stop solution

To reduce cost, instead of special servo axes we used regular drives with encoders for position feedback. For fast commissioning, we used Siemens servo control objects for positioning and wrote our own communication layer to use the regular drives.

For the end-stop, we used a special Festo Smart valve and piston and combined it with a position sensor. We then wrote our own control loop for controlling the position of the piston. After a beam enters the machine at great speed the end-stop will catch and gracefully stop the beam at the position required. Using this solution we were able to handle the great variety weights.

Software

Our software is running on a Siemens S7-1500 line CPU and we used an in-house developed template based on the ISA-TR88.00.02 standard. ISA-TR88.00.02 is also more commonly known as "PackML".

State machine

In this model, we divided the machine up into equipment modules that all share the same state. The machine enters transition states by triggered events (Abort, Clear, Start, etc.). Once inside a transition state (green) each equipment module will try to complete its transition and will signal "State Complete" or "SC" when done.  Once all equipment modules signal "State Complete", the entire machine transitions to the next state. Some event types, such as abort, take precedence over other events or transition states.

Equipment Modules

Each equipment module or "EM" can be broken up into the following list of components:

• Routines
• Actuators
• Events

For most EM's it's nonsensical to define behavior for every state. That's why we combined similar states into routines. When a certain state is active the matching routine will get called so divergent EM's can call specific routines for their specific case. But as a whole most EM's are simplified to

• Startup
• Execute
• Terminate

For more complicated EM's, which require different algorithms depending on the leaving state and the entering state, a single routine was used. In this routine a Step program was employed which would enter the next step based on the current inputs. This is similar to how "Sequential Flow Chart" works.

After the output from the routines is resolved, we need to output requests to the actuators. These get handled by the Actuator function blocks. The actuators are within PackML terminology also known as "Control modules". These will send requests over the network or trigger physical outputs. Also, they will gather feedback from the network devices. At Barth Industrial Automation we aim to have standardized interfaces for the same type of device from different manufacturers. That way a project is less reliant on one manufacturer, but also development can be sped up when using recurring manufacturers

Lastly, after gathering all inputs and feedback, events are triggered. Events are always global in nature and therefore have an effect on the entire machine. Most events can be classified as:

• Signals
• Warnings
• Error

Most events have an accompanying alarm that is shown on the device screen inside the alarm manager. After an event is triggered the accompanying action is queued for processing. The underlying framework of the used template will at a later moment empty the queue and resolve required actions based on current state and priority.

Do you want to learn more about this project? Or about other projects Barth Industrial solutions makes. Read on or contact one of my colleagues at https://barthindustrialsolutions.nl/#markten