I wanted to share a discussion which evolved within the interview I had with Jens Fetzer from CENIT during Automatica show. It somehow didn’t fit into the final articel/video. But as I believe it is worth sharing, I decided to make a separate posting out of it.
I believe that I already mentioned that I grew up in the workshop of my grandfather. So during school holidays I would work there in order to earn some extra money and I would saw the raw parts from the rods, load them into a CNC machine my grandfather built by himself, deburr them (after each “operation”) and so on.
It’s always about process parameters
During that time I also learned to operate manual milling machines and lathes. Manual. I have to stress that word. It means you operated the axes one by one. No CNC. Muscle strength. Direct force feedback. This way you develop a feeling for cutting depths, feed rates different materials and so on.
The machines I worked with were equipped with glass scales, and the current position of each axis was displayed. So you had to know where to stop or you produced scrap. When I think back I have to say that was really a ZEN like activity…
There was also the possibility to push a lever and the according axis started to travel on it’s own – after you dialed in the feed rate, of course.
From manual craftsmanship to CNC driven repeatability
When I worked on CNC machines, the process was still quite similar – now you had to program the cutting depths and feed rates per axis in G-code.
You can imagine it took an experienced if not skilled worker to operate such machines. You needed to have that feeling. The tables in the books gave you a start. Later you would use tables with parameters from the suppliers of the cutting inserts.
Workshop programming: controls assisting (un)skilled workers
So the target of that time was to support the man in front of the machine so that he could program faster and eventually get support for appropriate feed rates and cutting depths from the control directly.
This way of programming was called “workshop programming” vs. the place where full-time programmers did there job, which was already mainly the office at that time.
The main focus was to develop a control system which was “easy to program”. Do you already see the analogy?
Lack of skilled workers – not a phenomenon which developed over night
While there was one controls supplier who developed and refined that approach of an easy-to-program control over decades, others tried to rush it back in the 90s when it already became more and more difficult to get experienced and skilled staff for your workshop (or when you didn’t want to pay the price for them anymore).
When complexity kills simplicity
And then – between 2005 and 2010/2015 something happened which basically made this “easy to use” approach more or less obsolete: it was the rise of the 5-axis machine tools.
Why? As there are not so many skilled programmers who can think and program simultaneous 5-axis movements in G-code directly, you could have thought that this development must have pushed the workshop-programming.
There were several challenges, however. With two additional axes, these machines were already significantly higher in price. So you needed to find ways to use them more efficiently. Hence you didn’t want your machines standing when they were programmed (this was also mentioned from Jens when he talked about interrupting your money-making process, by the way).
Another factor was complexity. You were mainly limited to work with cylindrical or prismatic raw parts and typically not with the real CAD data. Thus, your options were limited.
Why you need to have an efficient way of teaching your cobots
This is what I mean when I talk about moving cubes from one side of the table to the other. Piece of cake with easy to program robot systems – as shown on TV (or in YouTube). However, if it gets more complex I need to ask you: do you really want to teach your application?
In the beginning of the 2000s, computer power became so strong that CAD/CAM software became approachable and affordable. Today there are even reasonable open-source projects out there if you have no money, but time. No one is programming 5-axis applications by hand anymore (maybe besides Jürgen, whom I was working with back then during my time at Heller who kind of naturally seems to think in 5 axis). It would be simply too complicated and time consuming.
Simulate it offline to decrease your down time
I know it sounds a little bit agains all ideas about how a robot should be operated, but think about it. You have a lack of (robot) programmers, but at the same time a lack of process specialists and you might want to use your robot or cobot for path applications as glueing.
While I believe in usability and while I am 100 % sure that the easy-to-use focus is important for the development of every new HMI, I am also not so sure that you want to program your complex applications directly at the robot while it is standing.
So if you ask me what a 5-axis machine tool and a robot should have in common, I’d say: both need to be easy-to-use for unskilled workers, but also both need to have a digital twin so that your processes can be programmed, commissioned and validated offline, so that ideally some unskilled person can choose the right program, press cycle start with 100 % velocity and you end up having parts with 100 % quality right from the first shot.
The message here: don’t concentrate too much on simplicity. Our (process) world is a complex one. Find digital ways to deal with it.