grblHAL core code and master Wiki

I often find myself in the shop and needed to jog the machine to get the gantry out of the way, but if I'm cutting on the machine I don't take my laptop out with me.

I'd like a way to move the machine in a limited way from buttons or a joystick etc. without having to get my laptop and fire up the sender.

On the grblHAL2000 board there is a RaspberryPi header that includes connecting the UART on the Pi to Serial2 on the Teensy. Originally I was thinking that the Teensy behaved like the arduino and that the USB serial would be replicated on the serial port by default, so I could just send some basic jog commands from the Pi when the Laptop wasn't connected, and move the machine.

It turns out the Teensy does not mirror the USB serial communications on any physical serial pins by default.

I'm thinking of using the Pi on serial2 on the Teensy and a plugin, perhaps, to allow jogging but I'm unsure of the best way to do it. I would like to be able to use something like a USB IR remote (that I have a few of) on the Pi side and maps those key presses to various GCODE and grbl commands. Does this sound like a reasonable way to do this? Or would it make more sense to somehow enable bidirectional communication on serial2 when the USB isn't active and just talk directly to the grblHAL core that way as if it was just another sender?

In Board Tinyg Due I could not declare a pin for Safety Door, response "driver error" or something similar. I can only use by software. In generic, it only responds by hardware. In both cases, with the following error: I could not get it to the Parking position: it only stops the movements and the spindle. When the Door pin stops being gnd, it resumes after the established time, or automatically if it is by soft, instead of waiting for the sending of ~

Hi Terje, have just updated my router to latest code, and seeing a weird homing issue.

Am running a ganged Y axis, with auto-squaring, on Phil's Teensy41 board. Was previously running code from much earlier in the year, didn't think to make of note of the older revision though.

Before attempting any movement, I'd moved the Y2 stepper & limit switch connections from B to A, and checked all the limit switches were triggering as expected in the realtime reports.

On each attempt to home; Z homes correctly as expected. If X is the next axis to reach it's limit switch, the switch is triggered, but the X axis motor doesn't stop. Stepper just stalls against the end stop. If the X axis limit switch is triggered when the Y axis reach their limit switches, then they stop as expected. If the X axis limit switch is not triggered when the Y axis reach their limit switches, then the Y axis motors don't stop. Stepper(s?) just stall against the end stops. If the Y axis limit switch(es?) are triggered when the X axis reaches it's limit, then X axis motor stops as expected.

Is a bit hard to tell whether it's affecting both or just one of the Y axis in each case.

Am building with platformio, no code changes, but have commented out the microSD libraries, and added the following settings;

    -DHUANYANG_ENABLE=1
    -DSPINDLE_RPM_CONTROLLED
    -DY_GANGED=1
    -DY_AUTO_SQUARE=1
    -DBLOCK_BUFFER_SIZE=512

Any ideas??

I've been following grblHAL's progress for a couple years. I'm thinking about starting a port for a Teknic ClearCore controller, https://www.teknic.com/products/io-motion-controller/, which uses an M4 SAM E53.

The terjeio/grblHAL readme states "You can even add your own driver if you feel so inclined." This template link is down https://github.com/terjeio/grblHAL/blob/master/templates/arm-driver

The HAL dev ref in the wiki, https://github.com/terjeio/grblHAL/wiki/Hardware-Abstraction-Layer-(HAL)----developer-reference is 18 months old. Is a newer one planned? or is this still current.

I understand the pending grblHAL move is in progress and the ports are in various stages of development...

1. Which port follows the directory/file structure that you want to see with all new ports?
2. Is there a template to follow?
3. Is the HAL Dev Ref page, dated 2019, close to current code revision level?
4. Have you benchmarked grblHAL's performance when the core runs in a FreeRTOS task?
5. Do you see any advantage to using FreeRTOS for some more complex designs requiring CPU to multitask with other non-grbl related tasks?

Thanks for your time.

Hello Guys,

i compiled the grblHAL for a Arduino Due (SAM3X8E). I used grbl on an Arduino Uno (328p) before. I found the uno to be too slow for rasterscanning images. So i was hoping for better performance on a Due.

