Balls R Us
Building a marble distributor with a PLC and pringle cans
Each year Stellenbosch University holds a competition between its Mechatronics students to build some sort of particle-board and glue-gun contraption to be powered by a Siemens S7-1200 PLC and some supplied Pololu electronics. The contrast between the beautiful hardware and the apocalyptic mechanisms are comical, and ours was the ugliest of the lot. But it won.
Our first idea was well thought out, we were doing to lazercut all our parts, have a nice little hopper, gravity feed it into a picking wheel so we can count out the marbles by rotations of the wheel and the only difficult part would be setting up the PLC and tuning the feedback and PID controller.
Marbles get stuck. Their friction coefficient is so high that they form interlocking meshes and block the exit to any container you try and come up with.
Marbles jam. They jam everywhere, against anything. They are temperamental and vindictive and will never go down a chute or tube or anything where they are the least bit forced.
Marbles encourage other components to join their jamming revolution and will make everything rebel against you.
Ultimately this leaves you with two options. Agitate and beat the hell out of them so they budge, or you need to herd them unsuspectedly like the cattle in Temple Grandin.
Option A, brute force Option B, coax
Some of the requirements:
The size of the distribution system is limited to 0.425m wide and 0.85m long.
The hopper should be able contain 200 marbles that are stationary until the system operation is started.
The inlet of the hopper should be at least 0.1m (diameter or squared).
The hopper outlet should be at least 0.05m lower than the container inlet.
The containers should be removable.
The containers inlet, either channel to the inlet, must be 0.02m or less (diameter or squared).
Functionality and Control:
The system must distribute marbles to three separate containers in specified amounts with a specified number of passes.
At least one of the actuators should implement PID control.
The system should have a software interface.
The software interface should be able to specify the distribution of the material.
The software should be able to specify the number of passes.
The software should provide visual feedback of the process.
The control of the system needs to be done with the PLC’s provided.
Boring stuff is in grey boxes, you can skip that
When we started assembling and testing parts of it, we soon discovered some major issues.
What followed was us continually face-planting into the mud every time we thought we made a bit of progress.
Here are some of the unforeseen problems we faced:
Chute control implementation:
The chute was driven to three hard coded angles by a geared down motor with an encoder attached to the motor shaft. The encoder works on a quadrature A and B channel pulse which can be read on the rising and falling edges of the signals to increment or decrement position. The pulses that the encoder sends may be of a very high frequency (tens of kHz). Therefore, the high-speed counters (HSC) on the PLC is needed to count the pulses
The resolution of the encoder is determined by the amount of lines on the encoder disk, and will give the ratio of pulses to degrees. Therefore, the total encoder pulses per revolution needed to be determined first. The HSC can be set to operate on single rising edge detection or rising and falling of both signals to give four times the resolution. The encoder was set to quad counting mode and then set to zero. The shaft of the motor was turned a full revolution and it was determined that there were 900 pulses per revolution resulting in (360/900) degrees per pulse.
This feedback information had to be intelligently used to position the chute accurately and quickly between balls exiting the chute to ensure none were misplaced. A rise time of 0.3sec was required. Using the compact PID block, it was easier to work with angles than the raw encoder pulses so several conversion blocks were implemented to store the encoder data as degrees which were set as the input of the PID compact block (not in percentage mode). This enables degrees to be used as the set-point input which makes debugging much simpler.
To control the motor, a PWM output was required and since relays switch too slowly, one of the direct MOSFET channels was used as the output. The PWM clock has a fixed hardware output of Q0.2 but the memory address that would store the pulse data for its output was changed from 1000 to 1003 since 1000 was already occupied by another function. The PWM block required an input of 0 to 32000 which meant that the percentage-wise output of the PID block was scaled before being written to that address.
Once the encoder to PID block communication was established and tested, the PWM output on the PLC was tested with the motor driver and also used to determine the minimum value required to move the motor (which was added to the output to ensure no unnecessary integral build-up occurred). Then the initial tuning and testing could begin. Initially a very low K value was set, and the integral (I) and derivative (D) terms were disabled. The proportional (K) value was slowly raised to check the response of the system and to determine whether the motor leads were correctly connected. The integral control was tested by disconnecting the motor leads and turning the shaft so that there was a constant error offset which would cause the I term to increase and therefore increase the output of the PID block. To make tuning easier, the K I and D values were adjustable from the InTouch program.
The final tuned system was given a step input of 30 ̊ and using the PID block tuning window was captured and is shown in Appendix C. The PID compact block enabled angle limits to be set, which controlled the process and kept it within safe operating conditions, reducing risk to the machine or setup. This proved useful when experimenting with damping, integral control, and initial automation of the system.
A limit switch was placed to trigger when the chute reached its first position. This was done to ensure minimal drift occurring and that the system has a zero-home position from start-up. The three positions to stop at can be read off the position given by the encoder and set on the interface before running.
The user interface can be seen on the left. It allows the user to specify the distribution of the marbles into the three containers as well as a pass count. Since not all distributions can be evenly divided up into the number of passes specified, the program works out a RES value to add to the last pass to make up the total.
For example, if a container needs 32 balls in a pass count of 3, each pass will get 10 marbles but the last one will be 12 to make the total 32.
The right hand side is a real time feed of the sorting status, the top container is shown emptying into the bottom three with the currently active path being highlighted.
The bottom panel are settings for the sorting chute such as the gain values for the PID loop and the set angles for each container
Balls R Us in action