EMC2 running on Raspberry Pi?
Mind you: preliminary testing of unfinished stuff.
This is basically the first time I run the motors at speed. No tuning of the PID loops or dSpin drives has been performed yet, which is audible. At 1G acceleration step loss happens at 800mm/s which is waaaay too fast to be comfortable anyway; the entire travel range is covered in a fraction of a second at that speed. Video is running at most at 300mm/s.
After several hours of running LinuxCNC and the Pi didn't miss a single beat.
What if the GUI was on the x86 computer and the other realtime tasks would run on RasPi?
These two computers could be connected by Ethernet, I know that RasPi has a USB-based ethernet but for non-realtime data it might be enough.
Would it be difficult to do something like that?
One of the benefits could be that the PC with the GUI could be a Windows machine on which could also be CAD / CAM software. GUI on windows machines could help to popularize Linuxcnc, I know many people who are still using Mach3 because they are afraid of Linux OS.
Their MachineTalk or whatever infrastructure is suited for this and they do have Qt5 UI's running on Android/Windows.
And if you go that route you are also better off using the BeagleBone (better latency figures, two helper processors named PRU for stepgen/encoders/pwm) or even better the DE0-Nano-SOC board (which runs the Mesa FPGA code allowing connection of all things Mesa).
Another option is remote X. OpenGL can be tunneled over the pipe also, so rendering happens locally at the X server running on PC. Check out MobaXTerm if you need an integrated SSH/X-server/Cygwin environment on Windows.
Huge disadvantage of remote X is that the application terminates when the link fails.
The initial idea was to build a controller that will have compact dimensions, the data will be mounted on a DIN rail and will not need a standard PC. Something like in a single-purpose machine built on a PLC. I found quite nice modular boxes from italtronic, which also have a version for RasPi, and on this basis we have designed the modular system of our boards.
We also decided for RasPi over Beaglebone because we dont use any of its benefits. We need computer with fast CPU and GPU and all other functions like stepgenerator, irc counters, ADC, DAC, IOs we can do it better on separate FPGA based modular boards.
The result looks like this:
Now I facing the problem, some customers say that boards is good, but we can´t use it in our machines because of this laggy GUI. We did not know about this problem until end, because we always test funcions with "LinuxCNC" splash example
I am not sure I would want to use a Raspberry Pi in a commercial product. The boards are not meant to be used that way and I doubt the foundation cooperates if you plan to do so. I would choose some system on module if I intend to do that (which could be a Pi SOM or something with an Atom or i.MX6 or so).
Regarding GUI's: I am green as grass in that area. I somehow managed to build something with Glade/GTK and Python, and so far is was a fairly painless experience. Except that the Glade version used is a disaster to get running on a more modern Linux distribution.
What is the difference between these and what did you recommend me one above?
I am not sure I would want to use a Raspberry Pi in a commercial product. The boards are not meant to be used that way and I doubt the foundation cooperates if you plan to do so.
Raspberry is same single-board computer like beaglebone, our cards is same commercial product like mesa cards. Only difference is that plastic box.
No standard motherboard was not meant to be used to control machine over LPT and nevertheless companies artsoft sell Mach3 software for years. I see many commercial boards for LTP to controll cnc.
This boards is not designed specialy for LinuxCNC. Any program running on raspberry pi that can reach SPI can use it. Until now I make some test with LinuxCNC, Codesys, Matlab, (LabVIEW is in plan)
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'.
Maybe things have changed nowadays, but I would at least investigate these possible issues and risks. A couple of RMA's and support calls burn through the money earned by using a cheap Pi's quickly.
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.
(and the drives I am referring to: granitedevices.com/miniature-servo-drive-ioni/
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