Revolution Pi – The Industrial Raspberry Pi
revolution.kunbus.com
revolution.kunbus.com
Back when I was in mechanical maintenance, we would wire up every machine on the floor (lathe, shave, heat treat, cymbal cutters, you name it) to Serial Comm adapters that convert the RS232 from most machines into IP/CAT5. These only cost $80USD, and were bullet-proof enough to replace when needed. The CAT5 lines were shielded so they were robot friendly, and went all the way to the front office where the Linux administrator had them all wired into switch panels and network servers for the guys in the QC labs.
Besides, most newer CNC come with remote desktop or SSH or something remote you can use to poll them or interact with them by default. Sometimes they even come with wifi antennas.
I guess if you were building a new robot or machine, and needed a logic interface, this would be an excellent solution to a proprietary world, but as a bolt-on accessory no.
These aren't little gateways to CNC machines built-in interfaces (although they can be), they're controllers and automation systems for factories and production lines.
Your serial to IP adapters are one use case where this could be used, and are one of the few things I've installed that was cheaper than this. If the machine needs a true PC for config/calibration software, displaying vision results from industrial camera, or reading/writing data to a plant network, the typical answer is an OnLogic ML100G-51 industrial fanless PC at $850. Sometimes the answer will be a PLC in with a built-in PC, like a Siemens S7-1500 or Beckhoff CX2020 at close to $3,000. Often, you also need an operator interface, which is usually some variant of a Windows CE computer bolted to a rugged touchscreen, and run between $500 for an off-brand 7" display to a $1500 software license plus that OnLogic PC plus a $500 or more large-format touchscreen. However, if the PLC needs to communicate with a USB or serial device like a barcode scanner, I'd reach for a Real Time Automation 435USB module at $640, which is basically the same as one of these. To remote into the machine we recommend every customer get a $600 Ewon Cosy industrial VPN appliance, it's an easy sell at less than the price of most service calls. If it needs a small camera, a $2000 smart camera marries a little ARM processor to a low-resolution monochrome sensor, or you connect GigE cameras to a higher-power vision processor for double that.
If you're going to sell 10,000 units to fill a particular industrial niche, you can injection mold your own DIN rail enclosure, make your own baseboard for 24V screw terminal connections and which might use a Pi Compute module or fully integrate a little ARM processor, and which will hide any of the details from end customers behind "no user serviceable parts inside" and "warranty void" stickers.
All of the above do essentially what a $35 RaspberryPi and a bit of Python scripting could do, but with a warranty, enclosure, manufacturer support, vendor support, and user manuals that customer maintenance departments can use. All of those are valued by many careful customers, but for half the price this is interesting enough to pay an engineer for a couple hours of custom work. For sales purposes, these go into the panel with 24V screw terminals and DIN rail mounting that checks off industrial standards conformance and don't look as crappy as wall warts and custom brackets. Those are the devices this thing is competing with.
Hm? Most machining tools cost $100,000 to >$1,000,000. Why would a DIN bank of $360 control modules bust the budget?
Another added bonus is the built-in flash, which is significantly more reliable than the whole SD card setup (for many reasons). Or the two CSI ports (only one is exposed on the standalone RPi board).
All in all, for anything except prototyping, this is a much better solution than a standalone RPi. In my designs, I found it to be a useful and reliable workhorse.
https://www.necdisplay.com/system-on-a-chip/
https://www.nec-display-solutions.com/p/uk/en/products/acces...
also the balena fin for IoT
Because I agree it is a very useful form factor.
We used a chip based on Cypress CYW43455, basically the same as on the Raspberry Pi 3B+, to benefit from the existing decent driver support.
My question would be how would I start out doing something similar? Because the I was thinking I would just have a look at the rasperry pi 3 b+ schematics (which do not show the Wifi Module, because they are incomplete, so I guess SDIO or UART?). Compare it to the schematics of the compute module, design a board thats connectso the Cypress Wifi Module and use the same drivers used in the rasperry pi 3 b+.
I'm at a Rockwell shop getting 5069-L306 PLCs for just under $1000 (which is a pretty good rate), and have only gotten list-price quotes for a handful of Beckhoff parts. I wish they'd just publish a price list and discount schedule. They wanted a lot more than $500 for a CX5020 or CX9020 last I looked.
For complete honesty... I ended up using a Galil motion controller rather than the Beckhoff ARM unit mentioned above, but that was due to really tight form-factor issues. Technically, the Beckhoff unit would have been better. The overall hardware cost was moreorless a wash between Galil and Beckhoff.
You'd have to ask Beckhoff or test for yourself. Depending upon whats going on on PC level, I think sub 10ms round trip is fairly typical. I should think the TCP/IP interface will be PLC cycle-time limited (PLC cycle time of 1ms is typical) plus some fractional overhead from the TCP/IP processes themselves.
These tick a lot of useful boxes, in particular the supply voltage, DIN Mount, usb host ability (plug in a PC to be able to field service a dead unit), real-time clock, and isolated IO modules.
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).
https://www.kiwi-electronics.nl/din-rail-raspberry-pi-behuiz...
I guess I'm not sure what you mean by the word 'kit'
It looks cool and I want to like it, but it needs a RTOS, if any at all, for automation.
Second, you can run bare metal on the Raspberry if you really want to.
The patches are adding higher nice values, and trying to remove some of the egregious kernel contention.
True hard real time is great, but not actually necessary for a lot of automation applications.
I see something about a passive heat sink, I wonder if that's enough...
Customers who don't need a GUI may create a custom Revolution Pi image based on "Raspbian Lite" using our imagebakery scripts: https://github.com/RevolutionPi/imagebakery
I would suspect it would be more common to connect via ethernet from a PC or laptop, vs local console. Especially for field servicing, carrying a laptop is simpler.
In the case HMI is needed, installing the desktop is just some additional packages.
This raises another question: what repository are you using? How are (security) updates handled, if at all?
Since the image is based on Raspbian, updates are installed via apt-get as usual. There are some deb packages of our own pre-installed. Updates for those are made available via our apt repository at packages.revolutionpi.de.
Partly off topic, but I've imagined an ecosystem where Pi-like SBCs _only_ connect out via USB-C to a powered hub, and from there to physical I/O. Sort of a different take on North Bridge / South Bridge.
But appliance manufacturers aren't interested.