RPi 4 vs. Compute CM+ for touchscreen console for rackmount instrument

[pratiken]

Hi,
I apologize if this is the incorrect board for these questions.

My small company builds instruments that are housed in rackmount enclosures up to 5 or 6U in size. These are controlled via Ethernet or USB.

A client wants a simple touchscreen added to the front of the rackmount for occasional manual control. This is in a laboratory setting. We don't have much time to develop a custom solution for this so I was thinking I could use an RPi4 with a touchscreen. It would connect with the rest of our instrument with UART. We would only need to develop the GUI for the Pi.

Then I found the Compute CM3+ module which is more for industrial use like this. However, we don't have time to develop a new PCB to mount the Compute. Reliability is important as if this module dies we would have to go service the instrument and replace it.

1.).    Is the CM3+ with Dev. header board more stable/reliable than an RPi 4?

2.) .   Are there industrial touchscreens I should be looking at that can easily interface with RPi? Or would the ~$100-200 ones I see on Amazon be sufficient for occasion use over the lifespan of our warranty (3 years)? This is in a clean laboratory setting and Not a harsher environment such as a classroom might be or heavily industrial setting.


Thanks for your help!

[Microdoser]

Recently a new pi compute module has been released, the CM4 and also the CM4 IO board which they say is designed to be used as-is in industrial designs and has a touchscreen display adapter on it. It has 1GB ethernet and USB 3, as well as a 1XPCIE slot. UART would be available through the standard Pi 40 pin IO header. There is now an option for onboard storage as well. You may find this gives more flexibility in your design. Up to 8GB RAM and up to 32GB storage.

https://www.digikey.com/en/maker/blogs/2020/raspberry-pi-compute-module-4-loaded-with-options

I have been using the official 7" touchscreens in a fairly dirty environment for a couple of years now and I have found them to be very reliable.

[Bicurico]

I remember reading that the RPi is not rated for industrial use?

[Microdoser]

I remember reading that the RPi is not rated for industrial use?

https://techcrunch.com/2020/10/19/raspberry-pi-foundation-launches-compute-module-4-for-industrial-users/

I think they are starting to aim at more serious applications

[Bicurico]

Cool. I was not aware of it.

Arduino and Raspberry Pi seem very tempting for industrial use, but I was informed that one should not use such devices in industrial environment, because they lacked the required rating. The consequence would be that insurance companies could refuse payment in case of any failure, even if unrelated to the use of these devices.

It is nice that Raspberry Pi is launching a version with this industrial rating. However, the fact that they chose to use an interface that requires a separate board like the I/O interface board opens the question if that board is rated for industrial use as well.

I am not ppointing any fingers or question the usability - rather I would like to know if this solution can be safely used in industrial environment and if insurance companies could object the usage.

Regards,
Vitor

[Microdoser]

Cool. I was not aware of it.

Arduino and Raspberry Pi seem very tempting for industrial use, but I was informed that one should not use such devices in industrial environment, because they lacked the required rating. The consequence would be that insurance companies could refuse payment in case of any failure, even if unrelated to the use of these devices.

It is nice that Raspberry Pi is launching a version with this industrial rating. However, the fact that they chose to use an interface that requires a separate board like the I/O interface board opens the question if that board is rated for industrial use as well.

I am not pointing any fingers or question the usability - rather I would like to know if this solution can be safely used in industrial environment and if insurance companies could object the usage.

Regards,
Vitor

They say it is and the wireless is certified too if you use their antenna. It can operate on 24V because they say that is more common in industrial applications.

You can either use their IO board or design your own, they seem to have made a fairly flexible product.

I would suggest that rather than not know and ask more questions here, maybe check it out, watch a few videos, and read the datasheets. They are really pushing this one to be more serious than previous Compute Modules.

[SiliconWizard]

I remember reading that the RPi is not rated for industrial use?

https://techcrunch.com/2020/10/19/raspberry-pi-foundation-launches-compute-module-4-for-industrial-users/

I think they are starting to aim at more serious applications

With embedded eMMC. Nice!
That's starting to look good.

Now the main remaining issue (IMO) is the OS.
The official available Linux distros are OK for general purpose use, but I personally think they are not so well adapted for industrial uses.

[ejeffrey]

Cool. I was not aware of it.

Arduino and Raspberry Pi seem very tempting for industrial use, but I was informed that one should not use such devices in industrial environment, because they lacked the required rating. The consequence would be that insurance companies could refuse payment in case of any failure, even if unrelated to the use of these devices.

