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

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