Hi, I'm a kernel dev on the Revolution Pi team. AMA.
Two comments/suggestions:
1. I'd prefer a DVI-D connector (or even VGA) over the Micro-HDMI connector if I wanted to use this with a display. I've found that the bulkier, screw-locking DVI port is much less vulnerable to accidental disconnection or damage than HDMI (been burned a few times there, two "machine won't start" panic calls that turned out to be loose HDMI cables, one broken cable end, and one broken video adapter from ham-fisted maintenace personnel pulling on a stiff HDMI cable). Full-size DisplayPort has a latch, but even mini-Displayport feels sturdier than micro-HDMI without taking up much more space. I recognize that HDMI supports audio while DVI does not, but if my machine is playing audio it's likely just a fault klaxon from the stacklight rather than speakers or a TV.
2. A killer feature of, for example, Banner's XS26 safety controller (Don't panic, I don't intend to try to use your product as a safety controller, LOL) is their configuration storage device. If the device boots into factory defaults (either new from the manufacturer or after some reset image is loaded) and there's an image on the attached storage device, it will copy that stored configuration into memory and reboot. This means that my customer can keep a spare part on the shelf (for any number of machines!) and if one burns out the replacement doesn't involve a laptop, a rookie technician can replace it with nothing but a screwdriver. Bury a USB-A port (or, less rugged, a uSD socket, or less universal, a USB-micro drive port) on the bottom or even the back by the DIN-rail attachment and that will do a lot towards making this "scary Linux thing" in a potential customer's panel something they can almost treat as an off-the-shelf part like any other. (Note: I've never had an XS26 fail on me, and expect that your extended-temp eMMC is more trustworthy than most Flash drives. This is more about having a guaranteed backup and nontechnical replacement procedure than something I expect to do frequently.)
The video port coming out of the Raspberry Pi SoC is HDMI, hence the choice of the connector. We've put the connector on the top of all of our products to lessen the chances of the cable accidentally coming lose. The top and bottom of the case is primarily used for vents. We'd have to make them smaller to fit a VGA or DVI connector there and that might negatively impact heat dissipation. That said, I agree that HDMI is not as rugged. A particular problem we've encountered are cheap cables which connect the shield to ground.
As for flashing the products, there's a micro USB port on the front plate which allows flashing the eMMC from an attached laptop or PC. It's also possible to mount the eMMC to retrieve logfiles from the machine that way. When the machine is booted, it senses whether bus power is provided on the micro USB port. If so, the USB port on the Raspberry Pi SoC is switched to gadget mode instead of host mode. You then need to run a little program called rpiboot on the attached laptop which downloads a firmware to the Raspberry Pi to turn it into a USB Mass Storage Device. Afterwards the eMMC pops up on the attached laptop as an external drive:
https://www.raspberrypi.org/documentation/hardware/computemo...
It would in principle be possible to build small gadgets which users plug into the micro USB port and which automatically flash the attached Raspberry Pi without the need for a laptop.
Another possibility would be to split the eMMC into multiple partitions, one containing the regular OS and the other to store an update image. The system would initially boot into a RAM disk, determine whether an update image is present, extract that over the regular OS partition and reboot. The update image could be deployed via ssh.
> Another possibility would be to split the eMMC into multiple partitions, one containing the regular OS and the other to store an update image. The system would initially boot into a RAM disk, determine whether an update image is present, extract that over the regular OS partition and reboot. The update image could be deployed via ssh.
I'm less concerned about update images and more about backup images. If an update has been created, I'd want to be online with the machine anyways to test the change and I'd have no problem using ssh to develop and deploy.
What I'm more concerned about is whether I'm going to get a call from the third-shift maintenance on a Sunday morning if the label printer stops working and the HMI shows "FAULT: Print Computer Watchdog Timeout". I suppose I could create an image that would do nothing but boot from eMMC to a ramdisk, look for a backup image on the micro USB device, and overwrite the eMMC with that image (if found). They couldn't set up a new spare without contacting me, but they could keep that on their shelf...
Do you think your company might develop a non-industrial line for hobbyists which could bring the price more into the range of sub $100?
However, they might not since that's the main product, along with the I/O expansion modules and the software that drives all of this. To make the motherboard useful that software would probably be needed.
$360 is cheap if this system does what is claimed. Sub $100 is probably not realistic given what is involved with being truly industrial grade - the level of protection from the environment and reliability alone would require raising the price beyond that.
There's a big difference between an "Industrial Pi Case with a DIN mount" and a certified Industrial Pi PLC. This seems to be the latter.
What real time extensions did you use with the Raspbian kernel?
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-sta...
That patch set is slowly being upstreamed into the mainline kernel. We regularly encounter incompatibilities with drivers for the Raspberry Pi SoC and upstream our fixes and feature work as well, e.g.:
https://git.kernel.org/linus/f7da7782aba9
https://git.kernel.org/linus/3c7b30f704b6
I must admit I wasn't aware of LinuxCNC, thanks for the pointer. This would seem to be a really nice use case for Revolution Pi.
We did extensive testing in the climate chamber and felt that going down to -40°C is safe.
The BCM2837 normally runs at 1200 MHz and the firmware starts downclocking when the core temperature exceeds 80°C. Once it reaches 85°C, the frequency is reduced to 600 MHz. It will be further reduced to 300 MHz when going beyond that. In our testing we found that the CPU is eventually halted when it becomes too hot, but can be rebooted without any issues once it has cooled down.
If you know that ambient temperature regularly exceeds 55°C, it may be necessary to install cooling in the cabinet together with the RevPi.
Since you're mentioning street cabinets, our customer Nicolai Buchwitz of Enda KG regularly installs our products in street cabinets for monitoring of hydrogen fuelling stations:
https://twitter.com/NicolaiBuchwitz/status/11127278200427274...
Does the hardware watchdog work when halted because of over-temp?
One particular product in the Revolution Pi lineup called "Connect" has an additional hardware watchdog which is also capable of resetting attached devices via a relay. That one works even when the BCM2835 has locked up completely. However, the CPU needs to have cooled down a bit to reboot successfully.
Also what is the mapping between your various IO modules and how they are named in the program code?
You may use whatever language you prefer. There's a Python module called RevPiModIO, authored by a member of the Revolution Pi community, Sven Sager: https://revpimodio.org/en/homepage/
A NodeRED module was contributed by another customer, Erminas: https://flows.nodered.org/node/node-red-contrib-revpi-nodes
If you're into Structured Text, there's a software called logi.RTS included in our image (needs a license for unlimited use, 1 hour is free).