I have several hundred hours in setup and training behind Fanuc, Kuka, Motoman, ABB, and UR. With that said, there is, without a doubt, a push for automating processes and doing everything possible to get that done with the use of robotics.
This is due to several factors that have been very prevalent lately. Among these are difficulties due to hiring, employee retention, labor costs, and the need for more throughput or even quality demands on the existing throughput.
In this article, I want to focus on the hazards of incorrectly approaching an automation project that specifically includes robotics. If you have hundreds, thousands, or ten hours of experience with robots, some things still need to be considered on every project.
The scope of a project, details and other items need to be reviewed to help make the integration successful.
Robots have been around for decades doing the monotonous and dangerous…but now it’s time for something a little different. It’s time to look at the collaboration efforts, assistive components, and getting them to automate processes for reasons that they did in the past, and focus on what they can do next.
Processes and application assistance that reside outside the walls of that dangerous or monotonous box.
To start, you need to know what the common problems seen are so that you can work around them and even mitigate these before they happen to you.
From my reading and experience, the top three mistakes just lead back to the necessity of better planning and approach.
- Purchasing before the decision of how to use
- Purchasing before the breakdown of the target application
- Underestimating time for commissioning the final integration
I would also add the importance of getting the operator or technician that will be responsible for watching or maintaining the process involved from the very start.
They will have some great insight on the process as it currently is and ideas on the application that could lean the project toward successful completion.
Identify what has been referred to in some of my readings as the three Ds; Dirty, Dull, or Dangerous. This is also, like mentioned earlier, where you should open the window and look outside the box of “Ds” for other applications as well.
You will need to determine the goal to accomplish. I feel that three of the four on this list directly relate to the final part cost. Depending on your point of view, all four kind of do. If you don’t have quality, no one will want to buy your product.
- Quality à demand and returning customer loyalty
- Lower Product Cost à cost competitiveness (happy customers)
- Improve production à output and/or part cost (more customers)
- Decrease labor cost à part cost (competitive in the market)
The technical parameters of your chosen robotic application will need to be defined. One of the first might be the physical reach or work area that is needed to be covered. This will get you in the right ballpark to focus on a specific manufacturer or model offered by your company’s standard robotic vendor.
Another consideration that will narrow down what to look at is the payload capability or force ability. Some have significant variations. Some may be as little as 1 pound or as big as hundreds of kilograms. Check out one of the largest offered by robotics company ABB, IRB8700!
You will want to look at the number of axes that are necessary for your application. You may need six, two, or even a combination of multiple axes robots to get the job done. Repeatability and accuracy also need to be evaluated as to how important of a role it plays in the process.
Interfacing ability to other line controls, safety assessments, and possibly even the IP rating may be of particular importance to our application. Communicating to a local bridge PLC or other robots would be key to any integration.
On top of that, NEVER underestimate the importance of a safety assessment. This may restrict what robot you look at and has the chance to affect the footprint.
It is also important to look at the priorities of the goal you are trying to achieve. The scope of any project is important, but when an application such as a robotic one then starts to involve how much it will control, be controlled, or what collaboration will be needed with human operators, it is essential to have that defined.
You will need to know if the robot will work along with humans, closed off in a fence, how big of a footprint you will want to keep, and the overall project budget.
To wrap up the possible pitfalls, without expanding the scope of your current project, look at the possibilities of future capacity and even moving the robot to another location to help with a separate process.
If you plan and take into consideration the main pitfalls learned from the past and others, there is no reason that your robotic integration will not be a success and prove to have a speedy ROI and large cost savings in the coming years.
Written by Paul Hunt
Senior Automation Engineer and Freelance Writer
Have a question? Join our community of pros to take part in the discussion! You'll also find all of our automation courses at TheAutomationSchool.com.
Sponsor and Advertise: Get your product or service in front of our 75K followers while also supporting independent automation journalism by sponsoring or advertising with us! Learn more in our Media Guide here, or contact us using this form.
- Mitsubishi PLCs: Brief History and Hardware Overview - August 2, 2022
- Mitsubishi PLCs: FX5 vs iQ-R - February 10, 2022
- How To Register and Use a Device Profile in GX Works3 - November 9, 2021
Discover more from The Automation Blog
Subscribe to get the latest posts sent to your email.
