Maximum clock frequency?

[Elmi77]

Hi,

thanks for the list of supported MCUs. But I'm missing one information: the maximum clock (step) frequency one can achieve with them for the different axes (especially with the SAMD21 at 48 and 96 MHz). Is this information available somewhere?

Thanks :-)

[phil-barrett]

A lot depends on your breakout board. You can certainly get well above the grbl Classic max of 30K. I spec my Teensy 4.1 BoB conservatively for 160 KHz. (2 layer + interface logic and no impedance matching). I believe Terje has seen close to 300KHz (on a bare board?). Most stepper drivers are spec'd to 200KHz and I'm pretty sure that even a lowly 48 MHz SAMD21 will produce a step rate well above what you actually would use. Best idea would be to measure it.

[terjeio]

Is this information available somewhere?

No. See below.

I believe Terje has seen close to 300KHz (on a bare board?).

I have seen 400KHz+ with a Teensy 4 before the step signals started to break down. Single move so light CPU load - not possible to achieve in a real world application with many small moves with lots of traffic on the input stream.

Best idea would be to measure it.

How? As I did above by observing where the step signal fell apart and became erratic? Or better by somehow determining maximum execution time of the stepper ISR? Measuring load on the processor by observing how much time is spent idling in the main protocol loop? Check if the processor is able to keep planner buffer filled at all times? All of this?

It would be nice to have a standardized way of determining the max. step rate which one can rely upon. If anybody has a good idea what that would be I am all ears.

Note that on a SAMD21 MCU max rate could be limited by overhead when machining arcs, this at it has no floating point unit (FPU). But then perhaps not...

What can be mentioned is that most of the drivers I have written bypass framework wrapper functions to access hardware, I use direct register reads and writes where possible for speed of execution. This to keep grblHAL in line with legacy grbl - "... written in highly optimized C ...". I have even optimized some parts even more, by using coding techniques which is not possible to use on a 8-bit target without adding overhead instead. IMO grblHAL should be the fastest grbl port on any given processor due to this...

[phil-barrett]

How?

Nothing sophisticated. I have used a scope and logic analyzer to look at the signals. The scope will often show artifacts that make the signal look bad but not necessarily degraded to unusable. The LA will show you an idealized version of the waveform that is very likely acceptable to most drivers. And, in the cheap realm, I've used an Arduino to measure input frequency. If it can measure a frequency, it's probably ok for drivers.

[jimfong1]

Received a Teensy4.1 today and testing out the grbl-hal port.  Maximum single axis step pulse speed is 400Khz. This was tested with a expensive industrial Parker E-DC stepper driver set at 250 microstepping. This stepper drive is capable of 2Mhz step pulse input rates. Motor spins smoothly with no jitter at 400Khz.  Grbl pulse width set at 2 microseconds.  Step pulse frequency measured with oscilloscope and logic analyzer.  If you try to set the step pulse rate higher than 400Khz, the pulse degrades. This is probably some timer overrun in the code.

I need really high step pulse speed due to using brushless servo motors with ultra high resolution encoders. This 400Khz is the highest single axis step pulse rate tested on various grbl-hal ports on actual hardware.

[phil-barrett]

A subject near and dear to my heart. I did a blog about this here. We reached the same conclusion.

It is probably possible to go faster with a small change to the min pulse width. Though, that presumes it is just a number and not a limit of the timers used for step generation.

[jimfong1]

Hi Phil

Using the same LA you have and a Rigol 1054Z to measure. 2 microsecond pulse width is the lowest for $0. Need to find in the code to change it lower and compile again. My drives are good for 200ns pulse width which I verified with a HP8116a pulse gen.

I'm also testing with Lightburn laser software but high density grayscale is overwhelming the firmware throughput. These are huge gcode files. It still runs faster than the other ports of grbl but not significant. Not much faster than 80Mhz STM32 port of grbl-hal.

The Jitter is exceptionally low with the Teensy compared other controllers. This is rather nice and you get really smooth motor motion. ESP32 port, jitter is really bad over 100Khz

I've tested almost every grbl version available on the many different microcontrollers I have. The Teeny works well so far.

More testing and code tweaks to get this to where I will be happy.

[phil-barrett]

You definitely want to increase planner buffer size to at least 1024. info here and here.

[jimfong1]

I increased it to 1024 and it improved the grayscale raster speed by about 30%. I tried increasing it higher but did not see any more improvement. The Teensy4.1 runs my grayscale raster test about 9 seconds faster than grbl-lpc and smoothieware firmware. It is about 2 seconds faster than the LM4F120/grbl port which was the fastest version tested.

Not to bad.

[phil-barrett]

Would you mind sharing your test? GCode I assume.

[terjeio]

Does Lightburn use what I call "agressive buffering"? This is sending gcode to the controller until the serial input buffer fills up and then keep it filled by character counting. If sending a block wait for ok, send another wait for ok... then this will limit max feedrate for short movements. Using ioSender with "agressive buffering" enabled the feed rate can be significantly increased even at 115200 baud.

If a sender uses "agressive buffering" it may be hardcoded for the the 128 byte input buffer in legacy Grbl even if the buffer size is available in the $I report. Default input buffer size in most grblHAL drivers is 1024 bytes.

Max. planner buffer size in legacy Grbl, and in all ports I have checked, is limited to 256 bytes. In grblHAL it is limited by available RAM. Legacy Grbl uses indexed access to planner buffer entries, grblHAL uses a doubly linked list which is, IMO, faster. I am using linked lists for buffers in stepper.c as well, and downcounting loops for updating arrays where possible. This as I do not want to waste cycles (and to compensate for the few nanoseconds lost when calling driver code over a function pointer).

