Strato Pi – An Industrial Raspberry Pi(sferalabs.cc)
sferalabs.cc
Strato Pi – An Industrial Raspberry Pi
https://www.sferalabs.cc/strato-pi/
80 comments
I've been testing this one from Balena (formerly Resin)
https://www.balena.io/fin/
It's a carrier for the Raspberry Pi compute module. Solves many of the problems it has in an industrial environment. It takes 6-24vdc, has real eMMC storage, an RTC, a hardware coprocessor that can be used as a watchdog and an mPCIE. I think there's a DIN case for it as well.
All that for a bit over a hundred dollars plus the $40 for the compute module. That seems pretty decent at that price. The next step up seems to be a "cheap" x86 IPC at a few hundred dollars.
https://www.balena.io/fin/
It's a carrier for the Raspberry Pi compute module. Solves many of the problems it has in an industrial environment. It takes 6-24vdc, has real eMMC storage, an RTC, a hardware coprocessor that can be used as a watchdog and an mPCIE. I think there's a DIN case for it as well.
All that for a bit over a hundred dollars plus the $40 for the compute module. That seems pretty decent at that price. The next step up seems to be a "cheap" x86 IPC at a few hundred dollars.
I've had numerous failures on older RPi models due to SD card corruption, even in non-write intensive contexts. Not sure this is good enough when you want reliability...
Thats a well known issue with standard distributions, and there are fairly well known ways around it...
Basically, don't do continuous writing to the card, turn off atime updates,possibly even work entirely from the initrd if possible. Also, use proper industrial sd cards, these have proper wear-levelling and bad-block management unlike the consumer cards.
In other words, treat it as an embedded system and tailor it to your use-case.
Basically, don't do continuous writing to the card, turn off atime updates,possibly even work entirely from the initrd if possible. Also, use proper industrial sd cards, these have proper wear-levelling and bad-block management unlike the consumer cards.
In other words, treat it as an embedded system and tailor it to your use-case.
I've tried all these "ways around it", but SD card corruption still happens on Raspberry Pi's. We use them as dashboards around the office so having them running 24/7 really tests these devices.
I've found that the only working recipe for a stable Raspberry Pi is a USB hard drive (prefer SSD but mechanical also fine), and a UPS.
My simple advice is: do not try to run Raspberry Pi from SD cards in "production" under any circumstances on a large scale, as you will run into filesystem corruption and create a lot of work for yourself.
I've found that the only working recipe for a stable Raspberry Pi is a USB hard drive (prefer SSD but mechanical also fine), and a UPS.
My simple advice is: do not try to run Raspberry Pi from SD cards in "production" under any circumstances on a large scale, as you will run into filesystem corruption and create a lot of work for yourself.
> do not try to run Raspberry Pi from SD cards in "production" under any circumstances on a large scale
Can't confirm. I've written about this before, but I'm mainly responsible for running the https://info-beamer.com digital signage service. It's using a custom Linux distribution that always boots into an R/O system. All user content is on a separate partition that can always be restored if there's any error. The ext4 fs is tuned in a way that the kernel defers writes quite a while to minimize write access if possible. Since customers purchase their own SD cards, we have limited control of what ends up in a device. I've seen exactly one SD card related problem thus far. There are devices that have been running >3 years 24/7, so it's doable. But you can't just use Raspbian. You have to properly design the system.
Can't confirm. I've written about this before, but I'm mainly responsible for running the https://info-beamer.com digital signage service. It's using a custom Linux distribution that always boots into an R/O system. All user content is on a separate partition that can always be restored if there's any error. The ext4 fs is tuned in a way that the kernel defers writes quite a while to minimize write access if possible. Since customers purchase their own SD cards, we have limited control of what ends up in a device. I've seen exactly one SD card related problem thus far. There are devices that have been running >3 years 24/7, so it's doable. But you can't just use Raspbian. You have to properly design the system.
Thanks - that does give me hope.
I agree, which is why in a properly designed system you would run from initrd, its a single purpose system after all.
No need for any sd card access once the image has been read into RAM. The SD card is read-only in this case.
Also, I wouldnt trust consumer sd cards at all, they typically lack to necessary features to store data reliably anyway.
Or just make your root file system read-only. Running off an initrd greatly limits your filesystem size.
Would TinyCore be a good option for us? We just need to run RPi's and Chromium to display a web page.
Not familiar with TinyCore myself, but I’d recommend trying Nerves Kiosk if a webpage kiosk is your primary goal [1]. Getting all of the FS settings right and a tuned system like daviduum talks about is tricky IMHO. Though it should be possible with Yocto Linux or similar as well I’d imagine, especially with ‘fwup’ or similar in the loop. Nerves uses ‘fwup’ [2] to create a R/O squashfs filesystem for the core OS image which is also highly compressed.
1: https://github.com/LeToteTeam/kiosk_system_rpi3/blob/master/... 2: https://github.com/fhunleth/fwup
1: https://github.com/LeToteTeam/kiosk_system_rpi3/blob/master/... 2: https://github.com/fhunleth/fwup
"My simple advice is: do not try to run Raspberry Pi from SD cards in "production" under any circumstances on a large scale, as you will run into filesystem corruption and create a lot of work for yourself."
Is that true even if you mount the filesystem(s) read-only after boot time ?
As an aside, I have to say that it is very surprising and annoying how fragile "modern" drive parts are compared to decades ago when we were using either disk-on-chip or just plain old CF cards pin-compatible with the IDE connector.
I had 16MB CF cards on the IDE bus that lasted 15+ years[1] in production without a hiccup, but in 2018 SATA SSDs die randomly from time to time ...
[1] Yes, they were all mounted read-only ...
Is that true even if you mount the filesystem(s) read-only after boot time ?
As an aside, I have to say that it is very surprising and annoying how fragile "modern" drive parts are compared to decades ago when we were using either disk-on-chip or just plain old CF cards pin-compatible with the IDE connector.
I had 16MB CF cards on the IDE bus that lasted 15+ years[1] in production without a hiccup, but in 2018 SATA SSDs die randomly from time to time ...
[1] Yes, they were all mounted read-only ...
> Is that true even if you mount the filesystem(s) read-only after boot time ?
Yes, read-only filesystems are not the solution to most of the Micro SD card problems on the Pi, because the filesystem and the OS are relying on the card to work properly, and the actual consumer market Micro SD cards people are using don't always do that when used in the Pi.
To manage the flash, the (dirt cheap, barely fit for purpose) controller inside a consumer Micro SD card will generally do things like move data from one area of flash to another, even when the host isn't writing to the card.
One of the reasons for that, is that reading from NAND is a potentially disruptive[1] event:
> If reading continually from one cell, that cell will not fail but rather one of the surrounding cells on a subsequent read. To avoid the read disturb problem the flash controller will typically count the total number of reads to a block since the last erase. When the count exceeds a target limit, the affected block is copied over to a new block, erased, then released to the block pool.
There are industrial Micro SD cards that can handle most of the problems that show up on the Pi though, and they aren't absurdly expensive. The $15 ATP AF4-GUD3A and $28 ATP AF8-GUD3A are some I use in my Pi projects for this reason, and I've never seen any of them become corrupt, unlike SanDisk and other consumer cards.
[1] https://en.wikipedia.org/wiki/Flash_memory#Read_disturb
Yes, read-only filesystems are not the solution to most of the Micro SD card problems on the Pi, because the filesystem and the OS are relying on the card to work properly, and the actual consumer market Micro SD cards people are using don't always do that when used in the Pi.
To manage the flash, the (dirt cheap, barely fit for purpose) controller inside a consumer Micro SD card will generally do things like move data from one area of flash to another, even when the host isn't writing to the card.
One of the reasons for that, is that reading from NAND is a potentially disruptive[1] event:
> If reading continually from one cell, that cell will not fail but rather one of the surrounding cells on a subsequent read. To avoid the read disturb problem the flash controller will typically count the total number of reads to a block since the last erase. When the count exceeds a target limit, the affected block is copied over to a new block, erased, then released to the block pool.
There are industrial Micro SD cards that can handle most of the problems that show up on the Pi though, and they aren't absurdly expensive. The $15 ATP AF4-GUD3A and $28 ATP AF8-GUD3A are some I use in my Pi projects for this reason, and I've never seen any of them become corrupt, unlike SanDisk and other consumer cards.
[1] https://en.wikipedia.org/wiki/Flash_memory#Read_disturb
> As an aside, I have to say that it is very surprising and annoying how fragile "modern" drive parts are compared to decades ago
Those old parts used SLC (single bit per cell) flash, which has orders of magnitude higher endurance than whats used now, MLC or TLC (2 and 3 bits per cell). QLC (4 bit per cell) is starting to hit the market now.
Those old parts used SLC (single bit per cell) flash, which has orders of magnitude higher endurance than whats used now, MLC or TLC (2 and 3 bits per cell). QLC (4 bit per cell) is starting to hit the market now.
You can network boot them too, which is way more convinient. RPi3 can do it natively, the former ones need an SD card, but since it's only for the bootloader, it'll survive much longer.
Last time I read about this [1], the firmware had some issues that prevented the boot process from working 100% reliable. Do you have any experience with network booting the RPi?
[1] https://github.com/raspberrypi/firmware/issues/764
[1] https://github.com/raspberrypi/firmware/issues/764
Yes, but I only have 2 devices that network boot. One is with PoE, one without. Both work fine, but I don't have the need to reboot them every other day and the network is not a complex structure. Filesystem is with NFS.
I use raspberry pi as a display around a mid sized company. Out of 12 setups, I have to resurrect 2-3 every year due to ssd corruption.
Are these using UPS or just directly on power? At our office, power goes off about once or twice a month when someone is working on the electrical system. We've had lots of building work done, and it's definitely not been good on the Pi's - that being until we added UPS's.
Can I ask what industrial sd cards did you try? I was going to try one of those out but I'd like to know what to avoid. Thanks.
If you want reliability, buy SLC SD cards. 'SLC' keyword is much more important than the brand. There are a few companies that make them, for example Panasonic or Swissbit.
Good point. To elaborate, SLC means Single-Level, Cell, NAND Flash that's both simpler and longer-lasting:
https://en.wikipedia.org/wiki/Multi-level_cell#Single-level_...
Example suppliers:
https://www.micron.com/products/nand-flash/slc-nand
https://www.cactus-tech.com/resources/blog/details/why-slc-s...
http://www.macronix.com/en-us/products/NAND-Flash/SLC-NAND-F...
https://business.toshiba-memory.com/en-us/product/memory/slc...
https://en.wikipedia.org/wiki/Multi-level_cell#Single-level_...
Example suppliers:
https://www.micron.com/products/nand-flash/slc-nand
https://www.cactus-tech.com/resources/blog/details/why-slc-s...
http://www.macronix.com/en-us/products/NAND-Flash/SLC-NAND-F...
https://business.toshiba-memory.com/en-us/product/memory/slc...
We primarily used class 10 consumer cards including Kingston, Sandisk, Samsung etc. We also tried ATP which is sold as an industrial SD card. More info: https://www.atpinc.com/products/industrial-sd-cards
are there ssd or winchester drives that can plug into the sd card slot? Of course, the drive would need an additional power supply.
Or maybe this is just over-engineered, and maybe someone makes a pi that uses an SSD by default.
Or maybe this is just over-engineered, and maybe someone makes a pi that uses an SSD by default.
Not sure about the SD card slot, but the recent Pi’s can boot from a hard drive attached to a USB port.
Not to downplay the idea that pi's fs in unreliable, but there's another player here which is the SD card. Many SD cards are way less reliable than the imaginary R/W spec given by manufacturers, and there's a crazy amount of grey matter and counterfeiting.
atime refers to timestamping of files with their access time right?
That sounds interesting re. turning off atime updates, how do you do that out of interest?
That sounds interesting re. turning off atime updates, how do you do that out of interest?
> how do you do that out of interest?
Mount with -o noatime. The default (-o relatime) should however be good enough for most situations.
Mount with -o noatime. The default (-o relatime) should however be good enough for most situations.
noatime mount option
I'm pretty sure my Pi failures where due to weak power supplies. I tried running a Raspberry Pi 1 B on a 1 A power supply, and after a few months it wouldn't boot. Since then I've switched to a bigger SD card (16 GB) for better wear leveling, and a 2,5 A power supply and haven't had any issues yet.
It's often a combination of the power supply and the type of SD cards, but eventually you will have a failure no matter what SD card you use. I've learned this the hard way from running dozens of Pi's 24/7. Looking back, I regret the decision to use Raspberry Pi. See my comment below.
I can see specific usage of these but probably not large scale usage. Industrial things need to work 100% of the time and has to easily talk to other devices reliably usually in the form of some redudant network. It'll be pretty hard to convince engineers to use these on industrial equipment. The early 2010s were extremely lack luster for industrial electronics technological advancement. Everything you used were ancient (development of them started probably before I was born). But the mass adoption of Ethernet/ethercat have been speeding things up.
As an example of how we might consider using these:
We work on a lot of short-lived one-off experimental projects, and we currently use B&R industrial controllers for more or less everything. However, these use a clunky Windows-only development environment and can only be programmed in C/C++. For some projects - e.g. putting a data logger in a low voltage electrical cabinet, which interfaces to some gear using serial/modbus/CAN and analog/digital I/O and uploads the results to the cloud - this could potentially be quite useful. We don't often work on safety-critical systems, or require 5-nines uptime.
The only thing is that this system isn't that cheap compared to B&R gear, although not having to pay a subscription for the dev environment helps.
We work on a lot of short-lived one-off experimental projects, and we currently use B&R industrial controllers for more or less everything. However, these use a clunky Windows-only development environment and can only be programmed in C/C++. For some projects - e.g. putting a data logger in a low voltage electrical cabinet, which interfaces to some gear using serial/modbus/CAN and analog/digital I/O and uploads the results to the cloud - this could potentially be quite useful. We don't often work on safety-critical systems, or require 5-nines uptime.
The only thing is that this system isn't that cheap compared to B&R gear, although not having to pay a subscription for the dev environment helps.
A feature I didn't see anywhere is the ability to start the PI at a given time or after receiving a wake on LAN packet. This would be useful in several scenarios like performing some task, shutdown and boot again later, maybe at a time programmed by the PI itself.
a RPI uses so little power that it makes no sense to do wake-on-lan, and indeed the RPI doesn't support wake on lan at all. Just leave it on and idle.
The other day I saw someone commenting on aMLC SD cards and their increased tolerance to sudden power loss and generally rougher conditions. Can’t find it, though. Anyone have a link?
I wrote about this in the past various times. For example here [1]. I learned about it from HN as well though.
[1] https://news.ycombinator.com/item?id=18275494
[1] https://news.ycombinator.com/item?id=18275494
I've been using the PLCs from UniPi [0] for a few months. They started with Raspberry-Pi-based systems but now have a Allwinner-H5-based system with built in memory. They have a significant number of digital and analog ports, depending on the model, and work with a number of different programming solutions.
[0] https://www.unipi.technology/
[0] https://www.unipi.technology/
These customised Pi packages are hit and miss indeed but you can very often find a pretty neat plug-and-play solution for your particular problem that saves you time, so paying $150 instead of $75 is great ROI for your business.
Cool but is there something similar yet less expensive for not-really-industrial usage? Built-in UPS and hardware watchdog seem really valuable for almost everybody.
Could this be used for space projects, like satellites? (Thinking about the name)
The rPi chip itself is not rad-hardened, so it'd require a bulky shielding, that'd increase the launch mass, which is a lot more expensive than a more space suited chip. Also, launching into space requires a lot better electronics. Sure, it'd work likely, but .. when a launch is that expensive, you wouldn't accept these risks.
> Hardware watchdog
I thought the broadcom chip provided a hw watchdog that's integrated directly into the linux kernel?
I thought the broadcom chip provided a hw watchdog that's integrated directly into the linux kernel?
Its usual for an external watchdog to be added for industrial applications that cannot be disable ( or fail to be enabled) by firmware/software.
Oh wow, thanks. I'm using rpis in my home automation and never knew about it. I've been using micros (mostly arduino) as watchdogs. This sounds so much better.
It's nice to see more options becoming available in this space. Industrial PCs (and, in the same vein, PLCs) from the old-guard industrial automation providers are generally lackluster for the cost, in my experience. So many acts of industrial automation and robotic system integration can be achieved with a Raspberry Pi and/or an Arduino, with a little hardening.
I know I'm not the target market for their UPS addon, but is 91.00€ for a UPS board [1] that does not include the required lead-acid battery sound reasonable? I know they have gone through the certification process for everything, but doesn't this seem fairly high?
The battery is not lithium, but lead-acid. For an application using a Raspberry Pi, I generally assume size is a fairly major consideration. Considering a lead acid battery will need to be three times the size for similar charge capacity, doesn't this battery chemistry choice seem very strange?
A quick google brought me to the PiJuice HAT [2], a $54 piHAT, with an included 1820mAH LiPo. This device also doesn't massively increase the size of the Pi. PiJuice claims "~4 to 6 hours in constant use". Let us assume this is a vastly inflated figure designed by the marketing department. Isn't 2 hours run time more than enough for a UPS? If the power failure is longer, I want my UPS to allow me to safely shut down my gear.
1: https://www.sferalabs.cc/product/strato-pi-ups-board/ 2: https://ameridroid.com/products/pijuice-hat-1
The battery is not lithium, but lead-acid. For an application using a Raspberry Pi, I generally assume size is a fairly major consideration. Considering a lead acid battery will need to be three times the size for similar charge capacity, doesn't this battery chemistry choice seem very strange?
A quick google brought me to the PiJuice HAT [2], a $54 piHAT, with an included 1820mAH LiPo. This device also doesn't massively increase the size of the Pi. PiJuice claims "~4 to 6 hours in constant use". Let us assume this is a vastly inflated figure designed by the marketing department. Isn't 2 hours run time more than enough for a UPS? If the power failure is longer, I want my UPS to allow me to safely shut down my gear.
1: https://www.sferalabs.cc/product/strato-pi-ups-board/ 2: https://ameridroid.com/products/pijuice-hat-1
LiPo is a really terrible choice for a UPS; it'll wear out quite quickly. LiFo is way better, like this: https://www.crowdsupply.com/silicognition/lifepo4wered-pi-pl...
LiFePO4 is also much more fire resistant due to punctures, shocks and overcharging, which is also good for an industrial setting.
Litium battery backup and UPS is two different things.
Lead batteries are cheap.
And reliable, and they're OK with being cycled frequently. Their failure mode also doesn't include the words "chemical fire".
They actually aren't good at being cycled if you go further than about 50% discharge, less than 10. Otherwise it gets 500 cycles. Lithium Ion also gets 500 cycles, but can go up to 2000 cycles if you stay between 10% and 90%.
True. But you usually don't cycle UPS batteries that much. If you do you probably have bigger problems with your power supply. There are some cycle lead batteries though, sometimes called "solar batteries".
It is awesome to see battery backup being added to the Pi. There aren't any good solutions currently short of a full on UPS or a consumer grade battery pack.
Well given that the raspberry is decidedly consumer grade too I don't see an issue with running it off a name brand powerbank.
AdaFruit's "Powerboost 1000 charger" is not cheap but it's very good and also has USB power pass-through pin, in order to detect power failures. However you will need a 5V-3.3V level converter to feed it to the RPi's GPIO pins.
I got some clones of these made in China to save money. All in all, pretty happy. Although they really need a heatsink if you want to push 1A continuously, and the IC is so small it is hard to dissipate all that heat. One of them will push as much current as possible until it overheats and shuts off, but the rest seem fine.
I plan on trying to use 2 in parallel to make a UPS for my pi.
I've used one with good results on a low power IoT door unlocker. When the door is closed, a Qi charger make contact and powers the device. When the door is open, it runs off battery.
I plan on trying to use 2 in parallel to make a UPS for my pi.
I've used one with good results on a low power IoT door unlocker. When the door is closed, a Qi charger make contact and powers the device. When the door is open, it runs off battery.
Another option worth considering is the Modberry: https://modberry.techbase.eu/
Login just to see the prices? Classy!
Well, we ended up quoting a custom build with them, and it was slightly cheaper than the Strato Pi. I agree that pricing information for standard configurations should be available.
Indeed. WTF?
Ive worked in industrial manufacturing before, and I presently work as an engine mechanic in a small chain of midwestern diesel repair stores. I use regular raspberry pi's to pull data from ECU/OBD systems, and I even store that data on a PI server as part of a customers work ticket data.
the problem with anything thats 'industrialized' is that so many companies use this as a chance to gin up the price and double down on rent-seeking behavior. This thing takes a $45 pi and jacks the price up to $250USD. Some of the goofier features include:
- on-board buzzer. You know, because over the constant din of lathe, shave, and heat treat assembly line systems you're surely going to pay attention to the buzzer from something the size of a pack of smokes. anything essential should be shown on the light tower or picked up by QA.
- standard RS-232 and RS-485 interfaces to the Raspberry Pi serial line, with opto-isolator and electrostatic discharge protection: Motoman, Fanuc, Mitsubishi, and almost every other automation hardware have used cat5 for a decade. doesnt the pi have grounded cat5?
CAN network support - god no. This jumps into the realm of medical systems, elevator controls, and passenger vehicles. all of these are made of intrinsically isolated circuits and go through some of the most rigorous testing imaginable. For example, RF leakage common in a PI could cause aberrant failures or signaling problems in robotics that arent expecting it. CAN type controllers can withstand shock/heat/humidity many times that of what a normal computer can handle. Introducing the PI as a CAN device is asking for grievous bodily harm as a service.
the problem with anything thats 'industrialized' is that so many companies use this as a chance to gin up the price and double down on rent-seeking behavior. This thing takes a $45 pi and jacks the price up to $250USD. Some of the goofier features include:
- on-board buzzer. You know, because over the constant din of lathe, shave, and heat treat assembly line systems you're surely going to pay attention to the buzzer from something the size of a pack of smokes. anything essential should be shown on the light tower or picked up by QA.
- standard RS-232 and RS-485 interfaces to the Raspberry Pi serial line, with opto-isolator and electrostatic discharge protection: Motoman, Fanuc, Mitsubishi, and almost every other automation hardware have used cat5 for a decade. doesnt the pi have grounded cat5?
CAN network support - god no. This jumps into the realm of medical systems, elevator controls, and passenger vehicles. all of these are made of intrinsically isolated circuits and go through some of the most rigorous testing imaginable. For example, RF leakage common in a PI could cause aberrant failures or signaling problems in robotics that arent expecting it. CAN type controllers can withstand shock/heat/humidity many times that of what a normal computer can handle. Introducing the PI as a CAN device is asking for grievous bodily harm as a service.
On the pricing front. I've designed systems which use the RPi as a base and are sold for several hundred pounds (spectrometers).
The reason is basically margin and not going out of business. If you want to make any money, you need to sell at around 3x your BOM cost to compensate for distribution, optional sales events, labour, amortised certification costs and so on.
Working backwards, $250 means about $85 in parts. A custom printed DIN rail case probably costs $15-20 in small volume, the Pi is $45 and that only leaves $20 or so for the PCB and components which seems easy enough if they've over-specced it for industry. I wouldn't be surprised if this thing costs $100 to build; not including labour, packaging and shipping.
This is a classic "I'm an engineer and could build this for 1/3 the price" - sure you could. But you couldn't sell it that cheaply and make a business out of it.
The reason is basically margin and not going out of business. If you want to make any money, you need to sell at around 3x your BOM cost to compensate for distribution, optional sales events, labour, amortised certification costs and so on.
Working backwards, $250 means about $85 in parts. A custom printed DIN rail case probably costs $15-20 in small volume, the Pi is $45 and that only leaves $20 or so for the PCB and components which seems easy enough if they've over-specced it for industry. I wouldn't be surprised if this thing costs $100 to build; not including labour, packaging and shipping.
This is a classic "I'm an engineer and could build this for 1/3 the price" - sure you could. But you couldn't sell it that cheaply and make a business out of it.
Doesn't sound like he's saying that. Sounds like he is saying the $35 model will work just fine. And it is already proven and produced on a mass scale.
This is an extension kit to a well designed and well adopted embedded system. The OPs complaints to me read as: nobody wants these features because the stock model works for OP, and that the price was jacked up to cater to an industrial market. I addressed the second point above - to stay in business, hardware costs money.
On the first point, the product definitely provides benefits over the stock Pi. If you need those improvements, you need them. The $35 model will die if you plug in a logic level that isn't 3V3. It certainly won't handle standard RS-232. It doesn't have a proper power jack - either USB Micro or two GPIO pins (no latching). It also doesn't come with a DIN rail mounting system, nor an RTC, nor a UPS, nor a good voltage regulator. Some people might want those features (I've worked jobs where they would have been useful.)
Also on the buzzer front - not all DIN boxes are in factories. They're used inside buildings for power distribution and fuses, in greenhouses to control irrigation systems. These aren't necessarily noisy environments.
On the first point, the product definitely provides benefits over the stock Pi. If you need those improvements, you need them. The $35 model will die if you plug in a logic level that isn't 3V3. It certainly won't handle standard RS-232. It doesn't have a proper power jack - either USB Micro or two GPIO pins (no latching). It also doesn't come with a DIN rail mounting system, nor an RTC, nor a UPS, nor a good voltage regulator. Some people might want those features (I've worked jobs where they would have been useful.)
Also on the buzzer front - not all DIN boxes are in factories. They're used inside buildings for power distribution and fuses, in greenhouses to control irrigation systems. These aren't necessarily noisy environments.
Those industrial Pis offer things that are absoklutely important to many industrial users. Maybe not for you, but they have their market: DIN rail mounting, I/O modules, ESD/EMI lab results, conformance to electrical standards etc. pp.
Another one, probably better known is the Revolution Pi (https://revolution.kunbus.de).
Another one, probably better known is the Revolution Pi (https://revolution.kunbus.de).
"CAN network support - god no. This jumps into the realm of medical systems, elevator controls, and passenger vehicles."
When I see "CAN network support" I am not thinking of controlling those systems, but rather, having the ability to read those systems ... or in the case of a device like a VAG-COM, being able to set new values, etc.
I agree that I would not want amateur tie-ins to critical safety systems like elevators and bridges.
When I see "CAN network support" I am not thinking of controlling those systems, but rather, having the ability to read those systems ... or in the case of a device like a VAG-COM, being able to set new values, etc.
I agree that I would not want amateur tie-ins to critical safety systems like elevators and bridges.
... just wait for the first dude sniffing in active mode by forgetting to set the passive flag. The can controller will then not actively compose messages but will set the ACK bit... God knows what might happen by a third party ACK'ing on the bus ;)
I design electronics which uses CAN internally. This would be super useful to put in a test jig.
I fully appreciate the applications you listed as rendering the pi insufficient.
I can however see potential use cases in industrial film and television lighting where controllers were often 100% proprietary and vastly more expensive and you’d generally have a large array of them on large productions.
This isn’t a life or death scenario and these are cheap enough to have a spare or two on hand that could likely be compiled and written inside of an hour or two and connected within minutes.
And as another user mentioned, brings the units up to electrical safety standards in such environments.
It wasn’t my field so I don’t know for sure, but it seems like it could be useful.
I can however see potential use cases in industrial film and television lighting where controllers were often 100% proprietary and vastly more expensive and you’d generally have a large array of them on large productions.
This isn’t a life or death scenario and these are cheap enough to have a spare or two on hand that could likely be compiled and written inside of an hour or two and connected within minutes.
And as another user mentioned, brings the units up to electrical safety standards in such environments.
It wasn’t my field so I don’t know for sure, but it seems like it could be useful.
>> CAN network support - god no. This jumps into the realm of medical systems, elevator controls, and passenger vehicles.
In the auto industry nobody is going to use this as a component on a car. We will use it for software development to communicate with a module in development. Someone may use it in end of line test equipment. For those purposes $250 is rather cheap. I was hoping it would have a LIN interface, but oh well.
Speaking of LIN, has anyone used the sllin driver on the RPi?
https://github.com/trainman419/linux-lin/tree/master/sllin
In the auto industry nobody is going to use this as a component on a car. We will use it for software development to communicate with a module in development. Someone may use it in end of line test equipment. For those purposes $250 is rather cheap. I was hoping it would have a LIN interface, but oh well.
Speaking of LIN, has anyone used the sllin driver on the RPi?
https://github.com/trainman419/linux-lin/tree/master/sllin
The carino has a LIN bus: http://carino.io/
>> the problem with anything thats 'industrialized' is that so many companies use this as a chance to gin up the price and double down on rent-seeking behavior. This thing takes a $45 pi and jacks the price up to $250USD.
Fair point, but is it really a "problem"? Think of it from the opposite side. A market for this markup exists. It is an opportunity for people like you, that understand well both, a particular (non computer) domain and computing that is needed to support it.
I bet many "diesel repair stores" would need what you already accomplished with your regular raspberry pi's custom applications. And won't mind to get it packaged with an useful hardware and software for whatever markup you deem fair. They will be glad to pay for what you already thought and successfully incorporated in your application, wouldn't they?
It is HN after all. :-)
Fair point, but is it really a "problem"? Think of it from the opposite side. A market for this markup exists. It is an opportunity for people like you, that understand well both, a particular (non computer) domain and computing that is needed to support it.
I bet many "diesel repair stores" would need what you already accomplished with your regular raspberry pi's custom applications. And won't mind to get it packaged with an useful hardware and software for whatever markup you deem fair. They will be glad to pay for what you already thought and successfully incorporated in your application, wouldn't they?
It is HN after all. :-)
Both CAN bus and RS-232 still are very common interfaces in industrial manufacturing. It makes perfect sense to provide them as it makes piecewise upgrades of machinery possible.
As a counter-example for RS-485, my solar roof's data logger consists of an RS-485 to USB converter, a Raspberry Pi and some solid-state relays. They even used the standard Raspberry Pi power supply, but they cut off the micro-USB and use screw terminals connected to the Pi's GPIO (probably so that customers do not have the temptation to swap it with a random phone charger they bought on eBay).
As a counterexample, we used a CAN interface on a battery charger to get various metrics about the battery. Not all CAN usage is safety critical.
I’d think using flash memory for the file system on an industrial controller is another big problem. I had nothing but crashes with an RPI due to filesytem issues. Flash memory was intended for bulk R/W, not random access.
Other single board computers or system on module offer 10 year production lifetimes from introduction, e.g Variscite. This is possible as the manufacturer of the SoC (generally NXP or TI) also gauruntee to produce the silicon for 10 years, and as (unlike Broadcom) they will sell to anyone, alternative boards are available with the same processor should one board manufacturer go bust. They are a bit more expensive, but a trivial percent of the overall cost for an industrial application, and the difference isn't that much once you add a case, protection, industrial power supply etc.
1. https://www.raspberrypi.org/forums/viewtopic.php?t=193995.