Industrial machine user interface Controller solution

[Simon]

I'm looking at what solutions are available for a machine user interface controller for machinery. Essentially a custom user interface using a screen and buttons. This will communicate with the machine ECU.

It's the sort of thing that feels like it should be the smallest single board computer that can hack it to drive a screen, something like 800 pixels wide will do.

I don't know if there is something off the shelf designed to do this sort of thing, if I am using a SBC it feels like I need to be prepared for supply chain issues and only use things that are standard enough to connect to standard hardware or use software that is not over specific for a particular board.

Is an android tablet an option?

[SiliconWizard]

To find an appropriate solution, more context would be needed. Like:
- How many of those controllers would you be building? Would they be one-time "prototypes" or manufactured in small, medium, large quantities?
- Who would be writing the software/firmware?
- Would there be a particular language required for this, should the development be accessible to a large audience or specialized embedded developers?
- How would the controller communicate with the machine ECU?
- What kind of display should it be? Any specific requirements apart resolution? (Like brightness, being sunlight-readable, having a specific interface - HDMI, LVDS, parallel, SPI, whatever) Should it have a touch panel?
- What maximum acceptable delay between power-on and the user interface usable?
- Any particular operating temperature requirements?
- Any minimum required lifetime for the device?
- Would it be connected to some network or only to the machine ECU?
- Would it have to be easily replaceable?

And probably more stuff that I'm missing.

[nctnico]

Budget?

That is a trick question. Cheap hardware is likely to need lots of development time where a ready to go (PLC) HMI costs a lot but takes a relatively small effort to develop. The biggest challenge for these kind of projects is to find the sweepspot between number of units to be sold, purchase costs, NRE costs and support/maintenance costs. Some make the mistake to only look at purchase costs and call it a day.

[Simon]

To find an appropriate solution, more context would be needed. Like:

And probably more stuff that I'm missing.

- How many of those controllers would you be building? Would they be one-time "prototypes" or manufactured in small, medium, large quantities?
Lets say 100 a year

- Who would be writing the software/firmware?
Me

- Would there be a particular language required for this, should the development be accessible to a large audience or specialized embedded developers?
As this is a new area I am looking into there are no specific requirements.

- How would the controller communicate with the machine ECU?
Serial port

- What kind of display should it be? Any specific requirements apart resolution? (Like brightness, being sunlight-readable, having a specific interface - HDMI, LVDS, parallel, SPI, whatever) Should it have a touch panel?
Well as i said I would rather use as standard stuff as possible, HDMI seems to the the minimum standard, I've seen the hassle of transferring a DSI display from a RPi to a Rock4, we lost dimming capability, screens could be from 400pixel to 1000, depends on the machine.

- What maximum acceptable delay between power-on and the user interface usable?
What a silly question , instantaneous of course! OK, less than 1 minute, there comes a point where you have to say, look, cheap and slow or fast and fooking expensive, you choose boss/customer

- Any particular operating temperature requirements?
Nothing that a consumer device can't handle, I don't do that military shit anymore

- Any minimum required lifetime for the device?
5 years, it will probably get bricked before then, these users and the sort that throw their machines around, if it can break it will at some point.

- Would it be connected to some network or only to the machine ECU?
Only the machine ECU, at some point it would be nice to do some clever industrial 4.0 stuff but I'm not going to make the unlikely impossible at the start.

- Would it have to be easily replaceable?
Yes, I mean this sort of thing can be build into a box that screws to the frame with a 4 pin plug.

[coromonadalix]

you call them HMI      Dwin is a good one, graphical interface designer free software

Stone    etc ...

a few of them mimic Dwin ...

[HackedFridgeMagnet]

I used an stm32 dev board with screen in a one off project. works great.
it is about $100 US on digikey.
https://www.st.com/en/evaluation-tools/stm32h750b-dk.html

I even used the CubeMx and GUI code generators, HAL, free rtos. say what you want but it worked fine in this instance.

it has a can bus interface and ethernet if that is what you need

but it has a fair bit of learning involved .
Im not really using the touch screen but only simple display it was fairly easy if u have stm experience.

[Simon]

you call them HMI      Dwin is a good one, graphical interface designer free software

Stone    etc ...

a few of them mimic Dwin ...

Yes a HMI, DWIN looks interesting. I may want to do slightly more complicated stuff later like log data and generate reports.

[SimonTVC]

We use https://blackswansystems.co.uk/ to design our HMI if you are thinking of outsourcing.

[bookaboo]

