Where in the code is G94 G1 XA feedrate situation assigned to X while A is coordinated to move with it

[bLouChip]

I'm using another grbl version on a mega2560, and it has a bug whereby on G94 G1 XA moves, the linear feedrate value seems to be assigned incorrectly to the A axis rather than X. Of course A is expecting degs/min units. The spec on this situation is here: http://linuxcnc.org/docs/html/gcode/machining-center.html#_feed_rate
So I'm assuming grblHAL has implemented this correctly and I was looking for a code snipet solution that would lead me to fixing the grbl in my machine. btw, G93 motion mode works correctly.
I was expecting planner.c to perhaps have the solution. Can someone please direct me to the code, planner.c or otherwise, that implements this situation for G94 motion mode.
thanks much,
Lou

[terjeio]

So I'm assuming grblHAL has implemented this correctly

grblHAL was initially forked from Grbl so perhaps not...

Code is here?

I am not sure how to interpret the LinuxCNC spec, if linear motion and rotary motion is executed together the max feed rate for the rotary part should be ignored? Or somehow transformed before applied?

[bLouChip]

I am not sure how to interpret the LinuxCNC spec, if linear motion and rotary motion is executed together the max feed rate for the rotary part should be ignored? Or somehow transformed before applied?

Negative, respect max feedrate per axis. The code you reference seems to do that correctly.

However, after looking at planner.c nearby, here , I believe this may be where the fix is needed, the fix being to make sure X axis steps at the programmed feedrate dictate the time to make the coordinated move, that is the time it takes the control point to traverse the hypotenuse of XA. So in essence, for this type of linear-angular axes coordinated move, the move becomes an inverse time motion at this point and should be calculated as such.
I'm thinking something like what follows, and I will abstract the exact code to pseudo code...

edited 1/17/23 to clarify pseudo logic
// Line 498 // Store programmed rate.
if (block->condition.rapid_motion)
block->programmed_rate = block->rapid_rate;
else
{
block->programmed_rate = pl_data->feed_rate;
// insert new code here...
// else not a rapid move...
if (block->condition=this_is_a_linear_angular_move)
{
// then per NIST RS274 Section 2.1.2.5 Feed Rate, "...the feed rate means length units per minute
// along the programmed XYZ path, as if the rotational axes were not moving."
// Thus, let's treat this condition as an inverse_time motion,
// setup the block to take the characteristics of an inverse_time move
calc time_Xt for X axis to move Xmm in programmed_feedrate units;
block->programmed_rate = 1/time_Xt in minutes;
set(block->condition.inverse_time);
}
// Line 503 resume original code...
if (block->condition.inverse_time)
block->programmed_rate *= block->millimeters;
}

Thoughts ?

A test case is attached. It contains eight XA moves where the resulting hypotenuse line is 45mm in length, at 1000mm/m the control point should traverse each line in 2.7 secs. However, in my grbl machine, as the angle of the line increased from 0 towards 90 degrees from A axis of rotation, the traverse got progressively longer where the 80 degree line took ~20 secs. These timings indicate the A axis dictated the coordinated feedrate.

The photo shows the pattern on a cylinder made by a laser onto paper wrapped around the cylinder. You can see the over burnt lines indicating the progressively slow traverses.

XA tcB.nc.txt

[bLouChip]

I'm not sure if thread followers are notified of edits on a previous post, so if not, I edited my previous post here to clarify the pseudo code in which I was proposing a possible fix, if grblHAL exhibits the same error of course. Also, nothing to report yet from the folks at MillRight (MR grbl as I call it). I would be interested in knowing how the test case behaves on grblHAL when someone gets a chance to run it. Laser not needed, just time the moves via the gcode sender DRO.
thanks,
Lou

[bLouChip]

Ah... here's another proof point for the solution I suggest above... I built a version of the test file "XA tcB.nc", hand modified to use G93 Inverse Time motion mode in the G1 XA stmts, where F22.22 is the inverse time value for 45mm line at designed feedrate of 1000mm/m, and this file worked fine on my MR grbl. I just did the math on a few G1 XA lines of the original "XA tcB.nc", using the pseudo code in the proposed solution, and it works out to a block->programmed.rate of 22.22 in the case of converting the planner block to an inverse time motion when linear-angular motion is planned. Of course I haven't extrapolated this logic down stream of the processing to know for sure, but it stands to reason that converting this condition of move to an inverse time motion will play out correctly through cascaded code paths and not have undesired side effects.

