When you enter the 4th and 5th axis world for cnc things start getting interesting. I have started looking at how LinuxCNC works with a plan to use it as the primary gcode runner on a higher axis machine.
Of the many options that LinuxCNC offers, I might start out using a parallel port and small breakout board to software signal some stepper controllers. These controllers have an enable, step, and direction pin and can be wired up in a few ways. This involves if the signal goes to the A+ pin or if you run high voltage to those A+ pins and run the signal to the A- pin. See for example about half way down this smoothieboard page.
Anyway, back to the LinuxCNC topic. The main thing that controls how well you can control stepper motors over the parallel port is how accurately the LinuxCNC process can schedule itself. if there is a big delay or jitter between calls that are supposed to be at a fixed distance in time apart then the machine control will not be as you might like. The latency-test program can be used to see the jitter.
The LinuxCNC images are based on Debian wheezy. This distribution includes a Linux kernel designed for supporting real time operation. There are a few real time Linux options floating around and the kernel on stretch (rt preempt) that is installed by installing linuxcnc-uspace is different to the one used by the wheezy image (RTAI). IIRC.
For controlling the machine I put together a combination for around $200 including an Intel Pentium G4560 on a Asus H110M-C2 with 4gb of 2400Mhz RAM. This relies on having cases, psu, drives etc already. This has an Intel NIC and onboard prt header (no pci bracket). The CPU has 2 cores and can do two HT.
Booting the current LinuxCNC iso image and running the latency-test gave about 3200 idle and 5100 under load. The two downsides are that the kernel was old enough that M.2 didn't work and the NIC was not detected.
Installing Debian Stretch on the machine the M2 and nic were both detected and all was well. I then installed the LinuxCNC packages which brought in the preempt rt kernel:
Linux bitbreaker 4.9.0-6-rt-amd64 #1 SMP PREEMPT RT Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux
The latency-test came out at about 40,000 idle and up to 70,000 under load. Not quite what I had hoped for. Adding "isolcpus=2,3 idle=poll intel_idle.max_cstate=0 processor.max_cstate=0" to the kernel cmdline and using taskset -cp 2 $pid moved the numbers to 22,000 and 40,000 respectively. Better, but not what I had seen on the official recommended ISO bootup.
To cut a long story short(er) doing a telinit 3 and going non graphical on the control machine and using ssh -Y to login and run the latency-test I was able to get down to 4000 under load. This is again by forcing the rtapi_app to use a reserved CPU core.
Maybe using a different graphics card or some other graphics options would allow the latency to be lower on the display of the machine. But I'm fairly happy to run the GUI to display on the laptop to harvest the better latency numbers.
It is handy to be able to get closer to the jitter numbers that are given when using the official ISO for LinuxCNC as it gives the feeling that I'm not loosing out on good machine control because I'm on stretch and a customized setup. Ironically, using the nice new hardware for the build actually made initial setup harder. Though I imagine that is a temporary situation.
Hopefully those better jitter numbers can be had for real machining over the network too.
