Revolution Pi – Industrial PC Based on Raspberry Pi | Hacker News Reader

Revolution Pi – Industrial PC Based on Raspberry Pi

revolution.kunbus.com

127 pointsTomte73 comments

How industrial are we talking? Is it certified for use in industrial environments? I saw a few mentions of IEC61131-2, but I couldn't find whether it actually has certifications.

If it is suitable for use in the industry, I can't wait to ditch ladder and Structured Text in favour of modern programming languages for industrial controllers.

This was answered in the German Revolution Pi forum a few months back: https://revolution.kunbus.de/forum/viewtopic.php?f=8&t=6&p=1...

The TL;DR is that the products have gone through all the testing required by EN61131-2 and you can safely deploy them in harsh environments (e.g. wrt electromagnetic radiation or vibrations/shocks). However there is no external certification.

Unfortunately, as awesome as that is, that pretty much means industrial "in name only"...at least for non-hobby / non-startup projects

They seem pretty solid in terms of their specs and certifications, but for industrial equipment I'm always worried about availability and vendor support. Can I get them shipped to a customer anywhere in the world on short notice? Will my vendor's engineers come to the plant with me to solve an inscrutable issue that has brought a machine down? Those answers are "yes" for the systems I'd be replacing, and almost certainly "no" for this thing, however cool it may be.

Both the hardware (base board schematics) as well as the software are open source. Let's say Kunbus goes down the drain and you hit an issue. Best case someone in the community has already fixed it. Worst case you'll have to hire a decent consultant. Show me another PLC that affords the same kind of vendor independence.

As to availability, the hardware is manufactured and assembled in Denkendorf, Germany, so the supply chain is short. The Foundation guarantees availability of the Compute Module 1 and 3 until at least January 2023.

Well, I really like the idea of a standard open source industrial control system. If we ran into vendor/supply issues, that would give us options. But this industry (or at least the pocket of it that I work in) is very conservative. It's like the old "nobody got fired for buying IBM."

Hmmm. I'd be curious to know who ends up using these devices. Maybe I could apply to work for them. :)

Hi there, I'm project manager of Revolution Pi and would like top inform you that you could see the RevPi branded as "industrial Pi" oat the PILZ booth at Hannover Fair. This is just one of our big customers. Many leading companies have already started to port their solutions on out RevPi, e.g. TeamViewer or GTI Control (HMI solutions). There is no doubt that this project has hit the nerve of those generation of engineers who have waited so long to get rid of propriety solutions of "big S"... That's why we called it "Revolution"...

Traditional German manufacturers scrambling to get their foot into IoT, but also various international companies. The RevPi modules pop up at places you can't imagine. Before long there's going to be Linux in every electric cabinet. In other news, Linux world domination is progressing according to plan.

Hi there. I'm an engineer on the Revolution Pi team. AMA.

On the website, you mentioned that you run stock Raspbian with a real-time patch on the devices. I'm mostly curious about the real-time extensions you're using. Did you write the patch in-house? What real-time capabilities are supported on it? Is it just a better scheduler, or do you also include things like locking protocols?

This isn't a particularly important question; I'm just a grad student in real-time research so I like learning about what gets used in practice. Thanks!

There's a patch set for the kernel called PREEMPT_RT:

https://wiki.linuxfoundation.org/realtime/start