We do just this kind of thing for local OEMs, many people tried to roll their own and failed miserably.  The industry leader is IFM https://www.ifm.com/gb/en/category/250_030_010 , they have a good range of units to suit budget/machine, they are bullet proof reliable even in harsh conditions.

 Programming is done in Codesys, has it's quirks but fairly easy to learn. We had to write our own libs for ECU comms though, there are open source libs from Cat, Deutz etc but they are buggy as hell.

Do check the long term availability as they were caught in supply issues recently and are phasing out some of the lines (not the HMIs as far as I'm aware though).
Other solutions would be Danfoss, Deepsea, Hydec but cant vouch for them.

[JPortici]

I got in touch with some people with simillar (read SAME) needs, they use "Industrial Android Tablets" (which you can find on eastern markets) that have CAN, ethernet and all the doodah. They are app developers, i don't know if they use android studio or xamarin

[Simon]

So what is the deal with Codesys ? looks like an ideal solution for turning various hardware into a HMI or have a misunderstood?

[bookaboo]

Codesys is a generic HMI and PLC / general automation software. It's a third party platform that IFM and others use (IFM have a specific variant but it's still Codesys). It can do both HMI and general ladder / function block stuff. Most of our projects were on 2.3 but the new projects are 3.5.
I don't do much of the work directly, I usually do the test rigs and commissioning. I know some of the limitations that bug me are slow upload (even over ethernet) and sloooow graphics functions, hopefully they are fixed in 3.5. But in general it's par for the course for these types of environments.

Whatever you choose be sure you have a technical contact, these sorts of systems are just as quirky as embedded, there are often errata that you have to find workarounds for. Also, when dealing with engines, expect the unexpected. ECUs in low-med volume OEM are custom programmed with certain parameters, usually incorrectly if it's a new spec, so you can spend days wondering why your CAN control isn't as you expect only to find the ECU is flashed wrong.

The other option our competitors tried was the bigger name PLCs (Siemens, Mitsubishi etc) intended for fixed plant. Don't go there, they are not rated for the vibration, ingress or automotive supply rails.

[Simon]

what about running a web page in a full screen browser?

[SiliconWizard]

- What maximum acceptable delay between power-on and the user interface usable?
What a silly question , instantaneous of course! OK, less than 1 minute, there comes a point where you have to say, look, cheap and slow or fast and fooking expensive, you choose boss/customer

Yes it is silly, which is why I asked.

Jokes aside, the power-on delay (or "boot" time if you prefer) is a key spec of any UI. Not even sure how that spec could even be missed.

As we've all been subjected to, there's been a trend in "modern" lab equipment to have pretty long boot times (scopes, sig gens, even some multimeters now...)
This can be extremely annoying.
But in some application, the delay may not be only annoying - it could be a safety concern, if you have to wait a full minute before being able to do anything.

Obviously this spec can lead to completely different solutions. If only a couple seconds or less is required, almost any Linux-based-on-a-SBC solution will be out of the question. Although with some SBCs and great care configuring the Linux boot (and not going to a full desktop environment), that can be usually lowered to a few seconds. Have never managed to get something operational with this setup in less than about 5 seconds. Whereas with a MCU-based solution, the power-on delay can be nearly instant (a few ms to a few tens of ms.)

If in your case up to 1 min is acceptable (make sure of it though, as it could again annoy the hell out of your customers, even if there is no safety or otherwise written constraint), any Linux-based SBC solution with an off-the-shelf display will work. Program the UI in your favorite language, there's no lack of them for quickly building UIs. Done. Also, if selecting this solution, ideally set it up in a read-only manner (which may take some work on the Linux config side) so there's no possibility of data corruption that could lead to a non-working state.

[bookaboo]

Not sure about the new generation of controllers but the current/legacy CR1080 that we use would have no chance of that from what I've seen. The only connectivity we do is a 3rd party satellite modem that talks over CAN and parses out the basics.

[Simon]

- What maximum acceptable delay between power-on and the user interface usable?
What a silly question , instantaneous of course! OK, less than 1 minute, there comes a point where you have to say, look, cheap and slow or fast and fooking expensive, you choose boss/customer

Yes it is silly, which is why I asked.

Jokes aside, the power-on delay (or "boot" time if you prefer) is a key spec of any UI. Not even sure how that spec could even be missed.

As we've all been subjected to, there's been a trend in "modern" lab equipment to have pretty long boot times (scopes, sig gens, even some multimeters now...)
This can be extremely annoying.
But in some application, the delay may not be only annoying - it could be a safety concern, if you have to wait a full minute before being able to do anything.

