Put your robot in a good spot or suffer the consequences. It may seem obvious, but the best programming in the world may not be able to save a system where the robot has to struggle to get from point A to point B.
Palletizing
One of the first problems I had to solve as the newly appointed M-410iB product manager back in 2008 was where both an end-user and an integrator were blaming FANUC for overheat and throughput problems. “You claimed that this robot could do 28 bags per minute,” the integrator exclaimed. “We can barely do 20 without getting J2 overheats. We bought the fan kit and everything… this must be a faulty robot.”
Try coming up with a politically correct way of telling the integrator that they had mis-applied the robot during a heated conference call. Even companies that push 50 robots a year make mistakes.
One of the most crucial decisions to make on a palletizing system is the height of the robot relative to the incoming products and outgoing pallets. Generally, you should follow two rules:
- The pick height should be at roughly half your average unitload height.
- The robot should be placed as low as possible such that it can still build the tallest unitload.
The reasoning behind rule #1 should be pretty obvious. If the robot is building up a stack of products 10 feet high, it makes sense that it should pick each product at roughly 5’ above the pallet. This way it splits the effort in the Z direction between the bottom and top halves.
Rule #2 may be less obvious. Robots usually prefer to work in the upper part of their work envelopes. Try and put yourself in the robot’s shoes: would you rather move something from shelf to shelf at chest-level or do the same motion on the floor while bending over at your hips?
This project broke both of the rules. The infeed conveyor and the pallet were pretty much on the floor, and the robot was on the standard riser. It had to bend way over to pick up each product, and as the unitload got taller, J2 had to work harder and harder to move the robot vertically to place and then pick again. By simply lowering the robot and raising the infeed conveyor, the system started to make rate with no overheats, and the fan kit was no longer necessary.
FANUC’s Delta Robots
FANUC’s delta robots (like the M-3iA, M-2iA, etc.) are fantastic for high-speed picking applications. After years of pushing the M-430iA to the limit, these robots are like a breath of fresh air. However, they too can suffer if a couple considerations aren’t made with respect to their work envelopes.
These robots use ball and socket joints to connect each link-arm to the base. As with any ball and socket joint (like your shoulder), they can dislocate. When the robot is stretched out close to the extent of its work envelope, these dislocations are much more likely. While not catostrophic, reconnecting these link-arms is a pain, so it’s nice that FANUC attempts to avoid them with software.
The robots constantly monitor the likelihood of dislocating each axis. Depending on where the robot is, the payload, its vector, etc. the robot will stop itself if that likelihood ever crosses a threshold. Pressing RESUME is a lot easier than putting a link-arm back on, but any production-stopping errors are frustrating. Care should be taken to ensure the robot is not needlessly coming close to the edges of its envelope (both vertically and horizontally).
There’s actually a region where the robot automatically slows down to avoid these errors and dislocations. On the M-3iA, it’s a 500mm radius. As you can imagine, this can cause major issues with a line tracking system. Boundaries that work great at 100% don’t work so good when the robot suddenly moves 20% slower. If you can, try and limit the robot’s work area to the high-speed region. If you can’t, try and do something clever with your end-of-arm tool to effectively offset the work envelope.
Reach studies aren’t good enough
Many mechnical designers simply do a reach study in SolidWorks to validate a robot application. Unfortunately this simply isn’t enough for applications that near the edges of the robot’s capability. ROBOGUIDE does a great job of realistically simulating these robots. You can even estimate the overheat on each axis for a given cycle.
I figure each hour spent in ROBOGUIDE saves two on the floor, and when the consequences of a misplaced robot can cost you tens of thousands of dollars, it’s worth it to produce a comprehensive simulation before anything gets built.