Probing and gcode rotation

[raenji-sk]

Hi, would it be possible to add a feature to the probing part of the sender. One that would probe along one axis at two points in order to determine the angle if the stock is not exactly squared to the axes and then calculate and rotate the gcode in order to compensate? Uccnc has this for example and it seems to be pretty useful for example for two sided jobs.

[terjeio]

It is on my todo list, to be added sometime after the first production release.

[raenji-sk]

Perfect. Let me know in case I could help with testing it for example.

[terjeio]

I wonder where rotation should be implemented. In the controller or the sender?

LinuxCNC has rotation as an option for the G10L2 command, Mach 3 uses G68/G69.

LinuxCNC: "Optionally program R to indicate the rotation of the XY axis around the Z axis. The direction of rotation is CCW as viewed from the positive end of the Z axis."

Mach3: "Program G68 A~ B~ I~ R~ to rotate the program coordinate system." and "Program G69 to cancel rotation."

[raenji-sk]

Good question, I found out that the original grbl does not support G68 or G10L2 R gcodes. bCNC has this implemened somehow, but not with mechanical probing but rather using a camera to tell the sender where are the real coordinates in the stock material compared to the ones in gcode. Christian Knüll also implemented it somehow in his Estlcam SW/HW - https://www.youtube.com/watch?v=bhZdbgM6S70 at about 1 minute mark. Perhaps sender implementation would be faster and easier, unless you can somehow implemet G10L2 or G68 into grblHAL on the controller level. But I am no programmer, or not a good one at least, so just speculating about it.

[terjeio]

bCNC has this implemened somehow, but not with mechanical probing but rather using a camera to tell the sender where are the real coordinates in the stock material compared to the ones in gcode.

ioSender should support both camera and mechanical probing. I want camera support when drilling and milling PCBs.

Perhaps sender implementation would be faster and easier, unless you can somehow implemet G10L2 or G68 into grblHAL on the controller level.

I am not sure what will be fastest - and most complete. grblHAL supports canned cycles with repeat, I am not sure that these be transformed "as-is" in the sender. If implemented in the controller then only grblHAL can be used unless legacy grbl and other ports does the same... A partial implementation (not supporting all G-codes) in the sender could be the best solution initially.

[raenji-sk]

I want camera support when drilling and milling PCBs.

Yeah, camera probing is excelent for theese tasks and helps a lot with the exact alignment of a PCB.

A partial implementation (not supporting all G-codes) in the sender could be the best solution initially.

Right, I guessed the same. I doubt the legacy grbl will add any more features, so it is probably up to you how to do it and a sender implementation would allow the use with any gcode program independent of the hardware, but rotated, modified and sent to the cnc by the gcode sender. Perhaps something like the height map which I guess is also calculated by the sender.

By not supporting all gcodes you mean for example that after it gets rotated the arcs, or something else won't work?

Would it maybe be worthwhile to get in touch with other 32bit grbl ports? Like the Grbl_Esp32. Or Spark Concepts released a 32bit Xpro V5 controller not that long ago and it runs some 32bit grbl port, but I am not sure which one. I mean to establish some common solid base for the next gen grbl.

[terjeio]

Perhaps something like the height map which I guess is also calculated by the sender.

It is.

By not supporting all gcodes you mean for example that after it gets rotated the arcs, or something else won't work?

Repeated canned cycles may be problematic, G5 spline too? These are not widely used so a minor issue.

Would it maybe be worthwhile to get in touch with other 32bit grbl ports?

I don't know. grblHAL is pretty different in that the core is completely processor agnostic and I am not going to change that. There are a couple of developers working on new drivers for the core - IMO a good thing that I encourage. Generally I use the LinuxCNC specification as a basis for adding G- and M-codes to the core, a few are lifted from the Mach 3 specs.

Or Spark Concepts released a 32bit Xpro V5 controller not that long ago and it runs some 32bit grbl port, but I am not sure which one.

