grblhal / core Goto Github PK

Is it possible to modify the acceleration according to the job (something like the modifiers for feed, rapid, rpm) does it require more aggressive or less aggressive acceleration?
Use trochoidal mechanized, there greater acceleration decreases working time.
I also do pcb plate milling, lower acceleration protects the 0.1mm tip (jerk)

I'm working on a new plugin that uses that uses the Output_Aux lines but when I address them it hangs the code.

I am able to use standard Arduino pinMode and digitalWrite commands to write to the pins and they behave as expected - so the pathway is correct electrically.

Is this the correct syntax to have the line go high?

hal.port.digital_out(Output_Aux0, true)

(EDIT: I thought I think I found mistake, the comment above the point referes to true but the actual command wants a bool and it says on. However "on" is not defined but "On" and "Off" are defined. Exploring now.)

Also, I haven't located it yet, but I assume the output pins get set to output mode somewhere or should I be initializing them?

Hello grblHALians!!
After enabling estop, I define estop pin like this "#define ESTOP_PIN (14u)" bit it doesn't seem to work. Kindly guide me on defining it, as I have not seen it in any exmple map file. Further, how to invert it for NO or NC?
Thanks in advance.

Has anyone managed to run grblhal on a Bitsensor bsmceo4u-pp (USB MACH3 100Khz Motion Controller) card? It has a STM32F103RCT6 and it's very cheap!

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 ~

Can't get passed this error.

using latest arduino IDE, and full download from https://github.com/grblHAL/iMXRT1062

I have five limit switches on three inputs to my grblHAL setup.

Xmin, Y1min, Y2min & Y2Max (parallel), Zmax & Zmin (parallel).

I use them for homing to Xmin, Y1min, Y2min (with auto squaring), Zmax and that works properly.

However, when the machine is in operation, if I trigger Y2max at the rear of the machine, I get forced in to a homing cycle. The problem is, I need to manually move off the Y2max sensor first, if I proceed with the homing cycle, since the machine doesn't know the Y2's are in paralell it assumes I am on the front sensor and crashes in to the physical back of the machine. This is understandable, and mentioned in the config.h.

However, a more desireable outcome and what I am used to from 8 bit grbl, is the ability to reset and unlock and electrically move off the sensor and then manually choose to re-home. The problem is I do not have that option right now. I've tried adjusting config options in a fashion that I believe should achieve this, but I have not had success so I wanted to understand what the logic structure is. I may just be misconfigured, or is this not possible?

As an alternative, I have A & B limit switch inputs on my controller board, so I may move Zmin and Y2max to their own inputs, but I am hoping for a config fix if possible.

Also, given that we know where the machine is in absolute space when it crashes, I'm wondering if it would be feasible to extend the logic to support parallel switches by deriving which switch is likely tripped based on the absolute machine position. If I'm at the back of my travel and I trigger Y's limit switch, would it be safe to assume it was the rear switch? Perhaps have a percent of total travel distance that if you're within that % (5%? 10%) of that absolute location then trigger?

Alternatively, could perhaps an initial config cycle could be run after the switches are set up and initial home is defined, where the machine slowly seeks in each direction and locates the switches and stores their location to a config variable for this purpose?

I should note that I do not currently have soft limits configured. I need to return to that, but I was having issues where the soft limits were being applied to the WCS and not the machine absolute position, leading to strange limits on travel. I am in the midst of changing spindles so once I am back up and running I will do more thorough QA on the soft limits piece.

My preferred workflow would be:

1. On initial power-on, as a configurable option, to in to falt mode and require homing. (Already present but want to QA it once I resolve other issues).

2. On limit switch trigger, allow unlock but enter a new state where job motion is enabled but program execution is blocked until the system is reset and re-homed.

