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.
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.
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.
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!
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:
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.
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.
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.
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.
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().
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. 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.
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. :-)
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.
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.
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.
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.
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.
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.
* 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.
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.
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 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.
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...
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).
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.