It contains patches to get latencies down and touches numerous subsystems of the kernel. Most importantly, interrupt handlers become preemptible. (Normally interrupts are executed in "atomic context", i.e. they cannot be preempted. This also means e.g. that you can't sleep in an interrupt handler because the timer interrupt is disregarded. With PREEMPT_RT_FULL, interrupts are executed in "process context", i.e. as normal kernel threads which can be interrupted.)

We use the kernel branch of the Foundation (which contains a ton of patches required for hardware support of the Raspberry Pi), cherry-pick the realtime patch set on top, then apply three custom patches, one is a fix to make the USB driver's interrupt handler preemptible. The result is this branch:

https://github.com/RevolutionPi/linux/commits/revpi-4.4

When I first saw the product renders the box reminded me of some things packaged in cardboard. But actually that might not be such a bad idea for a Raspberry Pi type of computer in some applications. A lot can be done with printed cardboard for creating a fun case. A cardboard box version for the hobby developer targeting the 'pro' version could make development easier to get into.

The case is made of polycarbonate. Cardboard would be interesting from an environmental perspective, but likely wouldn't be able to withstand the harsh conditions prescribed by EN 61131-2 (low/high temperatures, damp air, vibrations/shock etc). We add a safety margin to those conditions, e.g. 61131-2 requires safe operation at 55 degrees Celsius, we test at 60 degrees. The products are used e.g. in automotive applications where these harsh conditions are not just theoretical.

I think the intent is "give developers a cheaper system to get started with" and not putting a cardboard version into production environments.

No that is definitely not the intention of RevPi. The price is not comparable to Raspberry Pi. It's just the other way round: Many of our customers have used original Raspis to play around and have short development cycles. When they start getting the things ready for real life they switch to RevPi because it is nearly 1005 sw compatible with their experimental system but which is designed for rough environment like any other system from KUNBUS. Btw. the case is the same which used for several PILZ products developed and manufactured by KUNBUS.

I think you misunderstand. The intent of the guy asking for a cardboard case is that he wants a cheaper version of your RevPi for developers. No one should be putting this theoretical cardboard-wrapped computer into production.

Yes, I see your point that a developer could just use a stock RPi to get started, and switch up to RevPi for production use. But this guy wants your sexy case in cardboard.

I'm always looking for LabVIEW alternatives... is one of your cards an analog input module? How else to get 10-20 analog inputs? And is 10kHz sampling reasonable? What's the highest practical Fs? Thank you/danke!

Our AIO module which will be available in June/July is a high precision module (0.1% FSC accuracy without calibration) having 4 differential inputs which can be used as current or voltage inputs (several input ranges are software controlled available). There are 2 additional RT100/RT1000 inputs and 2 analog outputs (current or voltage). These modules are not designed for high speed data acquisition but as standard inputs for typical industrial analog sensors or analog controlled actuators. We are using delta sigma converters to achieve the high precision but this excludes high speed acquisition.

Thanks! Sounds like a replacement for an NI USB DAQ 6008.

An AIO module is coming next month, but I'm not sure about the exact specs. I've just called the project manager, he promised to come here in a bit and answer open questions such as this one.

Nice idea!

One of the reported issues with the Raspberry Pi is failure of the SD card if power is interrupted while the card is being written. Does your implementation overcome this problem?

We use the Raspberry Pi Compute Module, i.e. a special, stripped-down version of the Raspberry Pi which fits on a 200 pin SO-DIMM module. This version does not use an SD card but has a 4 GByte eMMC on-board. (It would be possible to use an SD card in addition to the eMMC but we don't make use of that.)

Of course the eMMC is still based on flash, which has a limited lifetime. So we use a customized version of Raspbian which has swap disabled by default (can be enabled if you need it) and tunes the syslog configuration to reduce the amount of log data written. It's also possible to use a tmpfs-backed /var/log (can be enabled with a mouse click or a simple command). That way we try to prolong the lifetime of the eMMC as much as possible.

We've also been in talks with the Foundation about this and they have asserted that the eMMC is of good quality and should last for the typical lifetime of a PLC (which can be decades).

We are in a very close contact to the Raspi Team and I can assure you that most of those "SD card issues" is pure rumor and urban legend. All known issues could be reduced to the fact that some people bought cheap cards and supposed them to work for ages even when treating them like you would never do with your PC. Raspi team's Sw developers told me they would switch off power without shutting the system down dozens of times per day and never ever had an SD card crash for years now. So please do not spread the rumor without any substantial first hand information. Just because someone did write something somewhere in the internet we can't judge about a technology. Having this said I would like to add the information that RevPi Core does not use any Sd card. nPlease refer to the Compute Module 1 information in the internet to get this Version of the Raspi explained.

I can't edit my post any more, but want to acknowledge this answer. Thanks!

Can these be programmed by any of the 61131-3 languages?

Yes, with appropriate software. logi.CAD (an IEC 61131-3 automation platform) is pre-installed as a demo version and license keys are available at the online shop for a few bucks.

But noone is forcing you to use a specific software. You can use Python or even Bash. The input and output values are stored in a process image by an open source kernel driver (piControl) and you can access the process image through a char device. Just seek() to the value you're interested in and issue a read() or write().

How does it benchmark against other modern PLCs? Could you give a ballpark figure for the scan time of a 10 robot cell for example?

I'm not sure if the question relates to motion control of robots, human-robot collaboration safety or something else entirely.

If the question is about motion control of robots, our cycle time of 10-20 ms is probably too long as motion control usually requires < 1 ms.

If on the other hand the question is about human-robot collaboration safety, the product is likely unsuitable as this requires specially certified appliances.

If it's none of these two, it would be necessary to know more specifically what the setup is (fieldbus used, number of axes, etc) to come up with a realistic figure.

I work in the automotive sector. Not interested in human-robot collaboration at all, I was wondering whether this would be a suitable alternative to PLC control of spot welding and handling industrial robots. Even though the processing power of these things is likely to be better than that of a PLC, am I right in thinking that the overhead involved with running a proper (albeit fairly stripped down) OS would make it slower than a dedicated PLC? Obviously it has its place (and my curiosity is most definitely peaked) but controls hardware costs pale into insignificance compared to the capital costs of everything else in a car plant, so we'd need a pretty compelling case to switch.

This is definitely not the right place to use the RevPi System. It is designed to be a a PLC as well as an IPC or Gateway system. This mixture makes it unique compared to standard PLCs. But any system needing cycle times in the 1 ms range or below can't be controlled by a RevPi. But try and find any PLC which is able to speak nearly every known fieldbus or can easily be used as a gateway for IoT projects.

1. Where do you get those hilarious article photos in the blog from? Stock photos? Colleagues with chickens at home?

2. Why did Kunbus stop selling liquor? ;-)

1. There's a Photoshop wiz on the team. I'm not aware of any colleagues with chicken, must be stock photos then. The crazy stuff shown on expo photos is real though (snack lottery, "occupied" booth etc).

2. I think that was a different company, I'll have to ask the CEO next time I see him.

1. Cool!

2. Yes, sure, we just found it incredible that he used the Kunbus name and address for the imprint. Had a few laughs about it over there in Ostfildern. :-)

