Pretty sure it didn't had an accessible SD card "Revolution Pi has a specially adapted Raspbian operating system, which is equipped with a real-time patch. The use of Raspbian ensures that most of the applications developed for the Raspberry Pi can also be used on the Revolution Pi."
The Raspberry Pi Compute Module built into the Revolution Pi products has an eMMC of 4, 8, 16 or 32 GByte. Each product has a micro USB receptacle via which it can be flashed or mounted from an attached computer. Users are free to use whatever image they want.
Not anymore, no. We use the "Raspbian with desktop" image as a basis and delete most of the games to make the image fit on the 4 GByte eMMC variants of our products (with about 1 GByte to spare).
Why desktop as opposed to a server (headless) image?
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?
A lot of our customers have a background in automation and are used to Windows on their desktop PC, with little prior Linux experience. Shipping a desktop by default is intended to make their life easier.
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.
Revolution Pi is an open, modular and inexpensive industrial PC based on the well-known Raspberry Pi. Housed in a slim DIN-rail housing, the three available base modules can be seamlessly expanded by a variety of suitable I/O modules and fieldbus gateways. The 24V powered modules are connected via an overhead connector in seconds and can be easily configured via a graphical configuration tool.
There are at last count three separate sets of patches that add real time support to the Linux kernel. I'm interested to find out which they used or if they wrote their own.
True hard real time is great, but not actually necessary for a lot of automation applications.
I used to work on a product that these would have been perfect for. At the time (early 2000s) we were using consumer mini-itx stuff in industrialised cases, because the true "industrial" stuff was all decade-old tech, or an absolute fortune (and still at least a couple years out of date).
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.
The DIN rail idea is very neat. I've seen a few projects of mounting regular Pi's in server racks but DIN is a much more compact form factor. Wonder how long until someone makes a regular Pi to Din kit.
Incidentally, the Raspberry Pi Compute Module is indeed "rather unknown", which is a shame. It is amazingly useful and lets you design devices without getting into high-complexity PCBs and BGAs. You can place an SO-DIMM socket on a simple 4-layer board (adventurous types might even go with 2 layers if you don't need USB) and build a computing device that would otherwise be out of reach.
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.
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+.
That's pretty cool! So you could have any type of hardware (nas, speakers, whatever... and simply upgrade the computer-part (the CM) if you'd need more power, network or whatever.
There's a kernel module called piControl (source code is on GitHub) which periodically polls the I/O modules. The values written to the outputs are taken from a memory area called the "process image". Values read from inputs are stored in that same memory area. User space accesses the memory area via regular open/read/write/close system calls. Plus there's a bunch of ioctls to perform special actions such as firmware updates on the I/O modules.
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/
What is the purpose of the Ethernet/IP and Modbus TCP I/O Cards? You can already access E/IP and Modbus TCP from Node-red or python with a standard Raspberry Pi.
True. However these modular gateways are ODVA-certified and have gone through all the mandatory testing (surge/burst, shaker, climate chamber), so they might be the preferred solution in environments where certified devices are required, be it only for compliance reasons.
The spec limits ambient temperature to -44–55°C. As the low temperate range of the regular Pis was the major limiting factor for use in industrial applications (0–50), is there some module that goes further? Think of devices deployed in a street cabinet in summer heat f.ex., those have to endure much higher temps.
We use the Raspberry Pi Compute Module, not the regular Raspberry Pi. The Compute Module is basically a SO-DIMM slot with the BCM2835 or BCM2837 SoC plus eMMC and LP-DDR2 RAM. The Compute Module is spec'ed at -25 to 80°C, versus 0 to 50°C on the regular Raspberry 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:
You mean the watchdog integrated into the BCM2835? That's a good question, we haven't tested that yet, but I've added it to the todo list now.
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.
I've been searching for RPi's in this formfactor and with protected I/O for a while. Besides your product I found some others but all suffer from the same drawback (for me at least), which is the price. I can understand there is some extra cost involved in the certification of these devices, eMMC and such. Most industry customers will probably find the price resonable even. But for me as hobbyist I can't justify it to myself if I could buy a handful of 'normal' pi's instead (solving the DIN mounting problem using zip ties).
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?
I could see them potentially selling just the bare motherboard to hobbyists in non certified form.
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.
I'm just a kernel dev, not a product manager, but I think a sub $100 product is very unlikely I'm afraid. There are volume discounts though for customers ordering large quantities. Otherwise Accujack's answer is spot on.
Just out of curiousity, did you look at the real-time HAL included with LinuxCNC at all? There have been attempts to make that code into a dedicated PLC system now and again.
What real time extensions did you use with the Raspbian kernel?
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.:
Hi, I'm a controls engineer at a small industrial automation integrator and will be picking one of these up for playing with. I've placed a couple Raspberry Pis running the DietPi kernel and dozens of OnLogic Windows fanless PCs in control panels, and if these do what they say on the box I think this will be highly competitive!
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:
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.
DVI-D has the exact same TDMS signals as HDMI, it just adds optional analog signals (to implement the full DVI-I interface) and drops the CEC remote control interface. I understand the difficulty with keeping the device small!
> 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...
IMHO what is needed:
- redundancy solution for both between the units and in the redundant I/O paths (Google Byzantine Generals problem)
- separate diagnostics interface like in Dell (iDRAC) or HP (iLO) servers have. Control data path should not be used for diagnostics data.
- Clock sync between the units using common GPS master clock
- Network boot with possibility to diagnose it thru serial console.
- Profinet support
- Lisp interface for internal system diagnostics using AI.
15 years ago I would love to have had a product like this when working mechanical maintenance in a machine shop but Jesus Christ the price alone is ridiculous. $360!?! some shops have hundreds of machines.
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.
If the modules work as claimed, then $360 a pop is fairly cheap. Real world PLC units capable of extensible digital and analog I/O, networked, usually cost anywhere from $1000 - $10,000 per unit.
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.
I don't think that most customers will use these to replace their PLC. There's just too much at stake. These are more likely to be used as 'glue logic' between the PLC and unusual devices that need custom software or only have PC-based interfaces.
For most PLC customers this is a no-go. They aren't in the market to save money on hardware. They save money by reducing downtime and eliminating failures. Without certifications for industrial control protocols (which take years and lots of engineering time to get passed), these will only be useful for those who don't really need a PLC.
I've been working as a controls engineer at integration shops for close to a decade, and had the exact OPPOSITE reaction. The price is ridiculously cheap!
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.
How's the Compute Module with temperature?
We've had trouble keeping Raspberry PIs (3 not 4) stable in industrial settings because they overheated (no, they weren't doing anything critical so we just configured them to reboot every couple hours).
I see something about a passive heat sink, I wonder if that's enough...
The big advantage this has isn't its temperature range or price, it's the form factor and power supply. Pluggable screw terminals for the industrial 24V power supply and a professional case with a DIN rail bracket make this a much easier sell than a bare singleboard computer. In units of 1, you'd trivially burn through the hour of engineering time that represents the price difference while setting up a case, mounting hardware, and accessories for a Beaglebone Black.
Raspberry Pi was all about the price, hence the success vs. Arduino. Checking the prices on site for these...and cheapest is above 100 Euro? Not a chance in hell.
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.
I can see a niche for these units in some IoT and small/simple control applications. But they are close enough in price to Beckhoff's ARM-based industrial PC / PLC's that I would tend towards Beckhoff for pretty much anything I wanted to do (especially now that Beckhoff offers FreeBSD instead of windows embedded). Note that Beckhoff offers both a hard-real-time PLC and a soft-realtime general computing environment on their PLC's. You can program the PLC side in standard PLC languages or C/C++ (with some limits on available syntax). On the soft-real-time side, you can pick any programming approach you want (C/C++/C#/Python/MATLAB/Labview/Elixir/TS or JS, etc.) and communicate to the hard-real-time side via a variety of options.
Ah, so Beckhoff finally got around to add another OS besides Windows. They teased us with promises of Linux support for a while, but it took them too long and we already had experience with NI cRIOs so we just used that for our project.
What kind of of pricing are you getting on these (and what base model CX unit did you select) that they're 'close enough'?
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.
Unfortunately, I don't have current detailed pricing for Beckhoff's lowest end. I, too, wish they would just publish pricing. IIRC, low end beckoff arm controllers do get down to 400-500 USD. A CX9020 1GHz A8 based unit, with win embedded compact edition runs about 1000 USD with the runtime. As I understand it, this is the lowest end unit system for basic multi-axis motion control. Keep in mind that this is actually a lot of computational horsepower. When beckhoff says "basic" that means mid range for most other PLC's.
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.
Q: What is the Beckhoff "variety of options" for communicating to the hard real-time side from (userspace?) soft-real-time side? As far as I know, all communication goes through ADS which is handled between cycles and isn't guaranteed to be even close to soft-real-time if the PC is busy. I'm genuinely interested if I'm missing a communication path here... I leveraged R3IO in TwinCAT2 to externally clock data into the task images from userspace for "soft-real-time" approx 10ms cycles , but TwinCAT3 droppped that option... My experiments and working with Beckhoff resources showed that ADS can't make that cyclic guarantee. (soft-real-time motion control application running in user-space)
Beckhoff now also offers a direct TCP/IP socket interface (for extra money, of course) if ADS doesn't cut it for you application.
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.
I don’t know anything about electronics, but I would like it if the replacement cost for home appliance control boards wasn’t $300. Making it a cheap interchangeable part would really cut down on waste.
73 comments
[ 4.5 ms ] story [ 169 ms ] threadCustomers 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.
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.
True hard real time is great, but not actually necessary for a lot of automation applications.
The patches are adding higher nice values, and trying to remove some of the egregious kernel contention.
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.
https://www.kiwi-electronics.nl/din-rail-raspberry-pi-behuiz...
I guess I'm not sure what you mean by the word 'kit'
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.
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+.
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
https://www.balena.io/fin/
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).
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...
https://youtu.be/4iaInDiEiQg?t=338
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.
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.
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...
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.
Hm? Most machining tools cost $100,000 to >$1,000,000. Why would a DIN bank of $360 control modules bust the budget?
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.
I see something about a passive heat sink, I wonder if that's enough...
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.
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.
But appliance manufacturers aren't interested.