[enkrs]

I have given talks to factory managers about finding that one or two employees that know Arduino/Raspberry for these projects. Every factory has such persons. They would love to do it!

The reception on this is mostly neutral or negative from management. When you identify these guys, turns out they have great hardware or programming skills, but no integration or architecture concepts. The existing system (ERP, MES) owners also like to put a lot of red-tape around anything unconventional connecting to their systems.

Managers also are held accountable for the project, even if the costs are low. They prefer to spend a lot and have a consultancy to blame on failure, then their internal employee project they selected.

What consultants do is they help the company navigate within it's own bureaucracy and processes. Even to implement the Raspberry solution.

[crispyambulance]

I work in this area and know the mindset of ERP and MES folks. It's great for long-term volume production of stuff that's very well established, but makes innovation really, really intractable.

That said, lots of people focus on how inexpensive things like the rpi are, but whether the unit costs $35 or $3500 makes a very small difference in the overall cost of the project. I am not totally against rpi's for factory stuff, as long as the folks who implement using those can slow their roll and think some more about the lifetime of their automation project and it's future maintenance.

There are PLC's that can run FOR DECADES without problems in a factory environment. Will an arduino/rpi be able to do that? Will someone 15 years from now know even know what an rpi is or be able to buy one?

[johnwalkr]

I see so much stuff reinvented using raspberry pi, arduino and sparkfun sensors simply because people have exposure to those and don't know what a PLC is. And PLCs don't even have to be expensive, a $200 one from automation direct would often be enough.

[sulcate]

PLCs are often a pain to integrate with multiple systems and are not nearly as versatile and simple as an internet connected pi running python, for certain desired tasks.

Please tell me which PLC you can get for $200 that runs python, can query some REST APIs, query and write to some databases, communicate with several other types of PLC and equipment, check a half dozen types of local sensors, and perform complex operations without purchasing a software subscription or having to be programmed in ladder logic.

Obviously they are suitable to different tasks, but there's a reason someone might reach for a PI to integrate new functionality, including on top of an existing PLC. They're tremendously handy in this environment, not just used because people don't know better.

[johnwalkr]

I mostly agree with you and perhaps this was the wrong article to put my comment on because I think in this case they did well with raspberry pi.

> without purchasing a software subscription or having to be programmed in ladder logic

I am thinking of cases where a small PLC, some industrial sensors and ladder logic is a good, reliable and easy solution, but someone reaches for a raspberry pi and python scripts because that's what they've been exposed to.

I agree adding something on top of an existing PLC can be great too. In my first job nearly 20 years ago, I did machine automation and we always added an industrial mini ITX PC to our PLC panels. This cheaply added datalogging (an advertised feature for the customer) and remote programming capability (usually an unadvertised feature that made us look really impressive when we could fix something immediately without going to the very remote site). Depending on what was available on site, we could connect remotely by the site's internet, by a modem/landline, or by a cellular radio (configured as a modem, as this predated reasonable prices for data plans). Sometimes the PLCs were from the 80s and none of the competitors would quote anything except tearing everything out and starting over, but would could find a way to add to the old system.

Connecting remotely by some official upgrade from the PLC manufacturer was usually technically possible, but impossible in practice to get authorization to gain access to the network, and get things configured to allow access to the PLC from offsite. But dialing up to our own installed modem bypassed all of that, and since a PC is versatile, there was always some way to bridge the PLC's programming interface to the PC.

I recall that we had to go out of our way to find PCs that didn't look like PCs and were DIN-rail mounted. Anything that looked like a PC would eventually get messed with by someone.

[babas]

WAGO pfc controllers series can do everything you mention. They are "just" Linux boxes with a fully featured integrated I/O bus (with any input/output type you can imagine). They can be programmed in pretty much any language and you can deploy with docker.

That said. Really large factories use DCS. (Distributed Control System) they are horribly expensive but integrates everything in one system. Controller programming, Human machine interfaces, MES and even ERP. Best known to me is ABB 800xA and Siemens PCS7.

[pbalau]

I think is a bit nuanced than that and there is a clear reason why a manager might go for a contractor instead of in house.

A good manager will have a clear understanding of his slice of the company, what work needs done, what are the hoops, what problems can arise, how the work needs done. Same manager most likely has no understanding what it means to build, deploy and maintain a hardware + software thing. And since we are talking about a good manager, they are aware of that. Hence they call for a contractor that will build, deploy and maintain said thing.

And lets face it, will these tinkering workers actually able to deliver a robust system? You already mentioned the lack of integration or architecture concepts. The red tape might be there to prevent data corruption. What user interface are they going to use? Fragile touchscreen or a big button to mark the end of the step (eg, after the worker finished mounting the mud guards). Will that button/touch screen survive the number of mud guards that need to be mounted every year? Or that prosaic issue: where do you store the spares? etc etc There is a reason why this kind of innovation, like automatic testing, deploying etc, happen in software companies, building, deploying and maintaining software is the core competency.

I don't doubt there are happy cases where the tinkerer is more than a tinkerer, the video we are commenting on proves that.

On the other hand, this sort of thing should be encouraged. Have the workers come up with POCs, then pass that to the expert contractor to help with the extra bits. When the startup I work for decided to pivot, I suggested to build a framework to help with automation: have a server that boots remote thin clients and have a basic client that you can plop all kinds of peripherals in. I had to use cases in mind: automation for small factories and bar/restaurant management. We decided to count trees instead.