You will have to be more specific about what ratings you want.  There are a bunch and there is no such thing as a generic "rated for industrial use".  Honestly that statement sounds like whoever was "informing" you was just trying to justify a decision they didn't understand -- that doesn't mean the decision is wrong, just that the person informing you didn't understand or wasn't interested in explaining it.

Raspberry pi has a bunch of compliance and safety ratings for many of their boards in many jurisdictions, you can find them here: https://www.raspberrypi.org/documentation/hardware/raspberrypi/conformity.md

Mostly these things are EMC ratings for unintentional radiation and certifications for intentional radiators such as wifi modules and antennas.  It also has flammability, RoHS, and a few other safety ratings.  None of these are industrial specific, although EMC in particular has different categories for different environments.  And a board you build yourself isn't going to have any of these certifications either unless you go through the process.

Also note that these certifications apply only to the Pi itself.  If you build an instrument, having parts with the needed certifications is helpful but not enough, the final assembly needs to be certified.

If you are talking about approvals for use in life/safety critical applications, basically nothing has that unless you are explicitly paying the manufacture for that.  And you in turn shouldn't be promising that to your customers unless they are paying for it and you really understand what is involved.

There are a bunch of reasons why you might not want to use things like the arduino or Pi in an industrial setting.  Those are issues like form factor, cost, features, long term availability, and ease of integrating into a final product.  The compute module is an attempt to alleviate several of these issues.  It ditches the pin-headers and IO jacks for a mezzanine connector that lets you route the signals where they are needed, includes eMMC memory for the system image, and provides guaranteed availability for 8 years.

In terms of insurance, that is obviously up to your local regulations, insurance companies, and your specific agreements with the insurance companies.  In the US insurance companies generally can't refuse a claim based on something that didn't contribute to the problem.  Where UL listing (which is the primary insurance related certification) is that if a non-UL listed appliance causes or contributes to a fire, *then* your insurance may not pay out, although it depends on a lot of factors so don't take my advice here.

[Bicurico]

If it is OK, let me explain the context of my earlier questions in this thread:

1) I am not an electronics engineer - all I know is by learning it myself
2) I work in CAD/CAM/CAE, RP and Reverse Engineering. Main field of work is programming CNC machines.
3) The idea was to develop a control/monitoring system to gain data on which machines are working and which are stopped. This can be done by interfacing the controller, however, due to customers having a high number of different machines, this gets complicated. Also, older controllers do not have any interface for this. So one way I imagined was to use an Arduino ou Raspberry Pi with acceleration sensors mounted on the Z axis of the machines. Through WLAN data of the accelerometer would be sent to a controller PC, which would correlate this data with the NC programs in queue to be processed.

It was at this point that concerns arose that said hardware (Arduino/Raspberry Pi) are not rated to be used in industrial applications.

Sorry for hijacking this thread, I just thought that it would be a useful and fair advise to OP to consider rating for industrial use before developing whatever product. Also, I just mentioned that I had not noticed that Raspberry Pi was meanwhile available with said rating. Finally, I do not know what further considerations are needed for a given application. Can a Raspberry Pi module with industrial rating be attached to a CNC machine? No idea! I wouldn't even know how to get that information.

Regards,
Vitor

[ebclr]

This is made for your application

https://pt.aliexpress.com/item/33037605021.html?spm=a2g0o.cart.0.0.28593c00fLlySm&mp=1

[Mr. Scram]

https://techcrunch.com/2020/10/19/raspberry-pi-foundation-launches-compute-module-4-for-industrial-users/

I think they are starting to aim at more serious applications

Just saying something is industrial grade doesn't make it so. You need testing and paperwork to back up how it is industrial and I'm seeing very little of that.

[Mr. Scram]

Hi,
I apologize if this is the incorrect board for these questions.

My small company builds instruments that are housed in rackmount enclosures up to 5 or 6U in size. These are controlled via Ethernet or USB.

A client wants a simple touchscreen added to the front of the rackmount for occasional manual control. This is in a laboratory setting. We don't have much time to develop a custom solution for this so I was thinking I could use an RPi4 with a touchscreen. It would connect with the rest of our instrument with UART. We would only need to develop the GUI for the Pi.

Then I found the Compute CM3+ module which is more for industrial use like this. However, we don't have time to develop a new PCB to mount the Compute. Reliability is important as if this module dies we would have to go service the instrument and replace it.

1.).    Is the CM3+ with Dev. header board more stable/reliable than an RPi 4?