Obviously this spec can lead to completely different solutions. If only a couple seconds or less is required, almost any Linux-based-on-a-SBC solution will be out of the question. Although with some SBCs and great care configuring the Linux boot (and not going to a full desktop environment), that can be usually lowered to a few seconds. Have never managed to get something operational with this setup in less than about 5 seconds. Whereas with a MCU-based solution, the power-on delay can be nearly instant (a few ms to a few tens of ms.)

If in your case up to 1 min is acceptable (make sure of it though, as it could again annoy the hell out of your customers, even if there is no safety or otherwise written constraint), any Linux-based SBC solution with an off-the-shelf display will work. Program the UI in your favorite language, there's no lack of them for quickly building UIs. Done. Also, if selecting this solution, ideally set it up in a read-only manner (which may take some work on the Linux config side) so there's no possibility of data corruption that could lead to a non-working state.

There are no safety concerns here, just impatient ignorant operators that have plenty to do while the machine is turning on. i have a Rock4 board, I may play with that. What is annoying is that it is hard to come by the specs of the solid state interfaces and the drives that people sell. Not sure I want full blown M.2 (cost) don't know if the little plug in things are really any good or just anther SD card.

[HwAoRrDk]

The problem with lobbying the client to provide a specification for something undeclared is that it can sometimes result in farce.

Like, you go to them and ask "what is your requirement for start-up time?", and they come back and say "10 seconds". But after meeting all their other requirements, you can only provide a system with a 30 second start-up. "Oh, no problem", they say, "that's fine". "So why did you give us a requirement for 10 seconds then?" "Oh, we didn't really know, so we pulled out of our arse whatever arbitrary number we thought sounded best, because you said you needed a number..."

(No, I'm not bitter and definitely haven't been there several times and got several t-shirts. )

[Simon]

Well I would not make it the primary focus, if someone wants an instant start I have that solution already, any micro I can get a timed interrupt running on and control the GPIO with a text display

[coromonadalix]

opensource arduino plc's   

[Simon]

opensource arduino plc's   

steady on, I may have to get the longest "string" of four letter words you have ever seen 

[Nominal Animal]

Have never managed to get something operational with this setup in less than about 5 seconds. Whereas with a MCU-based solution, the power-on delay can be nearly instant (a few ms to a few tens of ms.)

Yep.  Depending on the hardware, several of those five seconds can be unavoidable; like the BIOS/EFI startup on AMD/Intel that often takes 15-30 seconds to even start booting an OS.

(Having an animated bootsplash, like on old Mac OS showing the icons for the kernel/OS modules and services it starts during bootup, can make that feel much shorter, though.  You can test it on unwitting people too: just don't ask which form of boot is faster, ask which one they prefer.  Something to seriously consider.)

In all cases, I cannot stress enough how much easier systems integration and minimising bootup time is, if you have SSD-class (PCIe/NGFF or SATA) bootable storage.  It is the one thing I personally will not do without, when making gadgety appliances based on Linux SBCs.  If the hardware does not support bootable SSDs, use a minimal bootloader that can boot off USB, and an USB-to-SATA dongle, and a cheap but reliable SSD (Kingston, Western Digital).  Even if you have only USB 2 available, that still makes sense, because of the utterly superior small random read block rates.  Test it in practice, to see for yourself how large a practical difference it makes.

With fast PCIe, or native or USB3-bridged SATA storage, even a $50-class sub-10 watt SBC can feel like a desktop machine when browsing the internet and watching videos and playing retro games.  Just make sure their OpenGL ES implementation is supported in Linux.

(Although, using a wrapper around the browser to keep your browser profile on a tmpfs (ramdisk) –– compressed and stored to permanent storage when last browser instance closes, set up and decompressed from permanent storage when the first browser instance starts –– makes the most of the difference, even on Raspberry Pis running off SD cards.  I started doing that 15 years ago on a Linux minilaptop with a 2.5" spinny-disk drive, in the Acer Aspire One era.)

[Simon]

Well we have settled on a SBC, currently we are using Squareline studio/LVGL. So for the sake of testing and learning myself I have a RPi P400 setup with Ubuntu server so no desktop, I can export code from squareline studio but no idea what to do in the middle. As I understand it I need to open it with VS Code and tinker with the code to set it up for the hardward myself. I suppose at this point it's how does one code for Linux, any suggestions on resources welcome.