Share this article
Continue reading with these related posts
Every automation project looks cleaner in the proposal than it does on the shop floor. This is the honest version: the cobot cell we built for a digital print shop, what drove our design decisions, where reality diverged from the plan, and what we measured when it was all running.
Building an automated cell without a proper safety assessment is like building a house without a foundation inspection — everything looks fine until something goes wrong. This post walks you through ISO 12100, physical safeguards, safety PLCs, and lockout/tagout procedures to keep your team and your operation protected.
Not every robot is the right robot. Learn how collaborative robots and traditional industrial robots differ in safety requirements, flexibility, programming complexity, and total cost — so you can choose the technology that actually fits your operation.
In the previous post, we covered the safety systems that protect your team inside an automated cell. Now we turn to a question that comes up in almost every automation conversation: what do you actually need to be able to do yourselves?
A fully automated cell that only the original integrator can program and maintain is not really automation — it is dependency. Every time a product changes, a fixture needs adjusting, or a robot trips a fault you do not understand, you are on the phone waiting for a service visit that costs hundreds of dollars an hour and may take days to schedule. The most successful automation deployments we have seen are ones where the manufacturer builds genuine in-house capability from day one, even if they start small.
This does not mean you need to hire software engineers or train every operator to write PLC ladder logic. It means being honest about which skills you need in-house, which are reasonable to outsource on an ongoing basis, and how to develop your team's confidence with the new equipment over time.
The Goal: Confident Independence
The target is not for your team to replace the original integrator — it is for them to handle the 80% of day-to-day tasks (program tweaks, fault recovery, routine maintenance) without outside help, and to communicate clearly with vendors when expert support is genuinely needed.
Here is what running an automated cell day-to-day actually looks like. On a typical week, the cell runs reliably and your operators interact with it only to load parts and clear the occasional fault. But over time, reality intervenes: a product variant requires a new program, a gripper finger wears out and needs adjusting, a robot joint hits a position limit that was set too conservatively, a vision system starts rejecting parts that were previously accepted. None of these are catastrophic failures. All of them require someone on your team who can look at the system, diagnose what changed, and make a correction.
The gap between "we bought a robot" and "we can run a robot" is real, and it is the source of considerable frustration for manufacturers who underestimate it. We have seen cells that ran well for the first six months — during the support period — and then sat largely unused after the contract expired because nobody on staff felt confident modifying the program. We have also seen operations where a single motivated maintenance technician, given two weeks of focused training, became genuinely capable within a year.
The difference is rarely intelligence or aptitude. It is whether training was treated as an investment or an afterthought.
Do Not Rely Solely on Vendor Training at Commissioning
The training that happens during commissioning is almost never sufficient on its own. Operators are overwhelmed by new information, the cell is not yet in stable production, and the concepts covered do not fully sink in until they are needed weeks later. Plan for follow-up training three to six months after go-live.
Before you decide what training to pursue, take honest stock of where your team is today.
Automation for a typical manufacturing cell draws on four overlapping technical areas:
Robot programming: understanding the robot's coordinate systems, motion types, tool and payload configurations, and how to create, modify, and test programs using the teach pendant or offline programming software. This is the skill most people think of first, and it is learnable with focused effort.
PLC and I/O troubleshooting: the ability to read a ladder logic diagram or function block program, trace an I/O signal, and identify why a sequence is not advancing. You do not necessarily need someone who can write a PLC program from scratch, but you need someone who can read one and use the diagnostic tools to find where a signal is missing.
Mechanical maintenance: understanding how the robot and peripheral equipment are assembled, what wears, what requires lubrication, how to replace common wear parts (grippers, filters, cables), and how to check mechanical backlash and joint condition. This often maps well onto existing maintenance competencies in a shop that already does CNC or conveyor maintenance.
Electrical troubleshooting: the ability to safely measure voltages, trace wiring against a schematic, and identify failed sensors, contactors, or drive faults. This is a specialist skill and may not need to be developed broadly — one person with solid electrical fundamentals goes a long way.
Beyond individual skills, ask whether your organisation is set up to support ongoing automation competency:
If the answer to most of these is no, the technical training will be less effective — people revert to calling the vendor when the organisational scaffolding is not in place to support independent action.
For a typical cobot or industrial robot cell, here are the programming skills that will have the highest day-to-day value:
Waypoint teaching and editing: being able to jog the robot to a new position, record it as a waypoint, and verify that the new position is safe and correct. This is the most frequently needed skill — product changeovers and fixture adjustments almost always require touching waypoints.
Program flow basics: understanding how the robot's program sequences through moves, I/O waits, conditionals, and loops. Even without writing programs from scratch, a technician who can read the flow can identify where something is stuck and why.
I/O monitoring and forcing: using the controller's live I/O display to see the state of every input and output in real time. This single capability resolves a remarkable fraction of all faults — most integration issues are a missed signal, a sensor that is not triggering, or an output that did not command.
Fault log reading: understanding the robot's fault history, knowing what the common fault codes mean (joint over-speed, position deviation, communication timeout), and knowing which ones clear on reset versus which ones indicate a real hardware problem.
Offline backup and restore: knowing how to back up the robot's programs, tool data, and configuration to a USB drive or network location, and how to restore from a backup. This is a straightforward procedure that is disproportionately valuable when something goes wrong.
For cobots specifically — UR, FANUC CRX, Doosan, and similar collaborative robots — most manufacturers have invested heavily in making programming approachable. Universal Robots' Polyscope interface, for example, is genuinely learnable by someone with no prior robotics background in a few days of focused effort. Traditional industrial robots (FANUC, ABB, KUKA, Yaskawa) have steeper curves, but the fundamentals are similar.
Offline Programming Software Is Underused
Most robot OEMs offer offline programming and simulation software (FANUC ROBOGUIDE, ABB RobotStudio, UR Offline Simulator). These tools let your team practice program modifications in a virtual environment without stopping production or risking a collision. Encourage your people to use them for learning — the cost is typically included with a standard software licence.
There is no shortage of training options, but they are not all equally effective for your situation. Here is a practical map:
OEM training courses are the gold standard for depth. Most robot manufacturers offer two- to four-day operator and programmer courses, either at their training centres or at your facility. These courses cover the specific interface and programming language for your robot brand, which makes them immediately applicable. Budget $1,500–$3,000 per person, per course. The investment pays back quickly for anyone who will work with the cell regularly.
Integrator knowledge transfer during commissioning is valuable but not sufficient on its own. Negotiate specifically for structured training time — not just watching someone else work, but hands-on programming with the integrator present to answer questions. Ask for documentation of key procedures while the integrator's knowledge is still fresh.
Community college and technical school programmes are a good option for broader foundations — PLC programming, industrial electrical, and automation fundamentals. These are semester-length investments and make the most sense for a technician who will be your long-term automation support person, not for someone who needs to be useful next month.
Manufacturer online learning platforms have improved substantially. Universal Robots Academy, FANUC's online learning portal, and similar platforms offer free or low-cost self-paced courses. These work well for motivated learners who want to build familiarity before formal training, or for refreshing skills between courses.
Realistic timelines: a motivated operator or technician can reach the level of comfortable daily operation (fault recovery, basic program edits, tooling changes) in four to eight weeks of hands-on experience after a formal training course. Reaching genuine independence for more complex modifications — new product programs, vision system tuning, PLC sequence changes — typically takes six to twelve months of regular involvement.
Robots are reliable machines, but they are not maintenance-free. A neglected cell will eventually reward you with unexpected downtime at the worst possible moment. A preventive maintenance programme catches small problems before they become failures.
Start with the OEM's maintenance manual — every robot manufacturer publishes detailed service intervals and procedures. A typical programme for an industrial or collaborative robot cell includes:
Daily checks (operator level):
Monthly checks (maintenance technician level):
Annual checks (technician or service engineer):
Log Everything, Even Small Events
A simple maintenance log — a spreadsheet or even a notebook — that records every fault, every adjustment, and every part replacement will save you enormous time when diagnosing intermittent problems. Patterns that are invisible in real time become obvious when you can look back six months of entries.
Every automation vendor will offer some form of ongoing support contract. They range from basic telephone support to comprehensive agreements covering parts, on-site response, and remote monitoring. Here is how to think about them:
Keep a support contract when:
Consider going independent when:
A common middle path is to maintain a telephone support agreement (typically inexpensive) for access to technical expertise, handle all routine maintenance and programming in-house, and retain the option to call for on-site service on a time-and-materials basis for genuine hardware failures. This gives you most of the cost savings of independence while preserving a safety net.
Negotiate Support Terms at Purchase
The best time to negotiate support contract terms is before you sign the purchase order. Ask for extended support periods, training credits, and remote access support in addition to on-site response. Vendors are more flexible at the sale stage than after installation.
Across the automation projects we have been involved with, a few practices consistently separate operations that become genuinely capable from those that stay dependent:
Your Team Can Run This
With the right training, documentation, and organisational support, a motivated maintenance technician can become genuinely capable of programming, troubleshooting, and maintaining a robot cell. The path is not short, but it is well-defined — and the independence it creates is worth far more than the training investment.
We have now covered the in-house skills and maintenance practices that keep an automated cell running day after day. In the next post, Case Study: Our Digital Print Shop Cobot Cell, we bring everything from this series together in a real-world example — the cobot cell we designed and deployed for a digital print shop, from initial requirements through to measured results and the lessons we would carry into the next project.