XA tcB G93 v G94 compare rpt.html.txt
XA tcB G93.nc.txt

[terjeio]

I'm not sure if thread followers are notified of edits on a previous post

They are not, best to add another comment if the edit is not just fixing typos.

grblHAL suffers from the same "bug", adding your "translated" pseudo code fixes it - but other parameters (acceleration, rapids feed rate) has to be changed as well? I'll have to look into this in a bit more detail when I am back home.

Here is the "translated" pseudo code, motion.mask holds which axes are to be moved.

#if N_AXIS > 3
    if(!block->condition.rapid_motion &&
        (motion.mask & settings.steppers.is_rotational.mask) &&
         (motion.mask & ~settings.steppers.is_rotational.mask)) {

        float unit_vec2[N_AXIS];
        memcpy(unit_vec2, unit_vec, sizeof(unit_vec2));

        for(idx = A_AXIS; idx < N_AXIS; idx++) {
            if(bit_istrue(settings.steppers.is_rotational.mask, bit(idx)))
                unit_vec2[idx] = 0.0f;
        }

        pl_data->feed_rate = 1.0f / (convert_delta_vector_to_unit_vector(unit_vec2) / pl_data->feed_rate);
        block->condition.inverse_time = On;
    }
#endif

[bLouChip]

@terjeio , Well done!
On the one hand I'm sorry the bug is in grblHAL, but I'm glad we caught it and that you are onto the solution.
Hard to believe this bug persisted so long. Had it not been for LightBurn sticking to their guns and saying "we're generating the correct gcode, here's the spec...", I would not have pursued this. For most folks that run into this bug and actually notice it, they either tolerate it or change the gcode to use G93 motion mode, which in part is meant for this situation in the first place, it makes for clarity of the gcode anyway. For those that don't notice the behavior, well it never happened did it :) There are certainly countless youtube and other internet examples of fixing the slow G94 G1 XA steep angular moves by coding the solution in G93 motion mode.