2.) .   Are there industrial touchscreens I should be looking at that can easily interface with RPi? Or would the ~$100-200 ones I see on Amazon be sufficient for occasion use over the lifespan of our warranty (3 years)? This is in a clean laboratory setting and Not a harsher environment such as a classroom might be or heavily industrial setting.


Thanks for your help!

I do hope you're not desiging for a three year lifespan because that's where your liability ends.

[Nominal Animal]

Just saying something is industrial grade doesn't make it so. You need testing and paperwork to back up how it is industrial and I'm seeing very little of that.

No matter what they do, under heavy load the USB subsystem can "forget" packets due to hardware issues, which is a killer.  You can't fix that in software.  (They've done a lot of work on that, so they probably think they've added enough software band-aids on to so that it is now "rare enough" for their users to not worry about anymore.  They definitely don't like people talking about it.)

Anyone using a 'Pi for anything requiring reliability is getting the pain they deserve.  "Raspberry" and "reliable" just do not fit together, due to the Qualcomm hardware used.

There are a lot of Linux SBCs you could choose from.  Just because one is popular, does not make it good or best; only popular.  Linux (kernel) on ARM is ubiquitous in appliances nowadays, and rarely has any issues: it's either the hardware, or the "userspace" software that bugs out.

[l0wside]

I am using the Pi here as a home automation display and just went through the painful process of restoring the SD card after it had failed. I would not recommend that in an industrial setting.
There are a bunch of industrial PCs with integrated display around. Might be a bit overdone, but likely the easiest approach. As for the Linux distribution, just about any should do.

Software-wise, TouchGFX with an STM32F7 would look attractive, but I could not find any industrial boards with it. There is a plethora of development boards, but these will not help you.

If the display is not safety-relevant and not part of the actual control loop, a few missing packets will likely not be critical. If you have a safety rating on the system, your effort is likely to explode anyway.

[Mr. Scram]

I am using the Pi here as a home automation display and just went through the painful process of restoring the SD card after it had failed. I would not recommend that in an industrial setting.
There are a bunch of industrial PCs with integrated display around. Might be a bit overdone, but likely the easiest approach. As for the Linux distribution, just about any should do.

Software-wise, TouchGFX with an STM32F7 would look attractive, but I could not find any industrial boards with it. There is a plethora of development boards, but these will not help you.

If the display is not safety-relevant and not part of the actual control loop, a few missing packets will likely not be critical. If you have a safety rating on the system, your effort is likely to explode anyway.

That's what industrial grade memory cards or the built in memory are for. In the case of the former it's usually actually SLC memory, which should be much more resistant to abuse. I'd still consider other options which are more proper industrial grade.

[SiliconWizard]

I am using the Pi here as a home automation display and just went through the painful process of restoring the SD card after it had failed. I would not recommend that in an industrial setting.
There are a bunch of industrial PCs with integrated display around. Might be a bit overdone, but likely the easiest approach. As for the Linux distribution, just about any should do.

The CM 4 module includes eMMC, so that would solve a lot of issues we could have with a standard Pi using an SD card. SO, that's a step forward. With eMMC (as long as they chose reliable parts, I'll have to figure it out), that should be much better. SD cards, OTOH, are notoriously unreliable for this kind of use.

That said, I still don't agree with the OS being generally OK for industrial use. No, not just any distro should do. Any distro is a combination of Linux components each with a given version, that may exhibit bugs, be unreliable, or whatever, if the whole thing has not been tested properly and thoroughly. Besides, all those SBCs usually have incomplete (or buggy under some circumstances) support of some of the hardware outside of the CPU, which may trigger all kinds of problems. The Pi(s) in that regard are certainly not the worst off on the market, but I think software support is still far from perfect either.

Just my 2 cents. Never underestimate the software side of any project, especially when you target reliability.

[Nominal Animal]

Besides, all those SBCs usually have incomplete (or buggy under some circumstances) support of some of the hardware outside of the CPU, which may trigger all kinds of problems.

I disagree.  Samsung (Exynos) and Amlogic (Meson) have done quite a lot of work in recent years to push the support of their boards to mainline Linux kernels, and to a level users might expect.  You should not need to use vendor-provided kernels, nor have any binary blobs executed by the main processor (firmware files for peripherals with their own processors, like RAID adapters, excluded).  There are still occasional board variants which require an update/patch to the device tree description (a text file that is compiled to .dtb, describing the board), but buggy is not the term I'd use with SBCs based on Amlogic or Samsung Exynos SOCs.

(While Allwinner (sunxi) board support is generally acceptable, the company itself does not contribute, and even breaks GPL, so I cannot in good conscience recommend those at all.  A LOT of boards are using Allwinner SOCs, like A10, A20, H3, H5, H6, though.)