The page mentions it has Raspbian Jessie pre-installed. How are updates to that handled, or is that up to the implementor?

Updates to Raspbian packages can be installed via apt-get as usual. The same goes for packages specific to the Revolution Pi, those are made available through a separate apt repo: https://packages.revolutionpi.de/dists/

Upgrades to new releases can be performed either with an in-place "apt-get dist-upgrade" as is customary on Debian-derived distributions, or by creating a backup image of the eMMC, flashing the new image, then copying over any customized config files from the backup.

It's hard to tell from pictures, but are do IO modules have pin-headers instead of wire terminals?

The I/O modules themselves have 2 pin headers with 14 pins each. The pin headers receive adapters with wire terminals. The adapters are included.

The German I/O module page has an animation which shows this in detail, it seems the English page is missing that for some reason:

https://revolution.kunbus.de/io-modul/

That's great. Are there any modules with support for camera and/or screen (HDMI/DSI) planned?

A mini HDMI port is on the top of the RevPi Core and you can attach any display that you would normally use on a Raspberry Pi. There are some displays available from 3rd parties which are suitable for mounting on top hat rails.

The CSI and DSI pins are not accessible on external ports I'm afraid. I'm also not aware of plans to add modules which would make CSI/DSI available externally. In theory it's possible to open the case and attach wires to the pins which go to a connector external to the case and you could connect a CSI camera or DSI display there, however the result can hardly be considered "industrial". :-)

An alternative is to connect a USB camera.

