Comment: Modern HMI is needed more than PLC

[TheColonel2688]

This is just a comment to start a conversation.

I think there is a much bigger need for a Modern HMI solution, that emphasizes reusabilitiy over multiple projects.

I haven't found any HMI software that has a concept of Product/Library scope, and a separate Machine scope.

Things like User Accounts, default settings, database connection strings, maybe extra screens, would me Machine scope, because they may be different on each machines.

There are things like screens, tags, scripts, that can me used across multiple projects/machines would be Product/Library scope. these are also things that you might want to update on existing machines, add you add features.

I would also like something that plays well with git.

I have never found anything like this. My company builds standard machines that night have some light customization sometimes and trying to keep things standardized and upgradable is a nightmare

[joyja]

I definitely agree with you that the HMI market is ripe for improvement via an open source project based on web technology. Not sure if I agree that it's generally more important than an open PLC platform like Tentacle PLC, but it's definitely at least as important. Interesting idea to have something that caters more to OEMs or mass deployment of similar projects with the ability to customize. I like it!

[TheColonel2688]

Other side of it is user adoption. I think an open source HMI is a lot less scary to the plant support engineers than a Open Source PLC runtime. Even I, an OEM engineer thst likes the latest and greatest would be very skeptical of any run time that is built on JavaScript.

a PLC has to be rocksolid and run for months if not years with out restart. An HMI is a lot more forgiving of hiccups since it is just a UI.

A soft PLC with the runtime core written in C++, rust, or Go sure, and Maybe C#. Javascript or Python nope nope nope.

[joyja]

I've heard this argument before. It relies on an assumption that I have yet to see substantiated. The assumption being: "Node.js (and I'll throw Python in there, since you mentioned it) is less reliable than proprietary PLC hardware platforms." My opinion is that it's a poor assumption.

• Anecdotally, working with it for the past 3 years, it's at least as reliable. I have nodejs processes that have been running for years at this point without intervention. Not on Tentacle PLC yet, but still speaks to reliability. I also personally just enjoy working in it more - - - which I think is important.
• Logically, node.js is currently being used to run critical web services used by millions of people, where if the service goes down the monetary damages meet or exceed the monetary damages resulting from interruption of typical industrial processes (excluding life/safety critical systems - - - I'm not a monster ). Also tooling like pm2 and container technology (docker, docker swarm, and kubernetes) give you extreme flexibilty in your failure/redundancy strategy with general purpose hardware. See my modern edge architecture blog post that discusses hyperconvergence at the edge (redundancy that's more reliable and lower cost than major proprietary PLC manufacturers).
• While I don't have a hard source for this, I don't think it's possible that there are less developer's eyes and users of nodejs than there are of all of the major PLC platforms combined. Just by shear numbers of users finding bugs, adding features, and relying on it I would trust the nodejs community over proprietary industrial manufacturers any day.
• Most of the reliability issues in process controls logic doesn't stem from the core platform anyway. It stems from poor implementation. This is more of a comment about how hard proprietary PLC manufacturers make it rather than the quality of systems integrators. The tooling surrounding PLC development is just far behind. The tooling around nodejs (and any modern programming language really) is far better at helping you write quality code: community-driven distributed package management, LINTing, automated unit testing, CI/CD, and on and on. PLC development has focused on creating abstractions (FBD, LAD, SFC, etc) that actually limit implementing these features and slow the iteration cycle down (my anecdotal experience).

I have a few more points, like how proprietary PLC manufacturers seem to "innovate" more around increasing vendor lock-in/license engineering than actual developer/user experience, and that you have easy access to parallel (async) logic in nodejs, but I think the above gives you a good idea of why I think this is a worthwhile project.

To your comment about C++, rust, or Go. I have thought that adding a Rust or Go backend might be a path to more determinism and higher performance if necessary in the future. My experience though, is that for most applications nodejs will do just fine - - - Tentacle PLC doesn't have to be applicable to every situation right off the bat.