The Exynos and Meson boards in Armbian supported list – Odroids, La Frite, Le Potato –, is a good place to start.  I've been happy with mine (Odroid C1+, HC1, La Frite).

It is important to realize that the Qualcomm chipset used in Raspberry Pis has hardware issues that can be eased, but not fully eliminated, in software.  Those others do not.  Wrt. Allwinner, the issue is complete lack of cooperation and documentation from the SOC manufacturer.  (Qualcomm also pretty much hates everything F/OSS, though.)

I think software support is still far from perfect either.

Wrt. the userspace (including everything in the operating system besides the kernel), I fully agree.  I think it is even becoming worse, as fewer and fewer developers care about the mess they create.

[Syntax Error]

Going left field here, for touch screen use, have you condidered using a point-of-sale terminal? Ethernet, Wifi, fanless, 15 to 17 inch touch screen (capacitive, resistive or acoustic), USB, industrial/commercial rated and in a nice case. Some machines for under $1000 usd new, but cheaper for reconditioned units. Just add your own Linux distro. Or use a slide and hide touchscreen rackmount monitor?

[ebclr]

Don't ignore, this is your real and easy solution

This is made for your application

https://pt.aliexpress.com/item/33037605021.html?spm=a2g0o.cart.0.0.28593c00fLlySm&mp=1

[Microdoser]

Don't ignore, this is your real and easy solution

This is made for your application

https://pt.aliexpress.com/item/33037605021.html?spm=a2g0o.cart.0.0.28593c00fLlySm&mp=1

That is just a screen, what drives the screen?

[Nominal Animal]

If this was me, I'd use an Odroid C4 (quad-core Amlogic S905X3) or Libre Computer La Frite, with a 8GB or 16GB EMMC module, and  a capacitive or surface acoustic wave multi-touch display.  Those two SBCs are way overpowered for a simple UI, but meh.  I like SAW better than capacitive touch for industrial uses, as you can get displays with really tough surfaces (as in vandal-proof, even).  (Touch points are detected using the changes in ultrasonic pulses propagating within the display material, when something comes to contact with the display.  Really cool tech, but not new.)

For rotary knobs etc. that connect to the UI only, I'd use a simple microcontroller with native USB support handling the buttons and knobs, talking to the SBC via USB HID.

For the "firmware", I'd redo the full software stack (but I'm familiar with this stuff and have done it before).  The basis would be upstream Debian, pared down to the absolute minimum.  The user interface would be Python3 + Qt5 (for maintenance reasons), on top of EGLFS (Qt for embedded Linux).  Essentially, the init system would only start the necessary services – look at e.g. OpenWRT for how minimal that is –, and then (as a dedicated user, with a service supervisor that restarts the UI if it crashes (runit style, written in C).  If the device is network-connected, I'd also install fail2ban as a matter of principle, and possibly tripwire, with support for external logging.  All would be packaged Debian-style, for long-term maintenance reasons.  (Not just to make maintenance and upgrades simpler, but also because it helps developer consider what things need to be included in the packages, instead of tarballing their entire development environment up and telling future devs to use that as-is.)

For the communication with the actual instrument, I'd use the hardware serial ports with hardware flow control if possible; and very likely through a digital isolator like Si86xx series.  It may not be necessary, but it means the display-interface can be treated as a completely separate unit, and can make a big difference in long-term maintenance and development costs.  On the display side, the Python3 UI would talk to a local C service process (instead of directly to the serial-connected instrument), to create an interface between different instruments and different UIs.  Also, that same service daemon would handle commands and status requests via Ethernet.  (This was the structure I suggested for a fusor project, for example; it modularizes the state monitoring and UI stuff also, so that the UI itself does not need to do e.g. logging, and can be developed as a separate module instead of as an integral part of each instrument.)

If you don't want to look for someone to do this for you, there are companies specializing in human-machine interfaces you can outsource this stuff to, for example Norwegian Keytouch.

If you do get someone to do this for you, make sure the contract includes the requirement for maintaining full documentation not only on the final products, but also the steps taken.  If you intend to do business for more than five years, then at least half of the software side should be maintaining good documentation on the product development process; the worst thing that can happen, and usually does happen, is that in a few years, you end up maintaining a legacy codebase nobody has the time or ability to debug anymore, and you're just hoping that it'll work out.  It is not just proof against someone getting hit by a bus, but also an indispensable problem-solving tool, when something goes awry on the software side.