Since very slow PCs with limited memory could do this as well as the slower PRU
processors on the BBB, I'd venture a guess that if a Pi4 can't do at least
50kHz stepping while also doing trajectory planning and screen updates there is
something really 'off' with LinuxCNC.
It depends on your definition of 'off'. On a Pi LinuxCNC runs it's
realtime stuff as normal operating system tasks, just with high
priority. The task scheduler has been tuned to be very aggressive in
running high performance tasks but even so you have a lot of overhead.
Linux and modern computer hardware are designed for high overall
throughput for many tasks that are accessing huge amounts of data. They
are not designed for ultra low latency on small tasks.
To get good stepping on older PCs you need RTAI which is effectively an
RTOS that runs Linux as one of it's tasks. Realtime tasks are then run
on this RTOS rather than the operating system. This is a simplification
but you get the idea.
LinuxCNC has been designed to be versatile, easy to develop and easy to
maintain. If you take a look at the stepgen code it's very generic and
does not take advantage of any architecture specific code. The same code
runs step generation on PCs running RTAI or rt-linux. It also runs on a
Pi or a Beagle. It can run a parallel port, the PI GPIO pins, MESA GPIO
pins etc with no modification.
So why is Mach able to get fast step speeds? It hijacks a hardware timer
(the APIC) and has a custom interrupt handler that is tightly optimized
for step generation on a PC with a parallel port. The code has one
target and it works well on that target. It won't work on anything else.
If someone was to write an equivalent driver for for the Pi you would be
able to get blistering stepper speeds. The problem is that the code
would only work on a Pi. On the Beagle someone wrote a driver that
offloads the step task to the PRU. That code only runs a a Beagle. To go
this route for all platforms you now have to write and maintain a
different driver for each platform. LinuxCNC is a small project with a
limited number of maintainers. If you make it too hard to maintain the
project simply would not have the available man-hours to continue.
Maybe too many hardware abstraction layers?
Remember LinuxCNC is designed to be a versatile, highly customizable and
modular machine controller. It's original name Enhanced Machine Control
reflects this. You can use it to run anything from a simple X,Y desktop
engraver to a huge 5 axis monster with a complex tool changer or a robot
arm. It was never intended to be optimized, tweaked and streamlined to
wring out every last drop of performance for one task. You can have
performance or you can have versatility. You can't have both.
3D printers are used as examples of how it 'should' be done. They have a
different design philosophy. They do one job. The controllers are jam
packed with highly optimized code that wrings out every drop of
performance from both the hardware and software. Maintaining that code
is hard. Porting it to a different platform is a huge job. Configuring
it for a range of very different targets is pretty much impossible for
anyone other than an experienced programmer who is willing to put in a
lot of time. Luckily for the 3D printer community there are a lot of
people and businesses willing to donate the time and money needed to do
this. LinuxCNC does not have those resources.
And generally the trajectory planners create FIFO buffers that hold a step
and a direction bit for 4 axis in one byte. Each byte, sent out at 50Hz,
either has a step signal nor not. At the end of the 5uS step pulse time as you
said, the step levels are set off again.
Nope. That's not how LinuxCNC, Mach, GRBL or Marlin work. The step
generators are fed velocity or position commands and they work out when
to send out the steps as needed. They aren't fed a pre-processed byte
stream.
Mach does have a FIFO for the velocity commands. It's trajectory planner
runs in user space and tries to keep the FIFO filled with velocities.
That's why things like feed rate override and pause don't act
immediately. There is a small delay as the new velocities filter through
the FIFO. If the TP can't keep up your machine stops abruptly. When
jogging the driver uses a very basic built in trajectory planner to get
around the FIFO delay.
LinuxCNC's trajectory planner runs in real time. Stepper velocities are
calculated on the fly. This is why pause, FRO etc are pretty much
instantaneous (within the acceleration limits of the machine).
I haven't looked at GRBL and Marlin that closely but it looks like their
step gens are fed position targets from a FIFO rather than velocities.
The step gens effectively do some of the trajectory planning on the fly.
I'd say being able to 10kHz stepping and being happy with that might be setting
the bar very very low.
Keep in mind the Pi is a very new platform for LinuxCNC. This stuff is
in very early development. Are you willing to donate some time to making
it better? I have seen a lot of posts here saying how LinuxCNC could be
better in so may ways but I'm not seeing many volunteers to actually do
the work. The people actually improving LinuxCNC tend to spend their
time fixing problems rather than talking about them.
Les
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
