5 ms·

On an instrustial machine I worked on we got around this by hosting a node.js website on a Linux touch screen panel. There was a redis cache which was updated b

On an instrustial machine I worked on we got around this by hosting a node.js website on a Linux touch screen panel. There was a redis cache which was updated by a small python script that communicated with the embedded stuff via a serial interface. If you have the budget for it, this is a great architecture since creating a website GUI is much easier than an embedded GUI. Also, you could very easily pull up the machine control panel remotely from any web browser (with proper remote vs local security enabled of course).

LeifCarrotson 5y ago
Similar things happen on every industrial machine. Typically, it's a VxWorks-based PLC (implementation detail, never ever exposed to the end user) and a Windows CE touchscreen HMI. It is remarkable, though, how much this separation makes sense. You end up with some ancient 68000 or PowerPC processor running all the performance-critical logic with - if you're lucky - a megabyte of SRAM. It's expected to hit one millisecond scan times every single millisecond for ten years straight. And it does so, until you miss your SRAM battery maintenance interval or drive a forklift through the panel; it will probably keep running through any lesser hiccup. The PLC communicates over that serial interface (or an Ethernet socket which emulates a serial interface) with the HMI, which probably has a multicore x86 CPU and literally a thousand times more memory. It runs a pared-down desktop operating system. It's not made to hit one-millisecond scan times, it probably has visible lag while merely changing the background color of an indicator. Good luck creating a usable GUI with the IDE, which might be decades old. An Arm Cortex microcontroller for the embedded system, and a Linux touchscreen displaying a NodeJS website would be a convergent way to develop such a machine if you didn't have 50 years of legacy code and trundling along behind you....
- HeyLaughingBoy 5y ago
  That last sentence is what we're mostly standardizing on, except for using QT. I've pushed for web interfaces but it's weird how even embedded developers with broad backgrounds get when you bring it up. I think there's a psychological barrier some people have to using webpages on an embedded system.
  - liketochill 5y ago
    It’s because the web is a moving target and embedded systems are static. What’s your reaction when you see a web browser or web page that is 10 years old? 20? The timeframes of industrial machines is incompatible with web anything.
    - HeyLaughingBoy 5y ago
      You need to make a separation in your mind between "the web" and "web technologies." I said nothing about putting the device online.
      - zinekeller 5y ago
        > You need to make a separation in your mind between "the web" and "web technologies." I said nothing about putting the device online. I wish so, but Google kind-of wrecks that proposition, introducing new stuff to the point that some developers might (unknowingly) use something that is not available on the embedded browser.
        HeyLaughingBoy 5y ago
        That's kind of impossible when the server and the browser are on the same machine :-) Bear in mind that what I'm talking about here is making UI's for embedded systems easier to design by using web technologies. That means that we're only leveraging web tech for local use: there is no connectivity farther than (maybe) to another device on the same circuit board. Something like BoneScript (javascript for the BeagleBone) takes this step farther by building I/O extensions into the language so your system controller and webserver can be the same process.
IshKebab 5y ago
If you can install Linux on your device you won't have any of the problems he is talking about. He's talking about microcontroller GUIs. Honestly running a node.js website with a Redis cache and a Python script for an embedded GUI sounds like a completely insane and fragile mess! Qt or Flutter are clearly the best options for embedded touchscreen devices where you can run Linux.
- roland35 5y ago
  My point was at a hardware cost it may save you software development cost by adding a Linux machine to an otherwise embedded platform

LeifCarrotson 5y ago

Similar things happen on every industrial machine. Typically, it's a VxWorks-based PLC (implementation detail, never ever exposed to the end user) and a Windows CE touchscreen HMI. It is remarkable, though, how much this separation makes sense. You end up with some ancient 68000 or PowerPC processor running all the performance-critical logic with - if you're lucky - a megabyte of SRAM. It's expected to hit one millisecond scan times every single millisecond for ten years straight. And it does so, until you miss your SRAM battery maintenance interval or drive a forklift through the panel; it will probably keep running through any lesser hiccup. The PLC communicates over that serial interface (or an Ethernet socket which emulates a serial interface) with the HMI, which probably has a multicore x86 CPU and literally a thousand times more memory. It runs a pared-down desktop operating system. It's not made to hit one-millisecond scan times, it probably has visible lag while merely changing the background color of an indicator. Good luck creating a usable GUI with the IDE, which might be decades old. An Arm Cortex microcontroller for the embedded system, and a Linux touchscreen displaying a NodeJS website would be a convergent way to develop such a machine if you didn't have 50 years of legacy code and trundling along behind you....

HeyLaughingBoy 5y ago
That last sentence is what we're mostly standardizing on, except for using QT. I've pushed for web interfaces but it's weird how even embedded developers with broad backgrounds get when you bring it up. I think there's a psychological barrier some people have to using webpages on an embedded system.
- liketochill 5y ago
  It’s because the web is a moving target and embedded systems are static. What’s your reaction when you see a web browser or web page that is 10 years old? 20? The timeframes of industrial machines is incompatible with web anything.
  - HeyLaughingBoy 5y ago
    You need to make a separation in your mind between "the web" and "web technologies." I said nothing about putting the device online.
    - zinekeller 5y ago
      > You need to make a separation in your mind between "the web" and "web technologies." I said nothing about putting the device online. I wish so, but Google kind-of wrecks that proposition, introducing new stuff to the point that some developers might (unknowingly) use something that is not available on the embedded browser.
      - HeyLaughingBoy 5y ago
        That's kind of impossible when the server and the browser are on the same machine :-) Bear in mind that what I'm talking about here is making UI's for embedded systems easier to design by using web technologies. That means that we're only leveraging web tech for local use: there is no connectivity farther than (maybe) to another device on the same circuit board. Something like BoneScript (javascript for the BeagleBone) takes this step farther by building I/O extensions into the language so your system controller and webserver can be the same process.

IshKebab 5y ago

If you can install Linux on your device you won't have any of the problems he is talking about. He's talking about microcontroller GUIs. Honestly running a node.js website with a Redis cache and a Python script for an embedded GUI sounds like a completely insane and fragile mess! Qt or Flutter are clearly the best options for embedded touchscreen devices where you can run Linux.

roland35 5y ago
My point was at a hardware cost it may save you software development cost by adding a Linux machine to an otherwise embedded platform