but other parameters (acceleration, rapids feed rate) has to be changed as well?
Those are great points. I just looked at functions:
block->acceleration = limit_acceleration_by_axis_maximum(unit_vec);
block->rapid_rate = limit_max_rate_by_axis_maximum(unit_vec);`
but I don't see pl_data->feed_rate factoring into those calcs, and those calcs should operate on the original unit_vec[] as they do now.

As I study my pseudo code and your translate to C, I think I have a missing condition to trigger the fix, the fix being the pl_data->feed_rate conversion to inverse time feedrate and state, that missing trigger condition is...
if( is_false(block->condition.inverse_time) )
then { do conversion }
Meaning we don't want to convert the block from G94 to G93 mode if the G1 XA stmt was already in G93 inverse time mode, there is no bug in that case and pl_data->feed_rate is already in 1/t_minute units. And, upon leaving the { do conversion } block, we DO want the original planner.c feedrate in inverse time units converted back to distance time units again by using the hypotenuse XAmm, here, so this original code should always execute if not rapid motion.

Otherwise, I like it, it looks good so far.
Wow, this was a trip down memory lane for me, I spent a couple hours grepping code and remembering how to read C, C macros, and the like :)

Thank you very much for handling, please keep this thread posted with the final fix info or links to it. I'll make sure MillRight refers here before they dive too deep in their fork.

Cheers,
Lou

[terjeio]

On the one hand I'm sorry the bug is in grblHAL, but I'm glad we caught it and that you are onto the solution.

Well, from checking a couple of ports it seems to me that none handles this correctly. And I for one is glad that bugs are rooted out so they can be fixed! It annoys me a bit that bugs are often not reported at all, I see that from the Web Builder log...

There are certainly countless youtube and other internet examples of fixing the slow G94 G1 XA...

Do you have a couple of useful links?

... but I don't see pl_data->feed_rate factoring into those calcs, and those calcs should operate on the original unit_vec[] as they do now.

I am not sure, rapid rate is a feed rate and acceleration has a time dimension. When I am back home I will be able to check this out in more detail.

... please keep this thread posted with the final fix info or links to it.

I will - the final fix will be in the grblHAL core so will be added to the changelog when ready.

I'll make sure MillRight refers here before they dive too deep in their fork.

Do you know where their fork is hosted?

[bLouChip]

Do you have a couple of useful links?

In this reference, the CNC builder and Vectric expert Gary Campbell, explains "...Rotary feedrates have never been easy to understand. Inches (or millimeters) per minute (second) converted into degrees per min/sec just adds to the rotary confusion. To make it even worse, various controllers handle the data differently when given the same feedrates."
https://forum.vectric.com/viewtopic.php?t=30773

Here's an interesting one, according to the author he's running linuxCNC no less! The vid is 6 years old, so apparently linuxCNC had this bug too! I expect not anymore since they cite the spec now in their doc. This one threw me for a loop for a week because I thought if linuxCNC behaved as such, then it must be right! Until I read their spec, and verified it against NIST RS274.
So this author went to the lengths of writing a program to convert G94 motion gcode to G93 motion. Crazy. Well, on the other hand, I've done that before too when the prog I like using doesn't give me the output I want :0
https://www.youtube.com/watch?v=d0ffiCekhpE

Do you know where their fork is hosted?

sorry no.

[phil-barrett]

Do you know where their fork is hosted?

sorry no.

I don't believe MillRight has hosted the source for their version. Frankly, I doubt they care. MR's designs cut a lot of corners - for example they drive the Y stepper motors from a single driver.

[bLouChip]

I don't believe MR 'hosts' their grbl fork anywhere public either.
I'm in touch with MR. They assure me that they care about this bug, they're just prioritizing the bug fix in MR-grbl with other business right now.
I'm pursuing a grblHAL conversion of my controller as a Plan B path to solve this problem, but also as a means to test the grblHAL Plasma/THC plugin. My current plasma process using MR-grbl and my THC Z STEP Suppressor circuit for (XY Low-Velocity Z Anti-Dive) is working fine, I'm just curious to explore other methods. I like your concept of a grbl controlled THC thus keeping Z machine zero in tact.

[bLouChip]

@terjeio @phil-barrett
fyi... I just received my grblHAL board and my Teensy 4.1 NE board, so after a short assembly period, I'll be ready to download and compile grblHAL and once verified with this G94 G1 XA feedrate fix, then move on to a compile and testing with the Plasma/THC plugin.

@terjeio please advise how/when I download the fix code and you were going to make Plasma/THC plugin available on a web server for download and build. Thanks.

[terjeio]

please advise how/when I download the fix code and you were going to make Plasma/THC plugin available on a web server for download and build.

Sometime later this week? The rotary fix will be part of an updated core (some new settings++), possibly as a compile time option until verified as I do not have a rotary to test with. FYI I have timed motions produced by the fix and it looks good...

[bLouChip]

That's a good plan, well done. Thank you.

[terjeio]

The rotary fix is now available as an advanced option in the Web Builder.
Please report back when you have tested it with a machine as I am unable to do so myself.

[bLouChip]

Will do. thanks.

[bLouChip]

@terjeio
Although I purchased a grblHAL board and Teensy, I have not had time to gut my MR-grbl controller and replace with grblHAL. I still want to do this later in the year, and test/complete the Plasma THC plugin. So in the meantime, I decided to apply the fix to MR-grbl mega2560 implementation. I've testing it the past couple of days and it's working fine. I've attached it here. It deviates somewhat from your fix in grblHAL in that I preserve the rotational axes delta vector values for conversion to unit vectors ratios. Since G93 Inverse Time motion mode was already operating correctly for linear and rotational axes motion, this approach is to purely fix up the planner block with an inverse time feedrate calculated from only the linear axes hypotenuse, set the inverse time motion condition, and allow the original logic to process into distance/time motion. This approach does respect the axes maximum feedrate and accelerations, based on my testing.

Thank you for jump starting and sound boarding this fix. I'll be in touch when I get grblHAL running, I can at least do some bench testing with it sans the otherwise mechanical CNC attached in the very near future, now that I'm back in Arduino IDE work flow mode.
Cheers,
Lou

LDC MR-grbl G94 G1 XA FR fix.zip

[bLouChip]

@terjeio
So I had so much fun with Arduino IDE, fixing MR-grbl, flashing mega2560, and testing (bench and with CNC machine), iterate; that I thought '...before I forget all that work flow detail I'll just do the same with grblHAL and Teensy'. So I bench tested (no CNC machine motion) the grblHAL fix on a Teensy, using UGS to feed the gcode, and I used timings and the UGS visualizer to verify grbl operation. It's working identical to MR-grbl.

The original rotary fix in grblHAL did not work for me, and rather than debug it, based on obvious differences with the MR-grbl fix, I just ripped it and replaced it with the MR-grbl fix. Here is the compare report. Only file changed is planner.c.

Thanks again for your help moving this to the eventual fix.

grblHAL Rotary Fix compare report.html.txt

[terjeio]

The original rotary fix in grblHAL did not work for me

Did you configure ABC axes as rotary with $376?

[bLouChip]

Did you configure ABC axes as rotary with $376?

I did not; didn't know about it :(
Rather I defined values for A axis in $103, $113, $123, $133, of course after compiling with #define N_AXIS 4 in config.h
'$376=0' now and during my testing. However, after some searching for info on this now, '$$=376' explains it somewhat although I'm not sure of the effect on grblHAL internals since N_AXIS seems to trigger, in a cascading set of static function and declaratives, the setting of mask settings.steppers.is_rotational.mask, but those bit mask test(s) did not seem to be working in the original fix. Hence I changed it as you see now, because firstly upon original not working I had added !rapid_motion test, and unit_vec fixup; then after still not working, I ripped the original fix and replaced with what you see now. It works great after running several tests on limits with >< max speed on various axes, coordinated and single axis moves, rapid and G1, G94 and G93 motion modes, etc. I did the calculator math on distance and speed to verify the timings, and the UGS visualizer was in sync all the way, as were the status report coordinates and FS values.

$i report also seems normal for acknowledging A axis is active.
[VER:1.1f w LDC Rotary fix.20230219:]
[OPT:VNMSLW,35,1024,4,0]
[AXS:4:XYZA]
[NEWOPT:ENUMS,RT+,HOME,ES,REBOOT,TC,SED,RTC]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FLASH]
[DRIVER:iMXRT1062]
[DRIVER VERSION:230130]
[DRIVER OPTIONS:USB.2]

That's all I have short of ripping MR-grbl controller and replacing with grblHAL board and Teensy, that is still a ways off given the amount of CNC work in the queue right now, and the system seemingly running very fine at long last. I'll certainly follow up with you and @phil-barrett when I do rip and replace the controller for grblHAL.

[terjeio]

I did not; didn't know about it

Ok, that explains it - my code is basically the same as yours except that mine is configurable and supports all axes up to the limit (8).
It could be argued that ABC axes should be set as rotational per default - but I did not since that would break backwards compatibility. Perhaps a bad decision...

[bLouChip]

my code is basically the same as yours except that mine is configurable and supports all axes up to the limit (8)

agreed on the config and N_AXIS limit, good point, using settings.steppers.is_rotational.mask is better.
However, there are two more important differences I believe,

1. grblHAL is not excluding "linear_magnitude" calc (unit_vec fixup) when rapid_motion, but I realize this is self correcting because of the rapid_motion test and block->programmed_rate adj downstream, however...
2. grblHAL "linear_magnitude" calc depends on zeroing rotational axes in unit_vec, which has the side effect of an incorrect rapid (max speed) during XA motion, its overdriving the A axis if A max spd < linear axis max spd.
   My adhoc testing confirmed this operation, but I have to revisit it later this week to be sure and to record a sequence of limit test motions that I can share with you in a gcode file test case.

[terjeio]

I left equal code as yours, but inactive, when testing earlier - if you change the committed version like this:

    if(!block->condition.inverse_time &&
            /*!block->condition.rapid_motion &&*/
        (motion.mask & settings.steppers.is_rotational.mask) &&
         (motion.mask & ~settings.steppers.is_rotational.mask)) {

        float delta_vec[N_AXIS];

        idx = A_AXIS;
        motion.mask &= settings.steppers.is_rotational.mask;
        motion.mask >>= 3;
        memcpy(delta_vec, unit_vec, sizeof(delta_vec));

        while(motion.mask) {
            if(motion.mask & 0x01)
                delta_vec[idx] = 0.0f;
            motion.mask >>= 1;
            idx++;
        }

        // feed rate for laser mode has to be the actual speed of the controlled
        // point over the surface of the object to engrave?
        pl_data->feed_rate = 1.0f / (convert_delta_vector_to_magnitude(delta_vec) / pl_data->feed_rate);
//        pl_data->feed_rate = 1.0f / ((block->millimeters = convert_delta_vector_to_unit_vector(unit_vec)) / pl_data->feed_rate);
        block->condition.inverse_time = On;
    }

it is equal? IIRC my intention was to work on the code when I was back home and was the reason I left it the inactive part there...

Anyway, having degraded math skills over the years I have a bit of a problem with the following code:

    block->millimeters = convert_delta_vector_to_unit_vector(unit_vec);
    block->acceleration = limit_acceleration_by_axis_maximum(unit_vec);
    block->rapid_rate = limit_max_rate_by_axis_maximum(unit_vec);

These troubles me, perhaps incorrectly, as they become a mix of mm/min and deg/min when both linear and rotational motion is commanded at the same time. You can shed any light on that? And should not rapids be treated the same way as "normal" motion?

The other test result observation is that the 'realtime' grbl status report feedrate (sourcing the sender sw DRO feedrate) is different for G94 motion vs. G93 motion.

I believe the reported speed is always in mm/min (or deg/min) regardless of the mode.

[bLouChip]

Yes, that should work, because its does not alter unit_vec[] and thus preserves block->millimeters same as original version (pre-fix). Recall the original version handled G93 motion correctly for XA moves, so this corrected fix simply forces G93 behavior and the same downstream code path.
re. math skills, yours are fine :) You are correct to read convert_delta_vector_to_unit_vector() as mixing measurement units; however consider that the gcode generator has/should have taken into account the A axis cylinder circumference when it calculated the A axis degrees of rotation, so the degree units are basically scaled to appropriate millimeters in the dimension of the XA gcode stmt. Thus, the convert function works fine. That's my story and I'm sticking to it :) In fact if you wanted to, you could forego the rotary fix function convert_delta_vector_to_magnitude(delta_vec) and instead just call convert_delta_vector_to_unit_vector(delta_vec) when setting pl_data->feed_rate , that should work fine. Also, it just occurred to me that in the condition of linear and rotational motion, we could just:

float delta_vec[N_AXIS] = {0};        
memcpy(delta_vec, unit_vec, 3);           //only need values for linear axes motion distances, index 0,1,2
// calc the G93 feedrate based only on magnitude of linear motion in the block
pl_data->feed_rate = 1.0f / (convert_delta_vector_to_unit_vector(delta_vec) / pl_data->feed_rate);
block->condition.inverse_time = On;

done.

I'm thinking out loud here so there could be a mistake, to be sure I'll adjust the rotary fix both ways and test it within a day or so.

[bLouChip]

Its tested; passed all former failing tests including having a correct feedrate in the sender DRO now. Here's the code I fixed up and tested.

#if N_AXIS > 3  && ROTARY_FIX
    // NIST RS274 states that G94 G1 linear & angular motion has the feedrate assigned to the linear axes
    //   so to accomplish this, if we have this condition, then we'll fixup the planner block to 
    //   behave as if its doing a G93 Inverse Time motion move      
    if(!block->condition.inverse_time &&
      (motion.mask & settings.steppers.is_rotational.mask) &&
      (motion.mask & ~settings.steppers.is_rotational.mask)) {

	//copy to temp only values for linear axes motion distances, index 0,1,2
	float delta_vec[N_AXIS] = {0};
        memcpy(delta_vec, unit_vec, 3*sizeof(float));
        //get the linear motion magnitude and calculate inverse time feedrate 
        // and store for later assign to plan block
	pl_data->feed_rate = 1.0f / (convert_delta_vector_to_unit_vector(delta_vec) / pl_data->feed_rate);
        //finish block fixup by setting G93 inverse time motion mode
        block->condition.inverse_time = On;
    }
#endif

[terjeio]

Thanks. I have modified the code to match what you did for the Mega, and handle all possible axis configurations (up to 8) including remapping ABC to UVW. I am not sure what to do with this comment though...

[bLouChip]

Very good. Glad to help.
re. the comment and code --

    // Calculate the unit vector of the line move and the block maximum feed rate and acceleration scaled
    // down such that no individual axes maximum values are exceeded with respect to the line direction.
    // NOTE: This calculation assumes all axes are orthogonal (Cartesian) and works with ABC-axes,
    // if they are also orthogonal/independent. Operates on the absolute value of the unit vector.
    block->millimeters = convert_delta_vector_to_unit_vector(unit_vec);
    block->acceleration = limit_acceleration_by_axis_maximum(unit_vec);
    block->rapid_rate = limit_max_rate_by_axis_maximum(unit_vec);

The first sentence is true. I recommend changing the second sentence to:

   // NOTE: This calculation assumes all block motion axes are orthogonal (Cartesian), and if also rotational, then
   // motion mode must be Inverse Time mode. Operates on the absolute value of the unit vector.

[JeffHank1]

I am using a MKS TinyBee v1.0 ESP32 card with a 5 axis machine - three linear and two rotary. I select the Lightburn, Backlash and Rotary axis fix options only. I connect via USB only. The Rotary axis feature does not seem to compile using the Web Builder. I have tried three different compilations without success.

I have used GrblHal successfully on a Red Mach3 card for 4 axes - three linear and one rotary.

I am using iOSender to test the actions of the cards with Lathe option turned on. It is interesting that enabling Report in Inches for the DRO still requires the initial position settings to be entered in mm. Occasionally after running a GCode program in inches I can enter the starting coordinates in inches.
Any suggestions would be appreciated. Thank you.

[terjeio]

The Rotary axis feature does not seem to compile using the Web Builder. I have tried three different compilations without success.

It fails at run-time? Asking since it compiles for me.

It is interesting that enabling Report in Inches for the DRO still requires the initial position settings to be entered in mm. Occasionally after running a GCode program in inches I can enter the starting coordinates in inches.

I have modified the DRO behaviour in ioSender to always regard input as in the mode set by $13 and convert as neccesary depending on G20/G21 status. The perceived randomness in interpreting the values correctly is likely due to the sender not keeping track of the current G20/G21 status unless the Parser state option is enabled in the Status report options setting ($10). I have uploaded new edge versions (p7) with this change.

[JeffHank1]

Sorry for the delay reporting back. My SKR Pro V1.2 board was stuck in an alarm state (10) that I couldn't figure out. It would not budge until I changed several Grbl settings. All hard and soft limit settings are disabled on my machine because I don't use them. I don't use Homing at all. I think disabling the Probe location might have helped. Maybe it was a power surge at some point, no idea. Reloading previously working Grbl settings was not helpful. Resetting (software or hardware) or rebooting was not helpful. It is unlocked and working now. I have downloaded the Edge version of iOSender and run several programs on it. I added the Parser State enable in the Grbl settings as suggested too. Another interesting observation is the reporting behaviour for the C axis in a type of GCode program I am running. The C axis should always be turning in a Negative direction and physically it does. iOSender usually reports it counting negatively but occasionally it will switch and report the C as moving in a Positive direction (which it is not). I will attach the GCode file for your interest. Thanks again for a great program

…

On Tue, May 14, 2024 at 1:55 AM Terje Io ***@***.***> wrote: The Rotary axis feature does not seem to compile using the Web Builder. I have tried three different compilations without success. It fails at run-time? Asking since it compiles for me. It is interesting that enabling Report in Inches for the DRO still requires the initial position settings to be entered in mm. Occasionally after running a GCode program in inches I can enter the starting coordinates in inches. I have modified the DRO behaviour in ioSender to always regard input as in the mode set by $13 and convert as neccesary depending on G20/G21 status. The perceived randomness in interpreting the values correctly is likely due to the sender not keeping track of the current G20/G21 status unless the *Parser state* option is enabled in the *Status report options* setting ($10). I have uploaded new edge versions <https://www.io-engineering.com/downloads> (p7) with this change. — Reply to this email directly, view it on GitHub <#241 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM2XK2XU7OYCS6CEY4GFNGTZCG7PZAVCNFSM6AAAAAAT37NBIGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TIMZQGAZTA> . You are receiving this because you commented.Message ID: ***@***.***>

-- Looking to find, Finding to know, Knowing to learn, Learning to grow, wiser. JH

[terjeio]

I will attach the GCode file for your interest.

Please do so I can check it out.

[terjeio]

I have managed to fix this, but will wait a bit before committing since there is some testing going on for new functionality that includes changes in some of the files involved in the fix. I guess this is ok since machining is not affected?

[JeffHank1]

That’s ok with me. Thanks for considering the problem so quickly. I’ll watch for a new version.

[terjeio]

New version with fix is now up.

[JeffHank1]

Thanks for posting the new version. I have the May 14 2024 2.0.445p7 version from the Index of Downloads.
I will try the May 14 2024 iOSender 2.0.45p7 version from the Index of Downloads.

[terjeio]

The fix is for grblHAL, not ioSender.