Strato Pi – An Industrial Raspberry Pi
sferalabs.cc
sferalabs.cc
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.
Another one, probably better known is the Revolution Pi (https://revolution.kunbus.de).
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.
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.
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?
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.
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.
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. :-)
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.
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.
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.
That sounds interesting re. turning off atime updates, how do you do that out of interest?
Mount with -o noatime. The default (-o relatime) should however be good enough for most situations.
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.
1: https://github.com/LeToteTeam/kiosk_system_rpi3/blob/master/... 2: https://github.com/fhunleth/fwup
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...
Or maybe this is just over-engineered, and maybe someone makes a pi that uses an SSD by default.
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 ...
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.
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.
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.
I thought the broadcom chip provided a hw watchdog that's integrated directly into the linux kernel?
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
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.
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.