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.
