ioSender
ioSender copied to clipboard
terjeio
Probing and gcode rotation
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.
It is on my todo list, to be added sometime after the first production release.
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."
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.
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.
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.
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?
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.
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?
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...
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.
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.
Perfect, if I'll have a bit of time to spare tomorrow I'll give it a try.
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.
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.
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?
@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...
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.
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.
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.
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...
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
@raenji-sk Thanks for the feedback.
New edge version uploaded where rotation center (origin) can be specified, based on Program limits values.
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
-
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
-
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.
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.
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.
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.
@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.
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.
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.