EMC2 running on Raspberry Pi?

DaBit wrote: Also, if you want to make electronics for industrial use, you need a wider temperature spec and quite often more stringent EMC requirements than required for 'office equipment'.

There is a Pi module aimed at industrial applications. It looks like a perfect partner to the Granite Ioni drives.
www.raspberrypi.org/products/compute-module-3/

(and the drives I am referring to: granitedevices.com/miniature-servo-drive-ioni/

I know the Compute Module 3 exists. Now I hope that they can provide a steady supply of them. A quick check at RS displayed an 'out of stock' already (although it is probably not there yet).

The original Compute Module was a disaster in that regard; it was listed, but structurally unavailable. Luckily the project where I designed them in never went past the prototype phase.
Oh well, see for yourself. The CM1 is already a mature product, but not so old that it is past the typical 5-7 years of minimum required supply continuity. Try to buy 250pcs of them for your upcoming next virtual production run of product X which you designed two years ago. Good luck....
Oh, and you cannot simply change the PCB and use a CM3 in product X because then you have to redo a large part of the documentation and certification. Single unit electronics design is easy, designing for production is much harder.

I hope they did their homework this time, but until today I do not thrust the Pi foundation products.

Offtopic: I love all the Granite Devices stuff

I would like to see a LinuxCNC distro for the stock Raspberry Pi.
I do not get why this hasn't happened yet. There's a real-time kernel patch, right?
www.frank-durr.de/?p=203

I don't why it seems like everyone is recommending doing unfocused processes and for support for a specific pieces of hardware instead of getting everyone together to support a standard Pi, with the aim that it be as flexible as LinuxCNC itself.

To see this on both the LinuxCNC forum and the Rpi forum, I feel that I've just walked in on my parents have a moment of failed intimacy. There's something going on here, but I don't know what : )

I had Maschinekit running on RPi2B (latest model). Latency is really bad, ~ 50000ns. And you need a level converter between GPIO and almost anything you try to communicate with (If you don't the GPIOs die sooner or later). You'll need a display and keyboard, too, so you end up somewhere in the range of 120.- just for a crawling slow barebone machine with the equivalent of a parallel port and bad latency. So while it's nice to play with, it's a pain to actually work with.

Better get a used T60 with dockingstation (total ~ 30.- if it's in really nice shape), install Libreboot and have a latency of ~ 2000ns. Or get a T42/T43 and have a latency of ~ 8000 ns out of the box.

Actually, 50,000 nS latency isn't terrible. My first LinuxCNC machine had that latency and was OK even with software stepping. I think that expectations of acceptable latency have moved too far.

linuxcnc.org/docs/2.7/html/install/latency-test.html

Says:
"So, what do the results mean? If your Max Jitter number is less than about 15-20 microseconds (15000-20000 nanoseconds), the computer should give very nice results with software stepping. If the max latency is more like 30-50 microseconds, you can still get good results, but your maximum step rate might be a little disappointing, especially if you use microstepping or have very fine pitch leadscrews. If the numbers are 100 us or more (100,000 nanoseconds), then the PC is not a good candidate for software stepping. Numbers over 1 millisecond (1,000,000 nanoseconds) mean the PC is not a good candidate for LinuxCNC, regardless of whether you use software stepping or not."

I designed and made a batch of level-convertors for Pi (and then went on to never use them).
photos.app.goo.gl/BRkFbfVLtNOBYBW22

I used the GTL2000DL chip (22 bit bidirectional logic level shifter)
datasheet.octopart.com/GTL2000DL%2C518-N...datasheet-134572.pdf
Though it looks like that chip might no longer be current.

But to continue: I am not disagreeing that unless you are really short of space, there is no reason to use a Pi when a small x86 machine will work so much more easily and better.