Comments between. > -----Original Message----- > From: bari [mailto:bari00...@gmail.com] > The guy down the hall from me has been keeping RTAI alive for LCNC the > past few years. I'm not sure if real time performance would be much > better using QNX vs Linux + RTAI on a PC. I think one first has to define exactly what needs to be real time. I doubt QNX is free. > > http://blackberry.qnx.com/en/software-solutions/embedded- > software/industrial/qnx-nuetrino-rtos > > There would be trade-offs on hardware support to port LCNC to QNX, > especially when it comes to GPU acceleration. RTAI and preempt_rt > perform pretty well on many low cost PC's with base threads down in the > few microseconds range for software stepping. One of the reasons to use Linux or Windows is that as the motherboards (CPUs) change from one core to 2 cores to 8 cores to 1 core with two peripheral processors etc. the basic work to make the system has been done. When you plug in that USB WiFi dongle it's usually possible to find a driver. Same with a parallel port card or camera card or a second Ethernet card
If you are using Ethernet and UDP then it's a launch and forget method on a private Ethernet. Or if TCP/IP then reliable ordered messaging. So the workhorse for screen and outside world communications is there. > > Going with a motion controller where the real time control is closer to > the motors give us what? I still need a GUI on some display at least 12" > across. A smartphone display might be OK for a CNC glue gun but not to > control my 2 ton+ VMC or lathe. And there's the rub. In the past, connecting all the encoder/resolvers and motor input into a PCI card and having the PC do all the work made sense. Especially since the only other option was an 8 or maybe 16 bit processor that used EPROMs. (I'm talking 1990's here). > > The ~$2 STM32 boards gives you an ARM processor with unprotected IO. You > need many more parts around that to buffer, level shift and ESD suppress. This will be true for anything regardless of where the I/O begins. Note the MESA cards have buffers. The Xylotex Cape for the Beagle has buffers. The question to ask or answer is where do you want that to be. At one point it was on the PC motherboard and came out as a DB-25. Thousands of machines still run with that interface. At the moment mine does. I really don't know what is going on under the covers for either the MESA Ethernet 7i92H or the Ethernet Smooth Stepper for MACH. But considering the power of the processors running machines back in the 90's or early 2000's and that the mechanics for the metal cutting haven't changed much, my guess is that some 32 bit processor _not_ running Linux so that the graphics/USB/etc. doesn't cripple the real time behaviour will be the solution. For example a PIC32 with USB (for firmware upgrades) and Ethernet (for Control) along with a CAN bus (CANopen control of non-real time peripherals) and the Free RTOS could be the building block. The software on the PC written in say Lazarus (Object Pascal, write once, compile anywhere) which is available free with graphical capabilities on machine for Linux (PCs and Pi and Beaglebone) , Windows and MACs. This approach doesn't get mentioned. A small 32 bit processor like this could even have a small LCD display with a few buttons for basic machine operation. Enough to move axis, turn on/off spindle etc. Simple switch with local/remote mode. I look at the world this way because that's the type of stuff I've been designing and writing software for over the last 25 years or so. If I understand the Hardware Abstraction Layer correctly this is, in effect, already being done on the LinuxCNC PC. But when I run the stress test on my PC the machine has some pretty long latencies. But it's not needed. IMHO John Dammeyer > > On 1/23/20 12:17 PM, Chris Albertson wrote: > > The trouble with the Mesa FPGA design is that it depends on a computer > with > > good real-time performance. It can generate steps but I don't thing you > > can run a position or velocity PID control loop on the FPGA. > > > > You asked about "my controler". No this is not my idea, this is how most > > current designs work today. You "push" the real-time control down stram > as > > close to the physical motor as possible. In the old days computers > > where expensive and you wanted to minimize their number but tocay a 32- > bit > > computer with floating point math, RAM and quita a lot of > > peripheral hardware cost as littel as $1. I buy these $3 PCBs for > > controlling up to two servo motors with quadarue feedback > > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