Sadly i still cant go above 7000mm/min engraving speed. (stuttery/jerky motion above) My DIY engraver/cutter is physically capable of 20000mm/min movement speed and 4000mm/s² acceleration. So i was hoping to get to these speeds.

I used the nativ usb serial interface with Lightburn on a Mac. I set light burn to 2Mbaud. I could verify that the serial connection is not the issue as the max speed archivable didnt change with lower serial baud rate.

I tried increasing the BLOCK_BUFFER_SIZE in grbl/config.h to 512

I also tried increasing/decreasing the ACCELERATION_TICKS_PER_SECOND (50 to 200). And finally tried changing SEGMENT_BUFFER_SIZE.

I could not reach higher speeds while engraving grayscale.

Any ideas how i could improve the speeds?

Thanks for your support.

Not really an issue, more a call for help.

I don't normally get stuck on things like this, I'm quite comfortable with designing PCB's and writing my own software etc, but for some reason I cannot for the life of me figure out how to install grblHAL. I find the wiki instructions to be confusing. Gave up on my last attempt and stuck with GRBL, but I need a faster controller now.

Where am I supposed to put the driver files, inside the core folder? The logic on the instructions (as I interpret it, wouldn't surprise me to learn I missed something) goes as follows:

Download the drivers for the MCU of choice. Upload drivers.

There's some steps missing in between, and I don't think I'm supposed to be uploading just the driver am I? Have I missed some other documentation?

I have F4 and H7, they are different from the past, the specific performance is that the power is in the alarm state, and cannot be unlocked through $x, sending $x will get error 18, sending $H, will get error 5, (no code changes

I can't get the unlocking in the sender software. I need to press reset and unlock several times to make the grblhal in the idle state. I don't know what happened to the grblhal during this time.

[G59.3:0.000,0.000,0.000] [G28:0.000,0.000,0.000] [G30:0.000,0.000,0.000] [G92:0.000,0.000,0.000] [TLO:0.000,0.000,0.000] [PRB:0.000,0.000,0.000:0] [GC:G0 G54 G17 G21 G90 G94 G49 G98 G50 M5 M9 T0 F0 S0.] [VER:1.1f.20220325:] [OPT:VNMSL,35,1024,3,0] [NEWOPT:ENUMS,RT+,TC,SED] [FIRMWARE:grblHAL] [NVS STORAGE:*FLASH] [DRIVER:STM32H743] [DRIVER VERSION:220325] [BOARD:grblHAL reference map] [AUX IO:3,4,0,0] $0=10.0 $1=25 $2=0 $3=0 $4=7 $5=0 $6=0 $7=0 $10=511 $11=0.010 $12=0.002 $13=0 $14=0 $15=0 $16=0 $17=0 $18=0 $19=0 $20=0 $21=0 $22=0 $23=0 $24=25.0 $25=500.0 $26=250 $27=1.000 $28=0.100 $29=0.0 $30=1000.000 $31=0.000 $32=0 $33=5000.0 $34=0.0 $35=0.0 $36=100.0 $37=0 $39=1 $40=0 $43=1 $44=4 $45=3 $46=0 $62=0 $63=2 $64=0 $65=0 $100=250.000 $101=250.000 $102=250.000 $110=500.000 $111=500.000 $112=500.000 $120=10.000 $121=10.000 $122=10.000 $130=200.000 $131=200.000 $132=200.000 $341=0 $342=30.0 $343=25.0 $344=200.0 $345=100.0 $370=0 $372=0 $384=0 $X error:18 - Reset asserted Grbl1.1f ['$' or '$HELP' for help] [MSG:'$H'|'$X' to unlock] $X error:18 - Reset asserted [GC:G0 G54 G17 G21 G90 G94 G49 G98 G50 M5 M9 T0 F0 S0.] [G54:0.000,0.000,0.000] [G55:0.000,0.000,0.000] [G56:0.000,0.000,0.000] [G57:0.000,0.000,0.000] [G58:0.000,0.000,0.000] [G59:0.000,0.000,0.000] [G59.1:0.000,0.000,0.000] [G59.2:0.000,0.000,0.000] [G59.3:0.000,0.000,0.000] [G28:0.000,0.000,0.000] [G30:0.000,0.000,0.000] [G92:0.000,0.000,0.000] [TLO:0.000,0.000,0.000] [PRB:0.000,0.000,0.000:0] [GC:G0 G54 G17 G21 G90 G94 G49 G98 G50 M5 M9 T0 F0 S0.] [VER:1.1f.20220325:] [OPT:VNMSL,35,1024,3,0] [NEWOPT:ENUMS,RT+,TC,SED] [FIRMWARE:grblHAL] [NVS STORAGE:*FLASH] [DRIVER:STM32H743] [DRIVER VERSION:220325] [BOARD:grblHAL reference map] [AUX IO:3,4,0,0] $0=10.0 $1=25 $2=0 $3=0 $4=7 $5=0 $6=0 $7=0 $10=511 $11=0.010 $12=0.002 $13=0 $14=0 $15=0 $16=0 $17=0 $18=0 $19=0 $20=0 $21=0 $22=0 $23=0 $24=25.0 $25=500.0 $26=250 $27=1.000 $28=0.100 $29=0.0 $30=1000.000 $31=0.000 $32=0 $33=5000.0 $34=0.0 $35=0.0 $36=100.0 $37=0 $39=1 $40=0 $43=1 $44=4 $45=3 $46=0 $62=0 $63=2 $64=0 $65=0 $100=250.000 $101=250.000 $102=250.000 $110=500.000 $111=500.000 $112=500.000 $120=10.000 $121=10.000 $122=10.000 $130=200.000 $131=200.000 $132=200.000 $341=0 $342=30.0 $343=25.0 $344=200.0 $345=100.0 $370=0 $372=0 $384=0 [GC:G0 G54 G17 G21 G90 G94 G49 G98 G50 M5 M9 T0 F0 S0.] [G54:0.000,0.000,0.000] [G55:0.000,0.000,0.000] [G56:0.000,0.000,0.000] [G57:0.000,0.000,0.000] [G58:0.000,0.000,0.000] [G59:0.000,0.000,0.000] [G59.1:0.000,0.000,0.000] [G59.2:0.000,0.000,0.000] [G59.3:0.000,0.000,0.000] [G28:0.000,0.000,0.000] [G30:0.000,0.000,0.000] [G92:0.000,0.000,0.000] [TLO:0.000,0.000,0.000] [PRB:0.000,0.000,0.000:0] [GC:G0 G54 G17 G21 G90 G94 G49 G98 G50 M5 M9 T0 F0 S0.] $X error:18 - Reset asserted $X error:18 - Reset asserted $X error:18 - Reset asserted $X error:18 - Reset asserted $X error:18 - Reset asserted

hi, Terje Io, do you have a plan to make stm32h7 driver? I have made grbl circuit board of esp32 for sale, aimed at beginner CNC enthusiasts (they use aluminum plate or aluminum profile to make small desktop cnc), I want to make one more This is a circuit board for professional CNC enthusiasts (they use castings). I think STM32H743VIT6 is very good. This chip is very popular and easy to buy. But I can't program. So do you have a plan to make stm32h7? I will wait

I am working on status lights for my machine and if the machine comes up in STATE_IDLE, it does not appear to fire the onStateChanged event.

However, if it comes up in STATE_ALARM (homing required) it does fire. It would be good to fire a state change during boot and reset events, so anything chained to that trigger has a chance to perform functions at boot/reset.

hi, there are many pins on the f401, it looks a bit wasteful, so I'm going to add some custom M code for switching the io pins, I know you have an example program for adding custom M-codes, but it looks a bit complicated to me, So I changed it directly in the grblhal source code, My status_code_t gc_execute_block(char *block) in gcode.c Added my simple code in the function : case 70: //

         HAL_GPIO_WritePin(GPIOB, GPIO_PIN_3, GPIO_PIN_SET);

break; case 71: //

          HAL_GPIO_WritePin(GPIOB, GPIO_PIN_3, GPIO_PIN_RESET);

break;

Very good, he can run correctly, but HAL_GPIO_WritePin() runs as soon as grblhal receives this code, I don't know where to add it to make grblhal run HAL_GPIO_WritePin() after actually executing the m70 code

I've written a basic plugin using the my_plugin example, as well as fans.c as a reference.

On a state change, it should set aux output pins high or low, depending on the state.

I have added an enable define to my_machine.h and I had added a line to the driver.c to include the header file for my plugin. In the header file I call the init function. The plugin never seems to be called.

Is there was a way via the serial console to see what plugins are loaded and their version (I copied the version reporting from fan.c). I'm fairly certain the plugin is not being triggered, but I am unable to determine why.

Any guidance would be appreciated.

Thanks.

Hello. First, thank you very much for all the work you do for this project! I'm looking for a project that can be used as an electronic lead screw for the lathe with CNC capabilities, so the lathe can be used either in manual mode (with convenient feedrate configuration and other semi-automatic stuff) or CNC mode. All the projects I've found so far was either els-only or cnc-only, so I decided to try to adopt grblHAL to perform els tasks and probably implement it as a plugin with custom control panel, mpg, joystick, display, etc never mind. The idea is to feed grblHAL with commands based on joystick and other inputs state in close to realtime manner. For example, G33 can be used for threading, G93-95 for turning, G1 for async operations like slots or gears, and somehow get the spindle position to use it as a dividing head. My setup is stm32f411 blackpill + 2 steppers + 1800ppr quadrature encoder. The encoder has 3 outputs: 2 pulses with phase shift (A and B) and index (Z). As far as I can see, grblHAL accepts 2 inputs from the encoder (A and Z or B and Z). Looks like it assumes that the rotation is always goes in one direction, so if I enter G33 Z-100 K1, wait for Z to reach -50, stop the spindle and run it in opposite direction, the carriage will still be moving towards Z-100, please correct me if I'm wrong. I understand that full support of reverse rotation is pointless for G33 because it doesn't make sense to run gcode in reverse direction. But I see very common use case in manual turning when you sometimes stop the spindle, measure the part, start it again, turn etc, and when the spindle is stopped, you can accidentally move it backwards a couple of degrees, and the position becomes invalid. To solve this problem, the firmware should use all 3 inputs from the encoder anyway, so the first question is: how hard would be to ignore backward rotation of the spindle (considering 3 inputs), but when it starts spinning forward again, to keep track the thread as it was before? Or probably it would be easier and more correct in general to implement this behaviour as a separate mode/gcode/mcode? The second point is related to the presice configuration of sync point between spindle angle and linear axis position. Sometimes I need to restore a thread, so I need to place the cutter right between the threads, save the "sync position" and run it as usual in sync mode. Sometimes I need to cut a multistart threads, so I need to cut a thread, set new "sync position" 0.2mm farther or 40 degrees farther or so, cut another thread, move it again etc. So the second question is: do you plan to support something like this, or is it easy to achieve this with a plugin? What do you think in general, is it worth to try to make els on top of CNC firmware? Also, what rpm can grblHAL theoretically handle on f411 blackpill with 1800 PPR encoder? Thank you very much, and sorry for a longread

Is it possible to add NXP L4300 as another controller? It may be interesting to use the CIAA (Argentine Open Industrial Computer), designed to be used in industrial environments, open source, can be found on Github, and I can purchase the version with said micro.

I found potential issue in vanilla GRBL https://github.com/gnea/grbl/issues/1178

grblHAL have similar in gcode.c

                    if (!(axis_words.mask & (bit(plane.axis_0)|bit(plane.axis_1))))
                        FAIL(Status_GcodeNoAxisWordsInPlane); // [No axis words in plane]

I used the high-performance teensy4.1 GRBLHAL. Very good performance, really great work.

STM32H7XX series SCM has a high cost performance ratio. Do you consider making a GRBLHAL for H7?