Journalist innumeracy.

It's a pipeline. 30 seconds per build, but not 30 seconds between each console.

There's no way they can build an entire one in just 30 seconds. It probably takes longer than that just to package them.

Well, the packaging is done by humans.

No, it isn't. The article specifically describes the robots packaging the final product.

It’s ambiguously worded (up to vs up to and including), but the article actually specifically describes humans packaging the final product: “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.“

from the article :

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.

I believe that number to be for just that length of factory line. The factory as a whole presumably has more production areas than just the one pictured.

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. "

It's not clear if the journalist understood throughput vs latency.

But more fundamentally: factories often have more than one line.

Surely there is a pipeline such that the 32 robots have 32 in flight at a time and don’t sit idle waiting for a single ps4 to complete.

That's kind of implied by the images. But if only two completed units come out the end every minute (regardless of how long it takes an individual unit to be assembled), that does seem a little underwhelming. There has to be more manufacturing lines than just this one to move millions of PS4s every year.

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...

32 robots on the line. If each is always doing its job on a unit(because it's a pipeline), and a unit gets all 32 pieces done in 30 seconds, then each robot is spending about a second on its unit. That means a completed unit every second.

I've programmed ABB, Epson, Denso, and Fanuc 6 axis robots (no Mitsubishis, but I've seen a few) and there's no way that those robots are running at 1-second cycle times. Maybe with a delta or SCARA, but just moving 200mm and back with the inertia of the robot alone will take you on the order of a second.

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.

Controls engineer here - no, that's pretty normal. I'm accustomed to automotive work, but I believe the electronics assembly lines are similar. The flexible materials handling stuff (connecting flat flex cables? Applying Kapton tape?) is indeed super impressive, but the timing is ordinary.

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...

>The line is bottlenecked by the slowest process.

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.

Can you, or someone else, share your experience in becoming a Controls Engineer?

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.

Most of the available training for this stuff is vendor-specific, vendor-provided and really expensive to undertake. Indeed, many vendors have solution provider networks who will prefer to do this programming for you, because it is so unintuitive/dangerous/error-prone.

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.

I double-majored in computer and electrical engineering. In those courses, I learned how to create PCBs and wrote code for FPGAs, microcontrollers, and a few desktop applications. As my sibling commenter mentioned, a ton of the actual implementation is vendor-specific and there's a mix of RTFM, on-the-job training, and vendor classes. Also, quite a bit of https://xkcd.com/627/.

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.

Thanks for your insight. Out of curiosity, why don't more of such production lines have dedicated machines that each do one small/simple action and then send it to the next one. It seems many seem to deploy general purpose robots that mimic human hand/arm features (that I would imagine have a higher latency cost in terms of controlling,positioning,etc). Is it so that you can manufacture multiple products with different assembly steps?

I work in automation, but of biological processes (vaccines) and we have the same production issues with bottlenecks/capacity planning/down-time mitigation, etc.

> Out of curiosity, why don't more of such production lines have dedicated machines that each do one small/simple action and then send it to the next one.

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.

The line can assemble a unit in 30 seconds and will presumably have more than one on it at a time.

What you're talking about is the latency - start to end for construction for each is 30 seconds.

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.

We are also assuming that the article is worded correctly. It could very well mean that the assembly time for 1 unit is 30 seconds total from start to finish, and the wording is just inaccurate. It happens a lot with articles like this, so who knows.

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”

>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.

I assume it’s final assembly

For that single factory line. Consumer electronics factories often have a lot of lines in parallel.

Yep, also minimum 2 lines to address SPOF (single point of failure).

Just because one little thing went wrong, you don’t stop the entire production line.

My guess is that they have 12+ parallel lines.

I have to agree, if this ran all day it'd produce 2880 consoles. How do they keep up with launch demand that sees millions of units shipped in a span of a month or two?

Indeed, the lifetime sales of the PS2 were 155 million, which would take 147 years to produce at this rate. But the "graphical version" of the article that it links to says instead 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.

So presumably there is more than one PS4 going through the pipeline at once for more than 1 per 30 seconds.

Yes it does seem slow, and being an assembly line I wonder if it's just poor communication in the news article.

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.