It is based on Grbl_ESP32 - and in violation of the license?

I mean to establish some common solid base for the next gen grbl.

The grblHAL core is closest to beeing usable?

[phil-barrett]

Implement in sender vs Grbl core - interesting question. My first instinct is in the sender. Then it applies to all Grbl implementations and is fully self-contained (probing/transforming). If implemented in Grbl Core you still need the sender to probe for the amount of rotation and issue the rotation command.

Height Mapping/GCode Transform is fully within the sender and makes a reasonable model. Consistency?

If there are features like canned cycles that can not be transformed, I assume the sender would produce an error message. (Though I don't quite understand why CCs would not be transformable.)

Edit: on the subject of basis for next generation Grbl. Other than grblHAL, I do not see anything that is close. All other versions are tied to specific microcontrollers and not as easily extensible via plug-ins.

[terjeio]

Height Mapping/GCode Transform is fully within the sender and makes a reasonable model. Consistency?

The LinuxCNC G10L2 spec allows rotation so it would be nice to have support for that in the core, but might be hard(er) to implement. I'll go for a sender implementation as a first step.

If there are features like canned cycles that can not be transformed, I assume the sender would produce an error message.

Surely. I have not looked into this yet, and it might only affect canned cycles with a repeat parameter, L<n>, present, if at all?

[phil-barrett]

The advantage of putting the rotation (and height mapping) into the Grbl Core is that it keeps the sender less complex. This will be of value for non-PC senders like a simple control panel or hand-held device like a super MPG (ala OB's "Interface"). Though, probing is not simple...

[raenji-sk]

The grblHAL core is closest to beeing usable

That is why I ended up using it and the awesome BOB form Phil. I did compare, probably, all the options before making this decision.

Repeated canned cycles may be problematic, G5 spline too? These are not widely used so a minor issue.

If that would be the only limitation then I'd say it is no problem at all. Most hobby senders/hardware or postprocessors do not support that anyway I believe.

Though, probing is not simple...

True, but advanced probing methods are the only thing I miss at the moment in grbl(HAL), compared to more industrial solutions like Mach or UCCNC.

[terjeio]

GCode Sender Edge.33p0.zip now available for feedback for rotate gcode, tab added to Probing tab and menu/dialog added to File > Transform menu. Only lightly tested, does not support G5 splines. Artefacts seen on one file containing arcs. This is a RFC (Request For Comments) version so use with utmost care.

[raenji-sk]

Perfect, if I'll have a bit of time to spare tomorrow I'll give it a try.

[phil-barrett]

Thank you for doing that!

I think I know the answer to this question but worth getting confirmation - If I apply rotation and copy the GCode out of IOSender's Program tab, will that give me the modified/rotated GCode? I want to use it verify the rotation and look for artefacts.

Same question for applying a height map.

[terjeio]

If I apply rotation and copy the GCode out of IOSender's Program tab, will that give me the modified/rotated GCode?

Yes, all transforms does that, use File > Save to copy it out. The 3D display is also updated to show the modified toolpath.

[raenji-sk]

So I did some quick test. The good news is that it appears to be working and rotating the gcode in most cases. However on some files it does crash the program after pressing the apply button. https://1drv.ms/u/s!AmP5jEwdNIwcltc0gHe-pLyD-xAThg?e=gt3dMz Here is a link to my OneDrive folder with the gcodes tested. The ones which were rotated have a "rotation" suffix in the file name. Both original and rotated files are there. The two files named 8mm... crash the app. Could you perhaps take a look at them if you see something that would casue the problem?

[terjeio]

@raenji-sk Thanks. The files that crashes has arc moves not in the XY-plane. I have to add handling of that.

FYI I tested one of them with another sender and it did not crash - it just produced weird moves...

[raenji-sk]

The files that crashes has arc moves not in the XY-plane.

Yes I just found out by manually edditing the .nc file and removing them.

[raenji-sk]

Just to be clear, it does not crash on opening the file with G17-G19 and also runs ok with the official ioSender release as I did run those files yesterday and all was good. It does crash after probing the angle and applying the rotation to it.

[terjeio]

New edge version up. Now faults radius mode arcs and arcs in XZ and YZ plane, convert arcs to lines with File > Transform > Arcs to lines first. Some radius mode arcs migh possible to transform depending on how much of a half or full circle they cover.

Fusion 360 users can change the postprocessor to not output arcs in XZ and YZ plane. Info here.

The one file that produced arc artefacts had 4 decimals in metric mode (sub micrometer resolution) when converted to the convential 3 decimals they appeared. I have added a temporary fix for such files.

[raenji-sk]

Great, will test it next week.

One more thing on probing, I tried the external corner probe recently on bottom right corner and it is always off. The bottom left corner works OK though... No idea if it was my mistake or something else. I'll try to reproduce and document it when I get a chance. Edit: Disregard the previous info about corner probing. It works OK now with both edge and official release on all 4 external cornrrs. No idea what was wrong before...

[raenji-sk]

Tried the rotation with a simple program with XY arcs only. XZ and YZ are disabled in the post processor. Seems to work pretty well. Here's a short video: https://youtu.be/_FbhxemMLXc

[terjeio]

@raenji-sk Thanks for the feedback.

New edge version uploaded where rotation center (origin) can be specified, based on Program limits values.

[raenji-sk]

New edge version uploaded where rotation center (origin) can be specified, based on Program limits values.

Very nice, that could be useful.

Found out some other stuff: https://1drv.ms/u/s!AmP5jEwdNIwcltc0gHe-pLyD-xAThg?e=FYm0Dm One drive folder with new testing gcodes

1. Rotating the gcode strips/changes some commands/arguments If you compare the Rotation Test M7M8.nc with its rotated version there are missing parts of the code, for example Line 6 - Original is G28 G91 Z0 to retract the Z before starting the actual milling, rotated file only has G91G28 Line 13 - is dwell G4 S2, in rotated file it is S2G28 Lines 136 and 138, G28 G91 Z0 and G28 G91 X0 Y0 have the XYZ coordinate argument missing

2. M6 command problem Using more than one tool in Fusion grbl PP and enabling M6. This gcode crashes the IOSender - file Rotation Test Two tools M6M7M8.nc. Disabling M6 or stripping it upon opening file in IOSender does not crash it, but renders the M6 useless. How exactly is this supposed to work? BTW, it opens fine in bCNC even with M6 present.

Tests were done using the latest Edge release (33.p2). But I did run this on a Arduino UNO with a Protoneer shield as I do not have the Teensy controller with CNC close by, no idea if that matters in this case or not so please let me know if I should retest it with the Teensy. Also let me know if you have other things in mind that you want tested.

Edit 1: Point 2. The file with M6 tool change command opens without crashing when the IOSender is running with a Teensy controller connected. So it must be an issue with M6 handling on the 8bit arduino.

Edit 2: Point 1. Same behavior with the Teensy controller gcode gets stripped/modified the same way as stated above.

Edit 3: Point1, line 13, G4 Dwell. I had the PP set to G4 Snn (which is ok for RepRap firmware G4Snn - seconds, G4Pnn millis, I was editing a Duet PP before that so got confused..). LinuxCNC/GRBL uses Pnn only so I changed it back to that. Now after rotating the gcode the G4 command disappears completely from the rotated gcode.

[terjeio]

Line 6 - Original is G28 G91 Z0 to retract the Z before starting the actual milling, rotated file only has G91G28

This is a bug and bad gcode - is the move G0 or G1? Or a canned cycle? I should assume G0 or the current modal state from the controller? Perhaps a warning on load would be appropriate?

Line 13 - is dwell G4 S2, in rotated file it is S2G28

Bad gcode, G4 on its own will return an error from the controller. I should output a warning on load? (P parameter is missing). S2 sets the spindle speed. I just noticed your edit - another bug to fix...

Lines 136 and 138, G28 G91 Z0 and G28 G91 X0 Y0 have the XYZ coordinate argument missing

Again a bug.

Using more than one tool in Fusion grbl PP and enabling M6. This gcode crashes the IOSender

Another a bug? I'll have to connect an Arduino controller and check.

How exactly is this supposed to work? BTW, it opens fine in bCNC even with M6 present.

It is not supposed to work since M6 is not supported by vanilla Grbl. ioSender should report the error returned from Grbl and halt streaming. I don't know what bCNC does with M6 commands, it either handles it itself or just strips it out. There are some ports of Grbl that supports M6 so I decided to add an option for stripping M6 in Settings: App .

Note that there is, IMO, a serious bug in vanilla Grbl when agressive buffering is enabled. If an error is raised by the controller it will happily continue to process commands in the input buffer potentially causing mayhem... grblHAL will raise the same alarm for all subsequent lines until either a system command is executed or an empty line is sent. ioSender will stop sending lines when an error is received.

---

ioSender tokenizes the gcode on load, it is the tokenized version that is used for 3D rendering and all transforms. Transforms creates a new tokenized version that is then used to generate the gcode. The bugs you have encountered is likely to be in the tokenizer and/or the code generator - not the transform.

[raenji-sk]

The G28 G91 moves at the beginning and end of the program are rapids so G0. For grbl the fusion360 postprocessor supports setting the safe Z height to either G28, G53 or a retract plane set in CAM. At start it retracts the Z and then moves to zero workspace coordinates on XY. At the end it does again retract the Z and then moves to predefined G28 XY to get the spindle out of the way. I always use G28 as it's something I am used to but can try the other ones too to see what will happen. I don't see reason for a warning. Well unless it's for beginners, or someone who does not use homing switches, or did not set the suitable G28 position first with G28.1

Pretty sure bCNC handles the M6, as I did use it a couple of times with an Arduino controller. It did move to a predefined position and pause to change the tool, move to probe, measure tool length and continue. But as you wrote it most likely does that internally.

I do have the aggressive buffering disabled on the Arduino dummy, or testing, controller. Only enabled it on the Teensy.

[terjeio]

G28 G91 Z0 is a bit backwards as execution order is G91 G28 Z0, my bad not remembering this. IMO G91 G28 Z0 is easier to read/understand. The tokenizer always extract commands in execution order so the transformed code will come out like the latter when detokenized.

I have added a warning for G4 if the P argument is missing, and a warning if the controller is Grbl and M6 commands are in the file. Some Grbl ports supports M6 so IMO a warning is appropriate. I am not sure I want to add tool change support for Grbl in ioSender...

Bugs are fixed (hopefully), new edge version is up. Again, many thanks for testing.

[raenji-sk]

@terjeio Youre most welcome. I will test the new version and let you know if I have more things to report.

IMO G91 G28 Z0 is easier to read/understand

Could be, its just the way it comes out of the grbl Fusion postprocessor, I guess the order is irrelevant for the controller so no problem if its different after applying the rotation, or passing through the tokenizer. Could be changed perhaps, but I'd rather not to as if there are too many changes I'd need to keep track of everyhting and change it in the new version of a postprocessor if there's one.

I am not sure I want to add tool change support for Grbl

Personally I'd say it is not needed or worth fiddling with. The personal/free licence of Fusion 360 does not allow processing of multiple tools anyway. And those who have a paid licence usually have something else than a hobby grade grbl CNC (well I seem to be an exception in this case :) ), or use simpler CAM like Vectric for woodworking stuff. But there I have no idea how and if toolchanges work as I do not have any Vectric software.

[terjeio]

Could be changed perhaps, but I'd rather not to as if there are too many changes I'd need to keep track of everyhting and change it in the new version of a postprocessor if there's one.

No need to change anything, it was only me forgetting to apply the execution order rules when reading the code. BTW these rules are defined in the NIST standard, and the tokenizer has to comply with them. It would be impossible to render a 3D view or do a transformation properly for valid gcode if not. E.g. G28 G91 Z0 is converted to two tokens in the correct order, when recreating the line it is output in that order. Another example is M3S100, execution order is first set the spindle speed then switch the motor on, when passing trough tokenization/detokenization it becomes S100M3.

But there I have no idea how and if toolchanges work as I do not have any Vectric software.

They works as intended and outputs gcode as defined in the postprocessor. I own a VCarve Desktop license and is very happy with that, I use it mainly for milling aluminium and laser cutting. One nice feature is the Output direct to machine option which can be set up for ioSender. When checked the gcode is sent directly to the sender and will start it if not currently running. I just press the Output Toolpath(s) button in VCarve and then Cycle Start in the sender - can't be simpler.

[raenji-sk]

BTW these rules are defined in the NIST standard,

Oh, thats good to know, I was not aware of it. The PP for grbl I use is from official Autodesk site. But I guess it does not matter in the end if it gets out in a different order after being processed by the IOSender if no parts of the gcode are lost in the process.

One nice feature is the Output direct to machine option

Yeah, I was wondering how that works when I saw it in the IOSender. Pretty cool feature indeed.

Going to do some more tests today/tomorrow and will report back.

[raenji-sk]

Did not do any real life cutting test. But I tried rotating a gcode with M6, M7, M8, M9, M62, M65 (for ext relay) and it seems to work well. Compared rotated and original file in VSCode and I can not find anything missing in the rotated file.
Both gcodes are in the OneDrive linked in previous post.

So just the XZ, YZ Arcs are missing / not implemented.

Don't know how to test canned cycles for example, do you think the linuxCNC postprocessor for Fusion would work OK with grblHAL hardware/software?

[terjeio]

So just the XZ, YZ Arcs are missing / not implemented.

I think it is impossible to rotate those, convert with File > Transform > Arcs to lines first.

Don't know how to test canned cycles for example, do you think the linuxCNC postprocessor for Fusion would work OK with grblHAL hardware/software?

I have done some simple tests myself with Excellon drill files from KiCad converted to gcode with ioSender and then rotated. Nothing drilled yet, just verified that the 3D View "tool" tracks the paths displayed. The linuxCNC postprocessor may work, if not I would like to see gcode that fails.

Example .drl and corresponding .nc file:

RP2040 MPG and DRO.zip

.drl files can be opened (also by dropping) in ioSender for "on-the-fly" conversion.

[raenji-sk]

I think it is impossible to rotate those, convert with File > Transform > Arcs to lines first.

Ok, no problem, I turned them off in the grbl Fusion PP.

I'll try to run the files on the CNC, atleast some air cuts to see if all goes well and won't throw any errors. Might try the drill cycle as well while I am at it. BTW, it's yet another great feature to be able to use the Excellon drill files directly in IOSender ;)

I've attached a sample gcode as it comes out from the Fusion LinuxCNC PP

Canned Drill.zip

It throws an error upon loading on line 15, but I have the Arduino connected now, so I assume it should work fine with Teensy right? Or do you see anything in the code that might cause problems?

[terjeio]

Or do you see anything in the code that might cause problems?

Yes, there is a G43 that is unsupported unless tool table handling is enabled in grblHAL. With tool table enabled it ran fine until I rotated it. To be investigated. And since there is a Z motion(?) in the G43 Z15. H1 block I guess this comment in the grbl parser is not correct:

// NOTE: The NIST g-code standard vaguely states that when a tool length offset is changed, // there cannot be any axis motion or coordinate offsets updated. Meaning G43, G43.1, and G49 // all are explicit axis commands, regardless if they require axis words or not.

LinuxCNC has this comment for G43.1, but not for G43 and G49 so it is possible that the grbl parser is too strict.

It is an error if motion is commanded on the same line as G43.1

[terjeio]

There are bugs in both the parser code inherited from Grbl and the sender. I can't find the vague statements in the standard so I decided to use the LinuxCNC specification and have modified the parser accordingly. I'll commit fixes later.

G28/G30 commands are a bit scary if the machine is not homed, I wonder if a warning on load is appropriate?

[raenji-sk]

Trying to postprocess a simpler program without M6 via the Autodesk LinuxCNC PP. It still outputs the G43 Z15 H1 Found another one: https://github.com/85vmh/LinuxCNCFusionPosts That one skips the G43 when only one tool is used. But makes use of G64 P0.01 which I don't know if grblHAL supports. It also mixes G28 and G30 to move to and away from part.... G28 for safe retracts on Z and G30 as a pedefined XY position where it moves after the job is done. So a bit confusing, but the whole LinuxCNC PP thing is probably out of scope for now... On the other hand it would be nice to have a grblHAL postprocessor with all the added features (4-5 axis machining, extended M/G codes, etc.)

G28/G30 commands are a bit scary if the machine is not homed, I wonder if a warning on load is appropriate?

Not really sure, a warning might be OK if one uses that for the first time or has it set up improperly, I know it did scare me the first time I tried it... But perhaps if you add this or other warnings in the future then you could add some option to disable the existing and future warnings in the IOSender settings. Either all at once, something like a "pro mode" or individually. My point is, it is a good way to get attention of a less experienced user, but might be a bit bothersome for the more experiecend ones.

[terjeio]

But makes use of G64 P0.01 which I don't know if grblHAL supports.

It does not, but can be stripped (is by default) in Settings: App. Support should be added, don't know how difficult that would be. This comment can be found in planner.c:

        // NOTE: If the junction deviation value is finite, Grbl executes the motions in an exact path
        // mode (G61). If the junction deviation value is zero, Grbl will execute the motion in an exact
        // stop mode (G61.1) manner. In the future, if continuous mode (G64) is desired, the math here
        // is exactly the same. Instead of motioning all the way to junction point, the machine will
        // just follow the arc circle defined here. The Arduino doesn't have the CPU cycles to perform
        // a continuous mode path, but ARM-based microcontrollers most certainly do.

My maths skills are no longer as they once were, perhaps somebody brighter can immediately see what needs to be changed?

So a bit confusing, but the whole LinuxCNC PP thing is probably out of scope for now...

IMO it seems not too far out of scope. It is possible to enable a tool table already so G43 can be handled properly, G64 is a show stopper?

Not really sure, a warning might be OK if one uses that for the first time or has it set up improperly, I know it did scare me the first time I tried it... But perhaps if you add this or other warnings in the future then you could add some option to disable the existing and future warnings in the IOSender settings.

I was thinking of outputting a warning only if the machine is not homed. grblHAL reports homed status, Grbl does not... Experienced users always homes their machine?

Currently warnings are shown when there are lines with unsupported commands and if there are tool changes that requires the tool length offset reference to be set. Some errors in the gcode is also shown. I do not want to disable those.

[raenji-sk]

G64 is a show stopper?

Maybe it would be worth it to make a custom PP by combining the grbl PP and add fetures form the LinuxCNC PP according to the extended M/G codes supported by the grblHAL? That is if implementing the whole LinuxCNC code range would prove to be difficult or time consuming.

grblHAL reports homed status Some errors in the gcode is also shown. I do not want to disable those

Fair enough, better to be safe than sorry...

[terjeio]

Maybe it would be worth it to make a custom PP by combining the grbl PP and add fetures form the LinuxCNC PP according to the extended M/G codes supported by the grblHAL

That would be nice, you gave me the idea that I probably should add a postprocessor repo for that. You can make one for Fusion360 and share it?

BTW, adding G64 is going to be somewhat problematic, not neccesarily because the math involved but due to challenges involved in adding the arc move...

I have added a warning for G28/G30 moves if the controller is grblHAL and the machine is not homed. I have also fixed a few tokenizer/detokenize bugs and added a gcode compression "transform" that removes superfluous command elements to the File > Transform submenu. New edge version with these changes just uploaded.

[raenji-sk]

That would be nice, you gave me the idea that I probably should add a postprocessor repo for that. You can make one for Fusion360 and share it?

A repo for PPs would be good thing to have.

As for making one, unless you have someone skilled in mind, I can try to look into it. I am no expert prgrammer, but perhaps I can merge some parts from the LinuxCNC PP into the grbl one. Can't promise any spectacular results though... and I have no experience with or way to test more than 3 axis PP.

[raenji-sk]

@terjeio I made a repo for my version of the Fusion 360 PP, you can find it here: https://github.com/raenji-sk/grblHAL_Post_Processor You can link to it or if you want I can upload it somehwere elese.

Functionality is not tested.

G81-G82 seem to output correct gcode and so does the 4th axis. G83 does not get processed corretly atm....

Can test the canned drilling cycles later. But I have no 4th axis at the moment so can't do that. Gcode preview in IOSender seems OK though.
Also tried it in ncviewer.com, there it looks distorted, no idea why, but it shows the LinuxCNC file incorrectly too, so probably a viewer issue.

Samples of processed gcodes attached. 4th_axis_and_G81-G83.zip

[terjeio]

Thank you.

I made a repo for my version of the Fusion 360 PP, you can find it here: https://github.com/raenji-sk/grblHAL_Post_Processor You can link to it or if you want I can upload it somehwere elese.

I will link to it, next on my todo list is to create a PP repo and a documentation repo.

G81-G82 seem to output correct gcode and so does the 4th axis. G83 does not get processed corretly atm....

Which build? G83 seems to run ok on my machine with the latest, there were some bug fixes for canned cycles in build 20210505.

[raenji-sk]

I think the G83 error is postprocessor related (something in the pp code) and not a problem with grblhal. I just quickly merged the features from linuxcnc pp to the grbl one and did not do any closer examination of how it actually works.

I'll try to figure it out when I have some time.

[terjeio]

I think the G83 error is postprocessor related (something in the pp code) and not a problem with grblhal.

Well, I cannot see what is wrong. However I found a bug in the senders rotation code, Q and P parameters are swapped.

Oh, I see now - there are no G83 codes in the file, just plain G0/G1 movements...

[raenji-sk]

Maybe create a new thread for this, or wait for new repo?

Anyway, I found out that the G83 works fine, atleast when it comes to the PP and generating gcode. The gcode I am not sure if is OK, but it gets generated. The dwell time must be set to "0" in Fusion CAM in order for it to work. I checked some other PPs and it seems to be the case in most of them - if dwell > 0 then it expands the cycle to individual coordinates, if it is zero it will generate appropriate cycle type, in this case G83. Why that is so is beyond me for now, but I guess if it works for ther PPs then why not for grblHAL?

I added G73 to supported cycle types. It generates a valid??? gcode too.

Sample gcode from Fusion PP with all 4 cycles is attached. Repo updated.

g81-83_and_g73_test_nc.txt

Edit: I see in the file that g82 was generated as g81... Will have to check it too Would you mind looking at the file to see if it's OK or it needs some modification?

[terjeio]

Maybe create a new thread for this, or wait for new repo?

A new thread is better if more issues arise, I'll create the new repo under the grblHAL account but issues with the sender should still be reported at this repo. We should finish this thread here as it is IMO close to be resolved.

The gcode I am not sure if is OK, but it gets generated.

It is ok.

The dwell time must be set to "0" in Fusion CAM in order for it to work. I checked some other PPs and it seems to be the case in most of them - if dwell > 0 then it expands the cycle to individual coordinates, if it is zero it will generate appropriate cycle type, in this case G83. Why that is so is beyond me for now, but I guess if it works for ther PPs then why not for grblHAL?

The reason is that G83 does not support the P dwell parameter. grblHAL is ok with the generated G83, the sender is buggy. FYI grblHAL inserts a 250 ms dwell at the bottom of the hole.

I added G73 to supported cycle types. It generates a valid??? gcode too.

It is valid but the sender incorrectly barfs at repeated commands without R words. grblHAL is ok. LinuxCNC is not a standards quality specification, it is just documentation - which is sometimes hard to understand. For G8x canned cycles it states that the R word is always "sticky", for G73 not - and states that it is an error if the R word is not supplied. For me that is ambiguous...

Note that the G73 retract distance can be set with $28 and defaults to 0.1 mm. This since LinuxCNC states "Rapid up a bit", I have no idea what "a bit" is in a machinists world and it can't be programmed...

Edit: I see in the file that g82 was generated as g81... Will have to check it too

The previous file was ok.

Would you mind looking at the file to see if it's OK or it needs some modification?

You mean the PP?

New edge version of the sender is up.

[raenji-sk]

You mean the PP?

I meant the generated gcode file, but of course feel free to look at the pp code if you want. If you want to do that i suggest using vs code and the pretty cool autodesk hsm plugin.

The G73 i got from a Uccnc pp, as linuxcnc does not have it implemented, atleast not the one in the official autodesk library.

There are ways to set the dwell time and retracts in the pp i think, I'll have to study the fusion360 pp documentation and other PPs more to see how it should be done. Don't know what the default values are. It's all new to me.

I'll take a look at the rest when I am at the desktop pc and will update the thread if I make some updates or find something of use.

[terjeio]

The G73 i got from a Uccnc pp, as linuxcnc does not have it implemented, atleast not the one in the official autodesk library.

LinuxCNC supports G73, but it is not a NIST RS274 specced gcode.

There are ways to set the dwell time and retracts in the pp i think

Not possible for G73 and canned cycle commands such as G83 that do not have words implemented for them. G0/G1/G4 commands has to be issued instead. The "G73 retract distance" I wrote above is the "Rapid up a bit. " distance.

Don't know what the default values are. It's all new to me.

Usually there are no default values for words - if not supplied they are not acted upon. An exception is the L word in canned cycles, this defaults to 1. Many words are "sticky" meaning they keep their value for subsequent commands. Some during the whole program some not. E.g. when a canned cycle gcode is issued (G81,G82...) "sticky" words related to the gcode is unset¹, at least this is how I have implemented it. This means every time a new canned cycle command is issued the R word has to be supplied or an error is raised. The canned cycle gcode is kind of "sticky" too as it stays in effect until a different motion command (or G80) is issued.

I guess this is why all required parameter words are supplied by the PP when a new canned cycle sequence is started.

¹ NIST RS274 and LinucCNC is, AFAICT, not clear regarding this. However, if e.g. the R value is to be sticky across all gcodes there has to be several variants of it as it is used by other gcodes for unrelated purposes.

[raenji-sk]

Alright, thanks for explaining. It's a lot to take in all at once ;)

LinuxCNC supports G73

I know, but it was not enabled/coded in the PP, so I had to get it from the UCCNC/CNCDrive one.

I think for now the PP should be OK, testing all of it would be nice. I can try the canned drilling cycles when I have some time. As for the 4th axis I can only do simulations as I don't have hardware for that. Added the option into grblHAL PP to select whether the A, or rotarty, axis is placed along X or Y and updated the repo. Will resimulate the test toolpath I have modelled in Fusion and see if it atleast looks OK.

[einencool]

Hello, I would like to ask how this new feature works? I updated the Teensy Board with the latest firmware and got your p34 Sender from your page.

But I don't know how the work flow was planned. I tried an extreme example and rotated the plate around 15 degrees. It doesn't matter in which order I probe the edge, the result is always not satisfying. My x0y0 point is always about 2mm off of the edge. How is the zero point been calculated? In my understanding it would be the right way to check the angle at first and then probe the edge on the other side and calculate with an 90 degree angle.

Here is a picture from my trials. You can see, that the x0y0 is not over the edge