The 4-core BCM2837 on the Compute Module 3 is beefy enough for image processing with OpenCV, in fact we're using OpenCV for our demos at expos. It may even be sufficient for video transcoding. One thing to be aware of though is that we're using a kernel with RT patches. Which means low latency, but also lower throughput. If you don't need low latencies but maximum throughput, it may be a good idea to use a kernel without RT patches. All the tooling to build a custom kernel is on GitHub.

We are already testing the next generation of RevPi which is called "RevPi compact". This series will have a connector with the DCI for the original Raspi camera. We will start selling them at SPS Drives Fair in November. But there is plenty of really good USB cameras on the market and they work fine with Compute Module 3 (CM3). We have had an exhibit at Hannover Fair where the only sensor was an USB Cam connected to the RevPi Core which controlled pumps and valves to mix oil and water from 2 tanks into a third tank and separate the fluid back in their tanks again using just the color difference of the fluids to detect the fluid levels.

Hannover fair this year? Damn, I skipped this one, would have been great to chat with you.

I am actually working on a prototype of something similar- Pi, camera, small touchscreen, distance sensor and small number of IOs.

The two specific use cases for me: measure dimensions of parts hard to measure with other sensors and stopping conveyor when some parts end up in unexpected places.

This would have been perfect for my last startup. Keeping those damn Pi's running when they were deployed across the country was a nightmare.

The SD cards had around a 20% failure rate per year. Eventually I just started shipping each system with a backup SD card taped to the inside of the case.

Were you using decent microSDs? Was each mSD getting QC'ed? We benchmark every single mSD before deploying an SBC with it, and have switched to only using Evo+ 32GB cards as they pass our QC 3/5 of the time, which is much better than the other available brands.

Also, mSD corruption means your using a mSD card with a bad controller. The mSD was bound to corrupt and was a low caliber card to start with, unless you are doing a bunch of writes a mSD should last 2 years minimum, if not longer.

Another tact to take would be to switch to an OrangePi PC+ (8GB eMMC included, $22) or similar, that way you know your getting good quality nand with a decent controller out of the box.

Do you mind sharing your quality control method for this? We are hitting card issues on relatively low device numbers.

Just saw this, TL;DR we transfer a large file onto and off of the mSD card. If its above 10MB/s for both (which is the base rating on a class 10 card), then it is a fine mSD card. I've also noticed that on multi-gig files speeds tend to drop to around 6MB/s, not the end of the world for us, but also not a sign of a bad mSD either.

From my experience the failures were almost always caused by a power loss.

The obvious solution would have been to include a battery backup in the case.

Odd, I've only ever seen this be an issue on the Raspberry Pi platform, outside of that power loss doesn't regularly cause data loss on most Androids or Allwinner boards so long as the mSD isn't of low caliber.

Removable storage is problematic when it comes to reliability. Simply powering the device off while it is writing will cause issues, worse is when you have vibration momentarily overcoming the sprung contacts to the card.

Also mentioned by others are SLC industrial grade cards which have more stable flash memory technology, better controllers, wider operating temperatures and not to mention are much much faster. It all comes down to cost, but trying to build a reliable system with removable cards is not a good idea.

The Pi design team should consider adding some reasonable quality onboard eMMC memory in the future.

Regarding cards, I can vouch for http://www.atpinc.com which we use where I work, expensive but very reliable.

"consider adding some reasonable quality onboard eMMC memory in the future."

The Pi "compute modules" include onboard eMMC and so do these which are based on them.

Have you tried SLC, pSLC or at least, industrial grade MLC cards? They are more expensive, but might be worth it in such applications.

See this whitepaper on why: https://www.cactus-tech.com/files/cactus-tech.com/documents/...

What did your startup do that required that many Raspberry Pis?

The Pis were used in a 24 gym and tanning salon system. They ran a touchscreen for customer interaction, connected to a custom board I built that attached to the proprietary network tanning control systems use, and handled RFID access control.

It worked well, but tanning regulatory changes killed it.