This would allow the operator to move off limits or reposition out of a crash in a work piece (something I've also had problems doing when a bit got stuck in a metal cut and my only option was to allow the Z to rip upwards inside the homing sequence and it lifted things right off the wasteboard).

Exiting this jog limited state with a reset would then require a homing sequence (if so configured).

Thoughts?

Hi Friends,
I want to propose a new Logo:

If you like it I can send the svg.

Terje,

I'd like to propose the idea of an formal API in to the grblHAL core via an official plugin that defines the functions available, applies restrictions and safety checks needed, and defines the physical interface type(s) for optional connection in to grblHAL.

Serial an i2c are exposed today and can likely cover most applications. Possibly also having USB on the roadmap as an additional option at the hardware layer might be something to consider as well, as that brings both higher bandwidth and also a large variety of pre-existing USB devices to the table.

With so much flexibility and potential in grblHAL, the opportunity for creative development (and use) beyond grbl's core user base and applications is significant and it would help showcase how grblHAL is a generational leap beyond grbl in terms of extensibility.

As an example, the availability of the second serial interface and the ease and elegance of wiring it up to the existing Keypad plugin had me thinking overnight about exploring getting the Xbox One BT controller , working directly via the Pi. I had used this on a previous grbl system via Universal GCode Sender on Windows. The Xbox controller brings better start/stop feedback from the sticks etc. and I believe support on the Pi/Linux side is well established, but it would be great if any work done in this regard was largely re-usable for other types of controllers.

Zooming out, as you demonstrated with your MPG work, a secondary interface could support up to (and beyond?) the capability of a full sender by handshaking with the core and determining that it is safe to take over authority from any existing sender on the primary interface. I was discussing it a bit with Drew and he made the important observation that "There has to be a priority and arbitration." between the two.

Also, by making both the (optional) hardware and software interfaces more formal, board designers can choose to include them or not in their designs, but they can be promoted and plugin work (on both the grblHAL and remote device side) can more easily be shared and improved by a wider audience, regardless of their grblHAL driver.

I am happy to help contribute to the effort if you think it has merit.

Is it possible to have 2 different pwm pin for spindle and laser triggered by the $32 variable? I would like to have both spindle and laser mounted on machine at the same time without any firmware update.
as previously discussed here fra589/grbl-Mega-5X#112

Curious if anyone else here is using CNCjs with grblHAL.

I had used it previously with grblMEGA 5x without any issues.

When I went to run a job (after getting back from 3 weeks of vacation) I decided to try CNCjs (as I have some tool length setting macros I really want to use). I noticed that the DRO doesn't seem to be updating properly.

When I ran my macros they would start off correctly but then start behaving oddly and that's when I noticed the values on the DRO weren't updated, either for tool length or corner finding.

I opened the console within CNCjs and as soon as I issued the ? status command, the DRO populated, however running the macro again resulted in the same issue.

I'm fairly certainly the frequency of the ? commands being issued is a client issue, but I'm unable to think of any reason that they would work with grblMEGA and not with grblHAL, since the board seems to respond just fine when I issue it by hand. Are there any situations during normal operation that block responses to the ?.

Any suggestions on where to look greatly appreciated.

Hi,

I'm curious what is the current workflow for tool changes at Automatic touch off @ G59.3 ($341=3) mode? Wiki has two places with descriptions( https://github.com/grblHAL/core/wiki/Additional-or-extended-settings , https://github.com/grblHAL/core/wiki/Manual,-semi-automatic-and-automatic-tool-change ) but they are not reflecting actual state of things. From wiki I had impression that firstly tool is moved to home position for physical change then it moved to G59.3 offsets for automatic touch off but my tests revealed that there no move to home position just lift in Z direction, then after Cycle Start tool is moved to G59.3 offsets.

Maybe there was some discussions about semi-automatic changes in grblHAL? Looks like search engine on github was changed recently and searching for anything has become quite difficult :-(

Also are tool changes in semi-automatic mode g-code sender dependent? How could I understand that sender handles tool changes correctly?

I'm trying to configure STM32F4 driver with custom BOB for BlackPill on my router setup(bCNC on rpi3 under NetBSD), I'm using latest bCNC sender, grblHAL configuration is:

$I
[VER:1.1f.20210608:]
[OPT:VNS2,35,1024,3,0]
[NEWOPT:ENUMS,RT+,HOME,TC]
[FIRMWARE:grblHAL]
[NVS STORAGE:*EEPROM]
[DRIVER:STM32F411]
[DRIVER VERSION:210606]
[BOARD:Custom BlackPill STMF411]
[PLUGIN:KEYPAD v1.00]

$#
[G54:-73.974,-317.996,-69.671]
...
[G59.3:-293.000,-17.000,-30.000]
[HOME:-299.000,-353.000,-2.000:7]
[TLO:0.000,0.000,-14.442]
[PRB:-293.004,-16.995,-78.005:1]

I'm not sure why TLR reference was removed from parameters here after second tool change and replaced with TLO.

$$
$0=10.0
$1=25
$2=0
$3=5
$4=0
$5=0
$6=0
$7=0
$10=511
$11=0.010
$12=0.002
$13=0
$14=7
$15=0
$16=0
$17=0
$18=0
$19=0
$20=1
$21=0
$22=5
$23=3
$24=30.0
$25=1500.0
$26=10
$27=2.000
$28=0.100
$29=0.0
$30=4800.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
$50=100.0
$51=600.0
$52=3000.0
$53=0.250
$54=500.0
$55=3000.0
$62=0
$63=2
$64=0
$65=0
$80=1.000
$81=0.010
$82=0.000
$84=0.000
$85=10.000
$90=0.000
$91=0.000
$92=0.000
$95=0.000
$100=33.334
$101=66.726
$102=199.077
$110=9610.000
$111=9610.000
$112=2550.000
$120=110.000
$121=110.000
$122=110.000
$130=301.000
$131=355.000
$132=85.000
$170=0.000
$171=0.000
$172=0.000
$341=3
$342=50.0
$343=30.0
$344=120.0
$345=120.0
$347=3.0
$348=2.500
$349=25.000

I have a quick question on the use of the hal.port.wait_on_input function.

I have a switch connected to Aux_In0 that connects the signal pin to ground when pushed. The function works correctly when the wait mode is '0' / immediate but I have not been able to get any other condition to work. Ideally I would like to trigger on low or falling but the board becomes inaccessible if I use them.

Would you be able to confirm the correct syntax to use the function to read a momentary button with debounce on a falling or low trigger condition?

Thanks,

 if (hal.port.wait_on_input(1, 0, 0, 0)) {
        if (inspection_light_on == 0) {
        inspection_light_on = 1;
        }
        else {
            inspection_light_on = 0;
        }
    }

I can write some debounce myself but it seems like the purpose of the function is to provide some debounce filtering already?

Thanks.

For SAM3X8E, remove the plasma plugin to make openpnp work.
Let driver.c ready with
#ifdef OPENPNP_ENABLE
openpnp_init ();
#end if
Okay, to just uncomment in may_machine?
Hug.

Working through my alarm indicator code, I discovered that the reset/e-stop button escaped my handler and then I realized that while the e-stop is state_alarm:10 (as showin in IOSender), it actually sets STATE_ESTOP.

I was just curious what the thinking is behind having both STATE_ALARM:10 and STATE_ESTOP?

I found this website by accident, https://www.grbl.org/single-post/how-fast-can-it-go
This article is very good, he solved my doubts for a long time for me, how many khz grbl,
In fact, I don’t care how much Khz it is, but customers who buy my grbl board often ask me this question.
I have purchased a 30 RMB USB logic analyzer to try it.

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.

The templates you recently added are great, but I haven't been able to get the user mcode example one to work. I was wondering if you could take a look and see if there is something obvious that is wrong. I copied and edited your code. It compiles fine within my tree.

I am calling the mcode from the MDI in IOSender with: M356 Q1 and I receive ok but nothing visible happens.

Is this the correct way to call it? I'm new to user mcodes.

I have temporarily added an entry in gcode.h that looks like this:
RGB_Inspection_Light = 356, //!< 356 - M356 // ** Collides with Plasma ** On = 1, Off = 2, RGB white LED inspection light in RGB plugin

I am not currently including the plasma module and I don't see the plasma codes defined in this file, but I did notice that $356 is referred to on the github summary page. Is this possibly the issue?

Here is the code section:

// check - check if M-code is handled here.
// parameters: mcode - M-code to check for (some are predefined in user_mcode_t in grbl/gcode.h), use a cast if not.
// returns:    mcode if handled, UserMCode_Ignore otherwise (UserMCode_Ignore is defined in grbl/gcode.h).
static user_mcode_t check (user_mcode_t mcode)
{
    return mcode == RGB_Inspection_Light 
                     ? mcode                                                            // Handled by us.
                     : (user_mcode.check ? user_mcode.check(mcode) : UserMCode_Ignore); // If another handler present then call it or return ignore.
}

// validate - validate parameters
// parameters: gc_block - pointer to parser_block_t struct (defined in grbl/gcode.h).
//             gc_block->words - holds a bitfield of parameter words available.
//             If float values are NAN (Not A Number) this means they are not available.
//             If integer values has all bits set to 1 this means they are not available.
// returns:    status_code_t enum (defined in grbl/gcode.h): Status_OK if validated ok, appropriate status from enum if not.

static status_code_t validate (parser_block_t *gc_block, parameter_words_t *deprecated)
{
    status_code_t state = Status_GcodeValueWordMissing;

    switch(gc_block->user_mcode) {

        case RGB_Inspection_Light:
            if(gc_block->words.p && !isnan(gc_block->values.p))             // Check if P parameter value is supplied.
                state = Status_BadNumberFormat;                             // Return error if so.

            if(gc_block->words.q && isnan(gc_block->values.q))              // Check if Q parameter value is supplied.
                state = Status_BadNumberFormat;                             // Return error if not.

            if(state != Status_BadNumberFormat && gc_block->words.q) {      // Are required parameters provided?
                if(gc_block->values.q > 0.0f && gc_block->values.q <= 5.0f) // Yes, is Q parameter value in range (1-5)?
                    state = Status_OK;                                      // Yes - return ok status.
                else
                    state = Status_GcodeValueOutOfRange;                    // No - return error status.
                if(gc_block->words.q)                                       // If P parameter is present set
                    gc_block->values.p = 1.0f;                              // value to 1 for execution.
                gc_block->words.p = gc_block->words.q = Off;                // Claim parameters.
                gc_block->user_mcode_sync = true;                           // Optional: execute command synchronized
            }
            break;

        default:
            state = Status_Unhandled;
            break;
    }

    // If not handled by us and another handler present then call it.
    return state == Status_Unhandled && user_mcode.validate ? user_mcode.validate(gc_block, deprecated) : state;
}

// execute - execute M-code
// parameters: state - sys.state (bitmap, defined in system.h)
//             gc_block - pointer to parser_block_t struct (defined in grbl/gcode.h).
// returns:    -
static void execute (sys_state_t state, parser_block_t *gc_block) {

    bool handled = true;

    switch(gc_block->user_mcode) {

        case RGB_Inspection_Light:
            // do something: Q parameter value can be found in gc_block->values.q.
            //               P parameter has its value in gc_block->values.p set to 1 if present, NAN if not.
            if (gc_block->values.q == 1) {
                rgb_set_state(RGB_WHITE);
            }
            else {
                if (gc_block->values.q == 2)
                   rgb_set_state(RGB_OFF);
            }
            break;

        default:
            handled = false;
            break;
    }


    if(!handled && user_mcode.execute)          // If not handled by us and another handler present
        user_mcode.execute(state, gc_block);    // then call it.
}

And I have the relevant sections in my init function:

`void my_plugin_init() // Init function called from drivers_init()
{
    if(hal.port.num_digital_out >= 3) {

        hal.port.num_digital_out -= 3;  // Remove the our outputs from the list of available outputs
        base_port = hal.port.num_digital_out;

        if(hal.port.set_pin_description) {  // Viewable from $PINS command in MDI
            uint32_t idx = 0;
            do {
                hal.port.set_pin_description(true, true, base_port + idx, rgb[idx]);
                if (idx == 0) { red_port = idx; } else
                if (idx == 1) { blue_port = idx; } else
                if (idx == 2) { green_port = idx; }
                idx++;                
            } while(idx <= 2);
        }
        startMS = hal.get_elapsed_ticks();

        // Save away current HAL pointers so that we can use them to keep
        // any chain of M-code handlers intact.
        memcpy(&user_mcode, &hal.user_mcode, sizeof(user_mcode_ptrs_t));

        // Redirect HAL pointers to our code.
        hal.user_mcode.check = check;
        hal.user_mcode.validate = validate;
        hal.user_mcode.execute = execute;
       
        driver_reset = hal.driver_reset;                // Subscribe to driver reset event
        hal.driver_reset = driverReset;

        on_report_options = grbl.on_report_options;     // Subscribe to report options event
        grbl.on_report_options = onReportOptions;

        on_state_change = grbl.on_state_change;         // Subscribe to the state changed event by saving away the original
        grbl.on_state_change = onStateChanged;          // function pointer and adding ours to the chain.

        on_realtime_report = grbl.on_realtime_report;   // Subscribe to realtime report events AKA ? reports
        grbl.on_realtime_report = onRealtimeReport;     

        on_program_completed = grbl.on_program_completed; // Subscribe to on program completed events (lightshow on complete?)
        grbl.on_program_completed = onProgramCompleted;   // Not using this yet, will add back if needed

        on_execute_realtime = grbl.on_execute_realtime;     // Subscribe to the realtime execution event
        grbl.on_execute_realtime = realtimeIndicators;      // Spindle monitoring, flashing LEDs etc live here

    } else
        protocol_enqueue_rt_command(warning_msg);
}`
 

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

Hello, i found a small error in the file limits.c
I think, the correct code is:
float fail_distance = (-settings.homing.dual_axis.fail_length_percent / 100.0f) * settings.axis[dual_motor_axis].max_travel;
fail_distance = min(fail_distance, settings.homing.dual_axis.fail_distance_max);
fail_distance = max(fail_distance, settings.homing.dual_axis.fail_distance_min);
Bye..

I have a new teensy based grblhal system up and running. Great stuff.

I am working my way through the config to get me back to parity on my previous Arduino Mega 6x build and one of the things that I had changed was the default MPos being 0,0,0 after homing.

Homing on my machine goes to the front left corner and I have my tool touch-off plate there as well, and would like this to be MPos 0,0,0. In config.h there is the define:

// After homing, Grbl will set by default the entire machine space into negative space, as is typical
// for professional CNC machines, regardless of where the limit switches are located. Set this
// define to 1 to force Grbl to always set the machine origin at the homed location despite switch orientation.
#define HOMING_FORCE_SET_ORIGIN // Default disabled. Uncomment to enable.

I have uncommented this, built and flashed but my MPos isn't being reset to 0,0,0 after flashing (this define does do that in grbl-mega).

I also tried:

#define HOMING_FORCE_SET_ORIGIN 1

That did not reset MPos either, I'm still getting:

<Idle|MPos:-1109.000,-927.000,-6.000|Bf:35,1023|FS:0,0>

Any suggestions on what to try next?

Hi, I'm having problems with accelstepper and it's lack of acceleration when using multiple steppers at the same time. So I was thinking of taking the code straight out of marlin/grbl. How should I do this? I'm reading the code and trying to understand it but it has a lot of excess.

Is there any way to use the motion code easily?
I have saved positions like this in my code
[axis1][axis2][axis3][position1]
[axis1][axis2][axis3][position2]
[axis1][axis2][axis3][position3]

From my limited knowledge, I have determined that grbl can look ahead and plan for the next movements. But I have no idea how I would go about doing this.

Thank you for your time!

There is an error in the configuration of the motor current at routine "mks_set_current" in the file mks_sbase.c
The correct line is:
static const uint8_t wiper_registers[] = {0x00, 0x01, 0x06, 0x07};

Starting to work on the aux-in code and I was looking for a way to display the state of all input pins. I was hoping the $PINS command might show that, but it only lists assignments at the moment.

Is there an existing way to show the status of all (input) pins?

Also, the $PINS command doesn't show up in $? as an option, is there a way to show an extended list of all available console commands?

Enter ""G1G91Z1.55F200" again, it will be correct 3.1, which is 1.55*2=3.

1

In General, G51 scaling requires a scaling centre defined by X, Y, Z and scaling factors for each axis defined by I, J, K.
(According to: https://cnc-programming-tips.blogspot.com/2014/12/g50-and-g51-scaling-and-mirroring.html#:~:text=G51%20scales%20program%20G%2Dcodes,%2C%20Y%2C%20and%20Z).&text=A%20G51%20applies%20scaling%2Fmirror,value%20I%2C%20J%2C%20K.)

I tested this in grblHal (stm32f103) and it is not working that way.
After some experiments, here are my observations:
The G51 command with X,Y, I, J parameters results in error:36 (Unused value words found in block.)
After hit and trial I found that I,J are not supported, but X,Y are used to scale axis (Maybe the center point is always 0,0)
This means that "G51 X0 Y0 I1.5 J0.5" should be written as "G51 X1.5 Y0.5"

This not a very bad news, but real big problem is that the arcs (G2 and G3) are not scaled. (only G2 was tested)
(To be more specific, the X,Y,I,J parameters of arc are only scaled. Considering unequal scaling of X and Y, If it was a semicircle, (means starting, center, and ending points are collinear) then the arc is made circular but not elliptical as it should be. if not a semicircle, then program gives error complaining that the centre is not correct. (error:33))

So, Scaling does work if G code does not has Circular arcs (G2 or G3)

Otherwise, it will only work if scaling is equal in All axes.

Although I have not tested G5 cubic splines, but they should be fine as the control points will also be scaled. (Maybe, but I dont know)

For example, like this, show the user the G code line currently executed by grbl, instead of the line that has been sent out

real-time report FS delivers a maximum value of 1000 for rpm (on the other hand, when the information is in F and S mode it is the correct value) I am interested in being able to add a field in the GUI (currently bCNC) to display the rpm while the machine is working. Can you correct this? Thanks, hugs.

I have the regular Z and then XY homing setup. Unfortunately, I swapped the X and Z switches and didn't notice it when testing the proper functioning of the switches. I wasn't able to react fast enough and broke the mount on my Z limit switch. No big deal and my own fault.

But I feel that especially when grblhal is moving in a known direction and a limit switch on another axis is triggered it should abort the mission. Cause there is always gonna be a dingus like me that messes up and breaks something.

see the below comment, expansion of PINMODE_OD is failing for some odd reason

3a84b58#commitcomment-51905150

here's the platformio.ini

[platformio] 
src_dir = src
lib_dir = src

[env:LPC176x] 
platform          = https://github.com/p3p/pio-nxplpc-arduino-lpc176x/archive/0.1.3.zip
platform_packages = framework-arduino-lpc176x@^0.2.5
framework         = arduino
board             = nxp_lpc1769
lib_ldf_mode      = chain+
lib_compat_mode   = strict 
lib_archive = yes 

src_filter = +<./*/*>
;            =-<./src/eeprom>
build_flags =
    ; -Isrc/eeprom
    -Isrc/FatFs
    -Isrc/grbl 
    -Isrc/grbl-lpc 
    -Isrc/lpc_chip_175x_6x
    -Isrc/lpc_chip_175x_6x/inc
    -Isrc/lpc_chip_175x_6x/inc/usbd
    -Isrc/lpc17xx
    -DN_AXIS=3
    -DUSB_ENABLE=1
    -DEEPROM_ENABLE=0
    -DUSE_HAL_DRIVER
    -DOVERRIDE_MY_MACHINE
    ; -DCHIP_LPC175X_6X
    -DCORE_M3
    -D__LPC17XX__
    -DBOARD_BTT_SKR_1.4_TURBO
    -D __USE_CMSIS=CMSIS_CORE_LPC17xx
    -D NO_BOARD_LIB
;     -Wl,-Map,output.map
    ; -v

It is the G code generated by the post-processing, and I have been using it in the machining center of the FANUC CNC system, and there is no problem

Presently I'm debugging an issue around configuration of the project.

Unfortunately, this is excessively hard to do based on how commit history is being written. As an example, when evaluating git blame on changelog.md, there are only two commits present. Comparing this with https://github.com/terjeio/grblHAL/blame/master/changelog.md reveals the actual change history.

During a g0 seek in M3 laser mode, the spindle (laser) can be turned on if subsequent g1 commands are fed to the planner.
This seems to be a consequence of line 195 in motion_control.c.
At this point in the code, the spindle state of future "planned" moves are immediately synchronized to the machine.
Not sure why this would be there, but it doesn't seem correct (and causes unintended laser cuts to be made across the workpiece) !

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 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.

What functions and hardware resources need to change or use to porter to STM32L476. I have them more than 100 pieces.

PlatformIO prompted me to update my teensy platform from 4.12 to 4.13.

Now I am getting errors on my compile that I wasn't getting previously (haven't updated any files and don't use the SD module).

I see there is some history around isssues with the SD module compiling for the teensy but since it pretty much worked out of the box before, I'm a bit confused what has changed or how to resolve it.

The errors:

Compiling .pio\build\teensy41\lib9f7\uSDFS\utility\sd_spi.c.o
In file included from .pio\libdeps\teensy41\MSC-non-blocking\src\msc.h:31:0,
                 from .pio\libdeps\teensy41\MSC-non-blocking\src\MassStorageHost.cpp:31:
C:\Users\xxxxx\.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2045:2: error: 'msSCSICapacity_t' does not name a type
  msSCSICapacity_t msCapacity;
  ^
C:\Users\xxxxx\.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2046:2: error: 'msInquiryResponse_t' does not name a type  
  msInquiryResponse_t msInquiry;
  ^
C:\Users\xxxxx\.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2047:2: error: 'msRequestSenseResponse_t' does not name a type
  msRequestSenseResponse_t msSense;
  ^
C:\Users\xxxxx\.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2048:2: error: 'msDriveInfo_t' does not name a type        
  msDriveInfo_t msDriveInfo;
  ^
C:\Users\xxxxx\.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2067:31: error: 'msSCSICapacity_t' has not been declared   
  uint8_t msReadDeviceCapacity(msSCSICapacity_t * const Capacity);
                               ^
compilation terminated due to -fmax-errors=5.
In file included from .pio\libdeps\teensy41\MSC-non-blocking\src\msc.h:31:0,
                 from .pio\libdeps\teensy41\MSC-non-blocking\src\MassStorageDriver.cpp:29:
C:\Users\xxxxx\.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2045:2: error: 'msSCSICapacity_t' does not name a type     
  msSCSICapacity_t msCapacity;
  ^
C:\Users\xxxxx\.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2046:2: error: 'msInquiryResponse_t' does not name a type  
  msInquiryResponse_t msInquiry;
  ^
C:\Users\xxxxx\.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2047:2: error: 'msRequestSenseResponse_t' does not name a type
  msRequestSenseResponse_t msSense;
  ^
C:\Users\xxxxx\.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2048:2: error: 'msDriveInfo_t' does not name a type        
  msDriveInfo_t msDriveInfo;
  ^
C:\Users\xxxxx\.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2067:31: error: 'msSCSICapacity_t' has not been declared   
  uint8_t msReadDeviceCapacity(msSCSICapacity_t * const Capacity);
                               ^
compilation terminated due to -fmax-errors=5.
Compiling .pio\build\teensy41\libd78\lwip\api\api_lib.c.o
In file included from .pio\libdeps\teensy41\MSC-non-blocking\src/msc.h:31:0,
                 from .pio\libdeps\teensy41\uSDFS\src\utility\sd_msc.cpp:41:
C:\Users\xxxxx\.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2045:2: error: 'msSCSICapacity_t' does not name a type     
  msSCSICapacity_t msCapacity;
  ^
C:\Users\xxxxx\.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2046:2: error: 'msInquiryResponse_t' does not name a type
  msInquiryResponse_t msInquiry;
  ^
C:\Users\xxxxx\.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2047:2: error: 'msRequestSenseResponse_t' does not name a type
  msRequestSenseResponse_t msSense;
  ^
C:\Users\xxxxx\.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2048:2: error: 'msDriveInfo_t' does not name a type        
  msDriveInfo_t msDriveInfo;
  ^
C:\Users\xxxxx\.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2067:31: error: 'msSCSICapacity_t' has not been declared   
  uint8_t msReadDeviceCapacity(msSCSICapacity_t * const Capacity);
                               ^
compilation terminated due to -fmax-errors=5.
*** [.pio\build\teensy41\lib5ae\MSC-non-blocking\MassStorageHost.cpp.o] Error 1
*** [.pio\build\teensy41\lib5ae\MSC-non-blocking\MassStorageDriver.cpp.o] Error 1
*** [.pio\build\teensy41\lib9f7\uSDFS\utility\sd_msc.cpp.o] Error 1
=============================================================== [FAILED] Took 4.48 seconds ===============================================================

hi, i'm new.
i'm using arduino wht grbl.
now, for a increase speed of engraving, try to use a samd based arduino zero board.
i know previuous issue, i use arduino ide 1.6.11, wht driver samd 1.6.12.
compiling i have an error wht serial.
undefined reference to stream_rx_backup(stream_rx_buffer_t*)'`

all error code is:
`Arduino:1.6.11 (Linux), Scheda:"Arduino/Genuino Zero (Native USB Port)"

Opzioni di compilazione cambiate, ricompilo tutto
/home/piro/Arduino/libraries/grblHAL_MKRZERO/src/driver.c: In function 'STEPPER_IRQHandler':
/home/piro/Arduino/libraries/grblHAL_MKRZERO/src/driver.c:1089:5: warning: assignment of read-only location '1107308544u->COUNT32.INTFLAG.bit.MC0' [enabled by default]
STEPPER_TIMER->COUNT32.INTFLAG.bit.MC0 = 1;
^
/home/piro/Arduino/libraries/grblHAL_MKRZERO/src/driver.c: In function 'STEPPULSE_IRQHandler':
/home/piro/Arduino/libraries/grblHAL_MKRZERO/src/driver.c:1096:5: warning: assignment of read-only location '1107307520u->COUNT16.INTFLAG.bit.MC0' [enabled by default]
STEP_TIMER->COUNT16.INTFLAG.bit.MC0 = 1;
^
/home/piro/Arduino/libraries/grblHAL_MKRZERO/src/driver.c: In function 'STEPPULSE_Delayed_IRQHandler':
/home/piro/Arduino/libraries/grblHAL_MKRZERO/src/driver.c:1103:5: warning: assignment of read-only location '1107307520u->COUNT16.INTFLAG.bit.MC0' [enabled by default]
STEP_TIMER->COUNT16.INTFLAG.bit.MC0 = 1;
^
/home/piro/Arduino/libraries/grblHAL_MKRZERO/src/driver.c: In function 'DEBOUNCE_IRQHandler':
/home/piro/Arduino/libraries/grblHAL_MKRZERO/src/driver.c:1118:5: warning: assignment of read-only location '1107305472u->INTFLAG.bit.OVF' [enabled by default]
DEBOUNCE_TIMER->INTFLAG.bit.OVF = 1;
^
/home/piro/Arduino/libraries/grblHAL_MKRZERO/src/serial.c:32:0: warning: "PIN_SERIAL1_RX" redefined [enabled by default]
#define PIN_SERIAL1_RX (13ul)
^
In file included from /home/piro/.arduino15/packages/arduino/hardware/samd/1.6.12/cores/arduino/delay.h:27:0,
from /home/piro/.arduino15/packages/arduino/hardware/samd/1.6.12/cores/arduino/Arduino.h:81,
from /home/piro/Arduino/libraries/grblHAL_MKRZERO/src/serial.c:26:
/home/piro/.arduino15/packages/arduino/hardware/samd/1.6.12/variants/arduino_zero/variant.h:122:0: note: this is the location of the previous definition
#define PIN_SERIAL1_RX (0ul)
^
/home/piro/Arduino/libraries/grblHAL_MKRZERO/src/serial.c:33:0: warning: "PIN_SERIAL1_TX" redefined [enabled by default]
#define PIN_SERIAL1_TX (14ul)
^
In file included from /home/piro/.arduino15/packages/arduino/hardware/samd/1.6.12/cores/arduino/delay.h:27:0,
from /home/piro/.arduino15/packages/arduino/hardware/samd/1.6.12/cores/arduino/Arduino.h:81,
from /home/piro/Arduino/libraries/grblHAL_MKRZERO/src/serial.c:26:
/home/piro/.arduino15/packages/arduino/hardware/samd/1.6.12/variants/arduino_zero/variant.h:123:0: note: this is the location of the previous definition
#define PIN_SERIAL1_TX (1ul)
^
/home/piro/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld: warning: changing start of section .bss by 16 bytes
/home/piro/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld: warning: changing start of section .bss by 16 bytes
/home/piro/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld: warning: changing start of section .bss by 16 bytes
libraries/grblHAL_MKRZERO/usb_serial.cpp.o: In function usb_serialSuspendInput': /home/piro/Arduino/libraries/grblHAL_MKRZERO/src/usb_serial.cpp:180: undefined reference to stream_rx_suspend(stream_rx_buffer_t*, bool)'
libraries/grblHAL_MKRZERO/usb_serial.cpp.o: In function usb_execute_realtime': /home/piro/Arduino/libraries/grblHAL_MKRZERO/src/usb_serial.cpp:206: undefined reference to stream_rx_backup(stream_rx_buffer_t*)'
collect2: error: ld returned 1 exit status
exit status 1
Errore durante la compilazione per la scheda Arduino/Genuino Zero (Native USB Port).

Questo report potrebbe essere più ricco di informazioni con l'opzione
"Mostra un output dettagliato durante la compilazione"
abilitata in File -> Impostazioni
`

Hey! I'm writing a plugin for a DIY ATC.

When looking through the current tool change code, it doesn't seem like I can easily plug into the logic without modifying at least the tool_change.c logic to account for an ATC plugin (And adding an ATC entry in toolchange_mode_t)

Would this be the correct way to approach this?
The idea is to have GRBL move the Z axis out of the way, send a command either through UART or I2C to a different board that handles rotating of the tool umbrella, swapping the tool and giving control back to GRBL for probing once done.

I'd want this to result in an eventual pull request with example skeleton code in the near future hence I'm asking if my approach is right!

Is there a NULL left over?

Hello,
today I compiled your great software, but somehow pin PA2 is not working. All the other Axix are working. My PCB is correct, I tested every pin on my CPU and I can toggle PA2 through other software.

I uploaded the machine file, in a zip file.
Have a nice Day

AIO.zip

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?

Is seems that a few new variables/functions (Which I suspect are only relevant in some options/plug-ins) are throwing-up warnings on compilation that they declared but unused....

Compiler output:

......Documents\Arduino\libraries\grblHAL_Teensy4\src\driver.c: In function 'driver_delay_ms':
C:\Users\Neil\Documents\Arduino\libraries\grblHAL_Teensy4\src\driver.c:574:39: warning: implicit declaration of function 'state_get' [-Wimplicit-function-declaration]
grbl.on_execute_delay(state_get());
^
In file included from .....Documents\Arduino\libraries\grblHAL_Teensy4\src\driver.c:73:0:
....Documents\Arduino\libraries\grblHAL_Teensy4\src\driver.c: At top level:
....Documents\Arduino\libraries\grblHAL_Teensy4\src\grbl/motor_pins.h:696:13: warning: 'motor_iterator' defined but not used [-Wunused-function]
static void motor_iterator (motor_iterator_callback_ptr callback)
^
....Documents\Arduino\libraries\grblHAL_Teensy4\src\ioports.c:37:42: warning: 'analog_n_in' defined but not used [-Wunused-variable]
static uint_fast8_t aux_n_in, aux_n_out, analog_n_in, *in_map = NULL, *out_map = NULL;;

Hello wonderful developers of this project..
I want to ask whether I can configure both side limit switches of any Axis separately? This I am asking because right now I am using grbl_esp32 and enabled 2 limit switches on axis but it takes single input out of both switches. This creates problem when any limit is switched and machine is powered on. It forgets which side to home :)
If separate limits can be input for each axis, kindly guide me How. FYI, I am using Teensy4.1 with customized PCB (yet to be designed)
Thanks in advance.

I did a fresh clone today and wanted to add my status_light plugin back in to my build.

I see the new wording in plugins.h in the grbl directory and I renamed my code status_light.c and put it in the same directory as driver.c as instructed. I also renamed my init function to be status_light_init().

When I try and compile, I get the following error:

.pio\build\teensy41\src\driver.c.o: In function driver_init': C:\Users\jac1d\Documents\PlatformIO\Projects\2022\iMXRT1062\grblHAL_Teensy4/src\grbl/plugins_init.h:101: undefined reference to status_light_init'
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\teensy41\firmware.elf] Error 1

I think it is probably a simple path or other issue, but can't see what is wrong. Any ideas?

I have to head out of town for a few weeks so I wanted to push this out before I left, for folks to try and comment on in August and hopefully there will be some helpful feedback for when I return.

I have developed a plugin for grblHAL that controls a basic set of 12V LED strip lights that are readily available from Amazon, via relays connected to AUX Out ports. The setup costs ~$40 and does not use any PWM, just simple relays.

Visual indicators are a real quality of life improvement and also aid in machine safety.

This is my first attempt at writing in C and I had not intended to put the code out without cleaning it up and reorganizing it but I would rather get it out than wait a month. Constructive feedback welcome, beginner mistakes should be expected.

A quick summary:

> CURRENTLY WORKING:
> ------------------
> 
> Basic State Status Lights:
> 
> MACHINE STATE       COLOR
> -------------------------------------
> Idle                Cool Blue (Solid)   -> Machine is ready
> Homing              Yellow (Solid)      -> Machine is inside HOMING state (other ops blocked)
> Jogging             Green (Solid)       -> Machine is in motion, no spindle on
> Cycle Running       Magenta (Solid)     -> GCode is being executed
> Hold                Yellow (Flashing)   -> Machine is in hold state (no conditions present)
> Alarm               3 Red Flashes followed by various indicators for alarm detail
> E-Stop              2 Red flashes then red/blue flashes
> 
> CONDITIONS          COLOR
> -------------------------------------
> Spindle On          Red (Solid) [overrides idle/homing/jogging/cycle state lights]
> Flood & Mist        Magenta (may switch to Cyan to avoid conflict with cycle, or may flash)
> Inspection Lights   White (accesed via MCode 356), intend to add physical momentary button too
>     M356 Q1 (for on)
>     M356 Q2 (for off)

The full readme is available here: https://github.com/5ocworkshop/grblhal-rgb-plugin/blob/main/rgb_plugin_readme.txt

The source is available here: https://github.com/5ocworkshop/grblhal-rgb-plugin

Finally, a big thank you to Terje for his patience and helpful answers as I have worked my way through this.

I made a surprising discovery tonight.

I was working on the code for flashing the lights when an alarm is raised and it wasn't working at all, or so it appeared.

If you connect to the machine, home and then intentionally trigger a limit sensor I was getting the correct light sequence for homing, idle and the limit event - but then the IOSender UI and the ? status line both claim Alarm:1 but my code wasn't triggering.

I discovered this, because on a whim I changed my STATE_ALARM to STATE_IDLE in my light code and was surprised to discover the code works fine, the machine state is the unexpected surprise. I get a momentary (onStateChanged) hit on the limit trigger, then I get the flasging event tied to STATE_IDLE.

I would think it is not expected behaviour to set the STATE_IDLE flag before the Alarm condition is cleared?

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.

Hello Terjeio. I have downloaded your latest version for Arduino Due. I can't remember or find in which file I should define the axes A_axis, B_axis and C_axis (I have defined in grbl N axis 6).
Can you guide me? Thanks, hug.

I'm coming from Marlin, which compiles in VS Code out of the box, and have no experience using C compilers beyond following the occasional how-to.

Is there anyone who can create and push a pre-configured platformio.ini for this project with support for the most popular boards?

I've read the Wiki here on how to compile with PlatformIO but it is super vague, and skips a lot of steps and board-specific items that only those who don't need a Wiki to begin with know of. Making a Wiki how-to meant for pros kind of defeats the purpose of a Wiki how-to.

Is there someone who can add platformio support for those of us who don't live and bleed C, but just want to build a CNC?

For reference, I'm trying to build for an SKR 1.3 board, but I'm hoping a robust platformio.ini implementation won't need to be tweaked per-board, like how the Marlin implementation works: you just change the board ID and hit compile.

Thanks.