If you can share your grayscale test file and some test results I can run some to see if there is room for improvement.

Need to find in the code to change it lower and compile again.

It is set here:

https://github.com/terjeio/grblHAL/blob/07ade75c2cbaffde1f11f6adbb9cd5b4bd874118/drivers/IMXRT1062/grblHAL_Teensy4/src/driver.c#L1454

Minimum is limited by interrupt latency and the maximum time it takes to set up for a new step. IIRC early on I found that to be around 300 ns.

https://github.com/terjeio/grblHAL/blob/07ade75c2cbaffde1f11f6adbb9cd5b4bd874118/drivers/IMXRT1062/grblHAL_Teensy4/src/driver.h#L177-L182

ESP32 port, jitter is really bad over 100Khz

Is this with the grblHAL driver or Barts port? If the latter I expect grblHAL to behave better...

Please use the test branch when testing.

[phil-barrett]

Lightburn has a "Transfer Mode" selection - buffered or synchronous. I suspect buffered is aggressive buffering - at least the way it is described in the gnea/grbl wiki.

Lightburn works with compatibility level 0 grblHAL, by the way.

[jimfong1]

Thanks for the info guys.

Lightburn and iosender with aggressive buffering runs my grayscale raster test with similar time, within 1 second.

The grayscale gcode test file is located here https://embeddedtronicsblog.wordpress.com/2020/07/20/grblhal/ On all processor grbl versions tested, I set steps per mm to 160 and acceleration to 2000mm/sec^2
This is the same settings I use for my laser so I can compare run times between processors. 2000mm/sec^2 is a reliable acceleration setting for the machine. Of course setting acceleration higher will lower runtime but then times can't be compared to actual machine. The gcode test file feedrate is set at 500mm/sec so you will need to set max axis speed higher than that. Takes about 34 seconds to run on the TEENSY4.1.

If you have Lightburn, the test file is here. The dpi is set at 100. My goal is to be able to run the file at 254 dpi fast and smoothly but no processor running grbl is able to do that yet. At 254dpi, the gcode file is over 5 times longer that 100dpi
https://www.dropbox.com/s/taj8s95j54yjg97/greyscale%20test.lbrn?dl=0

Thanks for the code snippet where I can change the step pulse time. Saves me time searching through.

It was Barts codebase that I tested a while back that had the jitter. I noticed a major code update on github so I need to re-test again. I also need to test the ESP32/grblHAL version at the same time.

Yes I have compatibility level 0 and lightburn seems to run fine.

Jim

[jimfong1]

I changed the step pulse to 1 microsecond. Scope measures it as 935ns, close enough. Was able to get a stable 500Khz step pulse rate single axis move, which is more than I need. Stepper motor runs smoothly at that speed.

More testing and reached 600Khz with stable pulse, any higher there is a pulse jitter that you can feel on the motor. Freq double checked with a HP5334B counter

short video driver set at 250 microstepping. motor is spinning at 720rpm https://youtu.be/2fAEQEkQyFw

[terjeio]

@jimfong1 - I am a bit slow as did not immediately connect you to the exchange we had earlier on your blog. Sorry about that.

I wonder if the 5-600Khz step rate is sustainable when processing lots of short moves that includes changing the PWM output. Or is this what you have tested?

I thinking about make some changes to grblHAL to support tuning without recompiling, at least for the more capable processors there are drivers for. One is that the planner buffer could be dynamically allocated from the heap, allowing the use of a $-setting to configure its size. Another is that the minimum pulse width allowed could be set by the driver, not the core as it is now.

Error reporting should be implemented too as the sum of step pulse width and step pulse delay plus a minimum off time (2.5µs or configured step pulse width?) sets the limit for the max. step rate attainable.

[jimfong1]

Good morning terjeio,

Max speed was just simple g1 move. Needed to get baseline on how fast step pulse is possible. Next step is to connect the TEENSY to my corexy test setup. This setup is using the same Parker stepper drivers so I can set microstepping really high to evaluate step pulse speed vs processor capability

https://youtu.be/O3NwQxUiyS4

I also have a 1200mm linear axis test to evaluate acceleration/speed https://youtu.be/xjhEENP9bwQ

having more $ runtime config options would be nice although it doesn't bother me to recompile all the time.

have a nice day

Jim

[phil-barrett]

Definitely interested in the results of the Teensy driving CoreXY. I am considering building a CO2 laser cutter and using CoreXY for it's speed.

[jimfong1]

Hi Phil,

Will post results on my blog. Was reading your blog and some nice machines you posted. I've made around 10 over the years. currently have 5 in my basement. 2 bench mills, router, metal lathe, co2laser. Nothing big or extravagant but gets the work done for my hobbies. I run whatever I think is best for the machine. Mach3, Linuxcnc, UCCNC, grbl, smoothie, marlin, repapfirmware etc. Working on converting my wood lathe to cnc sometime soon. I have a lot of different motion control hardware at my disposal.

[phil-barrett]

Thanks. The showcase is growing steadily. Mostly with machines based on my T4.1 BOB though I would love to feature more grblHAL based machines on other platforms.

[jimfong1]

I saw your TEENSY BOB. It looks really well designed. I just have a bare TEENSY and need to solder up the headers and a carrier board with screw terminals today. something quick and dirty to connect to the corexy machine. Last time I used that was over a year ago to some testing for Ray over at Cohesion3D. He sent me a pre-release board to try to blow up. Run through a bunch of thermal and reliability tests.