That seems.... slow? I mean, I have no idea what I expected, but 2 a minute, is that really fast for this type of manufacturing? How does that compare to Xbox or maybe iPhone output? I'm sure 2 a minute is really impressive, but I started reading that thinking something like hundreds or thousands an hour, I guess I was naive.
It's a pipeline. 30 seconds per build, but not 30 seconds between each console.
Just a few humans were present to deal with a handful of tasks -- two to feed bare motherboards to the line, and two to package the finished consoles.
The other article, kindly linked in one of the replies, states the following:
"In this area of 31.4 meters by 6 meters, it takes just 30 seconds for a team of 32 robots to build a PS4. "
But more fundamentally: factories often have more than one line.
525,600 minutes per year * 2 units/minute = 1,051,200 units per year (assuming 100% uptime)
There has to be at least a dozen manufacturing lines to meet yearly demand of over 10 million. https://www.statista.com/statistics/222403/unit-sales-of-son...
It's almost certainly 30 seconds part-to-part, taking 16 minutes (minus 30 seconds for each of the stations that have two or more robots) from the start to the end of the line. It's not particularly important how long it takes from the start to the end of the line, and they'd be unlikely to share that trivia with a journalist - but part-to-part cycle time is important.
If the TAKT time demanded a completed unit every second, they'd run multiple lines.
A sizeable 6-axis robot like those used here has a minimum cycle time of a second or two for the simplest possible "move in, place the thing, move out" operation. They're not ultralight delta or SCARA bots, they're about as fast as a human can control their arm. Also, there's a second or two lost while the pallets moves along and are parked at the multiple stations along the line, you want to design the system to maximize the ratio of useful on-station time to transition time.
The line is bottlenecked by the slowest process. You can make a slow station run in parallel - as in the photo at [1] with the 16 stations arrayed around the robot - but that adds a lot of complexity. I'd assume that their requirements were to accommodate up to ~8 minutes for burn-in testing at that station, and that by the empty stations, the software guys ended up only using 4 minutes. You can't make the whole line wait that long, so you spend the extra effort and introduce extra complexity by buffering parts there, but now your process has forked and needs to be merged again - really a pain for tracking suspect parts or tools. All that matters is that you unload each pallet before it needs to move on and replace it with a completed part.
Some stations may be doing nothing but running a 5 second electrical test. If there's some station that has to pick up a cable, photograph it, analyze it, contort it by rotating robot joints through large angles, plug it in, and get out of the way, that could easily take 10 seconds. Others may have a human who needs to keep up. Others might be heat-staking a plastic component and need time to blow on the stake until it cools enough to be unclamped. Others might have multi-headed tooling and can connect several different parts all at once. 30 seconds is a nice middling part-to-part value if you've got a few complex operations, a few human operations, and don't want heavy robots slinging your expensive parts around at high speed. I wouldn't have been surprised at a 10-second cycle time, but 30 seconds is still reasonable.
A final consideration is that you don't want an entire factory dependent on a single line. If you want to produce thousands of parts an hour, it's much, much better to have 10 identical lines that work at a 30-second cycle time than a single line frenetically thrashing to put out out parts in 3 seconds. If one line goes down, you still have 90% capacity, and can probably catch back up. If your single line goes down, you're in big trouble.
[1]: https://s3-ap-northeast-1.amazonaws.com/psh-ex-ftnikkei-3937...
I work in automation, but of biological processes (vaccines) and we have the same production issues with bottlenecks/capacity planning/down-time mitigation, etc.
Specialising your tools or machines comes at a cost: inflexibility, specifically changeover time between different products. If your machine can only do exactly one thing, the changeover time is "physically replace the machine", which may mean a delay of months.
Changeover time is a massive, hard-to-see drag on everything in a factory. The ideal manufacturing machine station can instantly switch its use between any two consecutive products moving along the line. Physically impossible, but ideal. Fully-programmable robots are much closer to that ideal than single-purpose machines.
That said, the tradeoff depends on the product/process spectrum. Some products are produced in "job shops", meaning an extremely flexible, high-touch environment, turning out very short runs. Others are worker-paced or machine-paced (which is what the Playstation factory would count as), mostly this is used for consumer goods. These still retain some flexibility, as much as sensibly possible.
At the far end are "continuous process" plants. These are very specialised to the product. Bottling plants, chemical plants, oil refineries and so on, where flexibility is not a highly meaningful advantage and the product lends itself to being treated as an undifferentiated flow as opposed to discrete units of product.
I recommend Matching Supply with Demand by Cachon & Terweisch as a first book to read. Then follow with the more in-depth Factory Physics by Hopp & Spearman.
I visited the BMW factory in Munich back in 2015; at the time it was manufacturing mostly the 3-series models (not sure now).
It was a generally fascinating experience; the most interesting piece of trivia was that, when scheduling the build order, they try very hard to avoid putting station wagons ('Touring' model) back-to-back.
This was because the build-time of the rear-window assembly on the station wagon took significantly longer than other models due to the rear wiper, and that you would get a literal pipeline stall if you had to do too many together.
Is your educational background in Mechanical Engineering or Electrical Engineering?
I’ve always found programming robots to be fascinating. And especially when building a robot to build other robots. I’m sure others will be interested in learning of this as well.
You can, however, learn the control systems by grabbing and reading the manuals. Look for manufacturers then seek out manuals. Many are online though they are often not the latest edition as some manufacturers now seek to keep this internal to paying customers.
All the systems I have seen use G-Code variants with manufacturer specific extensions. Many now offer GUIs to help with spatial planning, multi-machine integration, common code generation, etc. However, at the end of the day it is still nearly all about generating/writing/modifying/replaying stored G-Code.
One of the most important parts of my education learning that there is no black magic in technology. Everything we manufacture is a pyramid that builds complexity using leaky abstractions. At the lowest levels, you have atomic physics of doped silicon and charge carriers. At the highest levels of abstraction, you interact with those atoms by saying "Hey, Siri, do I need an umbrella today?" Someone, somewhere, either understands or wrote a tool that understands every layer between those two. We're a few decades out from the time when someone could think about the whole stack all at once.
If you want to really program robots, you need to understand a bit of the technology with which they're built (encoders and servomotors, control loops, motion planning, real-time operating systems) and then just pick up a teach pendant, and apply what you know. Do be aware of the value in abstractions, and don't try to reinvent the wheel, but if you don't know the fundamentals you'll be tripped up every time the abstraction leaks a little.
I didn't touch a PLC or robot until after college when the job required it. It's true that working effectively is all about familiarity the toolsets provided by various manufacturers, but I don't think that would be an effective thing to teach in a university setting. If you posted a listing for a recent graduate controls job requiring experience in your particular flavor of robots or PLCs, you're going to have a bad time - anyone with a CS/CE/EE/ME background could do it. Learn how to work, learn how to learn, learn how to plan, and by that time picking up a teach pendant and getting the robot to run a loop from point A to B and back to A will be the easy part.
But what the article is talking about is the throughput - one finished very 30 seconds - doesn't mention how long each takes to make start to finish.
A throughput of one every 30 seconds is only a million per year. They have sold 100 million PS4s.
Just because one little thing went wrong, you don’t stop the entire production line.
My guess is that they have 12+ parallel lines.
EDIT: another commenter points out that another version of the article does indeed say 30 seconds to complete one unit, as opposed to “one unit per 30 seconds”
How would that even be possible? Also what's are the start and end state here? Just pure assembly? Surely printing the PCBs can't possibly take a fraction of 30s. Neither can placing and SMD soldering the components.
> In this area of 31.4 meters by 6 meters, it takes just 30 seconds for a team of 32 robots to build a PS4.
So presumably there is more than one PS4 going through the pipeline at once for more than 1 per 30 seconds.
I'd think that 30 seconds would be how long 1 PlayStation takes to be assembled, but that there would be a new one every few seconds coming out of the line.