I have a cluster at home, and that's about what I'm seeing. Good wall warts and good power cables reduces the chances of it happening, but doesn't bring it to zero.

At work the SD cards lasted for about 1,5 year and then gave up. I now disabled Ext4 journaling and am considering using the F2FS filesystem which is designed for flash storage.

Is this a just a regular Raspberry Pi in a nice case?

No, it appears to be using the Raspberry Pi 3 compute module. That's essentially a small circuit board with the core components of an RPi3 already designed and assembled. They then solder/plug this module into a larger board to add connectors and peripherals to it. So there's some custom design involved.

https://www.raspberrypi.org/blog/compute-module-3-launch/

That is mostly correct. A few corrections/additions:

* It's either the Compute Module 3 or the older (cheaper, slower) Compute Module 1.

* The schematics of the base board in the RevPi Core are open source: https://revolution.kunbus.de/download/1803/

* Normally you wouldn't open the RevPi Core case and solder stuff to the base board, though you're given all the information you need if want to do so. The expected use is to just mount the RevPi Core on a top hat rail and extend it with I/O or gateway modules via the PiBridge connector.

No. The power supply and case are designed with surge/ static discharge protections conforming to EN61131-2 and IEC 61000-6-2.

What if the user wants to run a different OS besides Linux? Seems like the only option is Linux? No Plan9, BSD, etc.?

Anything that boots on a Raspberry Pi should also work on the Revolution Pi, e.g. FreeBSD:

https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi

It's just that we haven't tested it yet ourselves. Minimal adjustments may be necessary due to a few small differences between the standard RasPi and the RasPi Compute Module used in the Revolution Pi, e.g. the Compute Module lacks the on-board BCM43438 WiFi that's present on the standard RasPi 3.

+55°C max operating temp

Industrial? Nope.

That's the requirement prescribed by EN 61131-2. We test with 60°C, so an additional safety margin of 5°C.

Haha:-) that means you deny an S7-300 PLC to be industrial... Better study EN61131-2 and specs of any standard PLC before giving such comments...hopefully you've just mixed up "industrial" with "automotive" grade...

I was more hoping for a PC coomposed up multiple pis or something

They do exist https://www.picocluster.com/collections/pico-5/products/pico.... I have a 5 node Odroid cluster.

I saw that you mentioned running Hadoop/Spark on your cluster? Do you have any comments on that? I just made a 3 node RPi3 cluster and I have to admit, it's really slow. Like getting the spark Scala interpreter running takes about a minute before anything I type registers in the console. (NOte: this is my own cluster not a PicoCluster TM)

When all 4 cores are under load, the BCM2837 on the Raspberry Pi 3 will rapidly reduce the clock rate after about 60 seconds (from 1.2 GHz to 600 MHz, or even 300 MHz if the core temperature exceeds 85 degrees Celsius). Cooling is required if you want decent performance for prolonged periods of time.

The RevPi Core 3 is equipped with a high performance cooler which is able to sustain 1.2 GHz at full load for about 20 minutes (at room temperature). After that the clock rate will be moderately reduced to 1.15 GHz.

A 4% heat throttle seems an unusually subtle adjustment. If testing has found it to be effective that is a good finesse.

are my eyes mistaken, but a cardboard case? is that safe? fire hazard?

From the datasheet (linked on the website):

Housing type: DIN rail housing (for DIN rail version EN 50022) Housing material: Polycarbonate

Don't know which pics you have looked at but if you scroll through the blog you will find many pictures which are photoshopped and several pictures which are real fotos showing the case opened etc. Hope this will leave no doubt that this thing is made of durable poly carbonate...

Why is it 200 GBP? If it is a RPi3 compute board which costs only 25 GBP why the insane markup?

The RPI compute module is the thing that looks like a memory dimm, with no ports. It's not useful by itself.

The purported value add is that the product includes a backplane, ports, power supply, and enclosure that are suitable for use in an industrial setting (wide operating temperature range, shock/vibration, etc).

Reply on news.ycombinator.com