Hacker News new | ask | show | jobs
by SteveNuts 2966 days ago
Open hardware and software for PLCs for manufacturing.
4 comments

Along with this, we need a better way to program robots. I program Fanuc i200D and that whole industry makes my blood boil. Want more than 200 variables in your program? Shell out $10k.

High level programming language to program robots with safety in mind would be amazing. RoboDK is the only one that is doing this and they still suck.

If you have arrays why don't you implement a turing machine and compiler to turing machine so that you can have more variables without shelling out? Or some other model of computation.
Does the Fanuc need to be constantly reprogrammed? Or is it a rare occurrence?
I have worked in process and equipment R&D for ten plus years, off and on:

What I want is a PLC: 1) A PLC which has a hard real-time process and soft real-time processes. Beckhoff and B&R do this, other PLC's do this as well. 2) I want to do the hard real-time programming in Rust or Ada, or "Safe/restricted C"... Rust and Ada are so much more expressive than structured text. 3) I would also like to have a simple API to allow deterministic, hard real-time communication between the real-time control domain and a soft real-time domain so that higher level languages can be used for control problems. And I would like the PLC to support one of the high level languages: CLISP or Racket, F#, Julia, Python, Elixir... don't care what it is. This is actually doable on Beckhoff but the tight connection between hard and soft real-time was not really there.. and beckhoff runs windows. Would prefer Linux, VXworks, or QNX.

Integrating with 20 year old PLC's and robots is such a pain. Most people we work with have stacks upon stacks of abstraction to keep them safe and give them a sane wrapper for the functionality of the robots. So many labs have homebrew monstorous python scripts made by a grad student that left 2 years ago that everyone uses and no one can maintain.
The PLC/robotics/industrial automation space is often ten to twenty years behind in software best practices, with things like source control being completely alien to many vendors. Documentation can also be hard to come by, buried behind layers of paywalls and service agreements.

Of course, installations are usually expected to function for ten to twenty years at a minimum...an order of magnitude greater than anything your typical js-framework-of-the-day considers.

Even just allowing us to patch the servers would do wonders... a lot of this crap is running on 20 year old operating systems.
No one is saying to use the latest javascript framework for programming robots.