Probing and gcode rotation #94
Comments
|
It is on my todo list, to be added sometime after the first production release. |
|
Perfect. Let me know in case I could help with testing it for example. |
|
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. |
ioSender should support both camera and mechanical probing. I want camera support when drilling and milling PCBs.
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. |
Yeah, camera probing is excelent for theese tasks and helps a lot with the exact alignment of a PCB.
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. |
It is.
Repeated canned cycles may be problematic, G5 spline too? These are not widely used so a minor issue.
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.
It is based on Grbl_ESP32 - and in violation of the license?
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. |
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.
Surely. I have not looked into this yet, and it might only affect canned cycles with a repeat parameter, |
|
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... |
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.
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.
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. |
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. |
|
@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... |
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. |
|
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... |
|
Tried the rotation with a simple program with XY arcs only. XZ and YZ are disabled in the post processor. |
|
@raenji-sk Thanks for the feedback. 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:
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. 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. |
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?
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...
Again a bug.
Another a bug? I'll have to connect an Arduino controller and check.
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. 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. 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.
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.
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. |
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.
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. |
|
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. |
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... |
|
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. 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. Edit: I see in the file that g82 was generated as g81... Will have to check it too |
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.
It is ok.
The reason is that G83 does not support the
It is valid but the sender incorrectly barfs at repeated commands without 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...
The previous file was ok.
You mean the PP? New edge version of the sender is up. |
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. |
LinuxCNC supports G73, but it is not a NIST RS274 specced gcode.
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.
Usually there are no default values for words - if not supplied they are not acted upon. An exception is the I guess this is why all required parameter words are supplied by the PP when a new canned cycle sequence is started. 1 NIST RS274 and LinucCNC is, AFAICT, not clear regarding this. However, if e.g. the |
|
Alright, thanks for explaining. It's a lot to take in all at once ;)
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. |
|
Hello, I would like to ask how this new feature works? But I don't know how the work flow was planned. Here is a picture from my trials. |
|
@einencool Good question. Is the 0,0 origin set to the corner before probing and is the job origin the same? Have you tried with selecting the rotation center before probing, maybe like this?
Or did you probe with no job loaded? If you had a job loaded can you share that?
I have not given it much tought since it is perhaps a bit complicated depending on the job? Establishing and selecting the correct rotation center first is important - if possible... |
|
Hi @terjeio I didn't know what the points for rotation center are for. In an old thread that you took for your buildings of the probing tab from another software, there was also the discussion about the origin while rotating the workpiece. Now in this state it's a nice to have, but without the correct alignment sadly not usable. |
|
Using a corner finding probe with a hole centered above the XY0 seems to do the job. First run the center probing wizzard to find the center of the hole and then use angle probing to determine the angle. |
|
In this case you are right, but when there is such an option, than it should work as supposed. But when we have to use a corner finder with hole , than this should be mentioned directly in the program. Because for now it doesn't give the right values. But Terje has a hint in the program, that it should be used with care, and these are my thoughts, to get this feature work in the right way :-) |
|
I'd say it is not polished in regard to user friendliness, but it was added only recently. Also some sort of documentation would be helpful for sure. |
|
Yes you're right, and I followed this great software nearly from the beginning and mentioned this point around one year ago ;-) So I'm also very happy that it is going to be THE perfect program. Here you can see the discussion last year :-) |
|
I have not spent much time with actually using the rotation functionality other than checking that the transform works. To make it work as expected I belive the rotation origin and the CAM output has to agree. Currently X0Y0, corners, mid edges and center are supported. I could add manual input for the rotation center (and tool diameter too?) but it will be better to generate gcode that matches the choices currently available? I have a feeling this could get a bit complicated... |
|
I‘ve just read a little bit about rotation and the X0Y0 Point. When I understood it right in the „Vers.by“ article, then the rotation should be done at first, and after that, the origin Point should be measured. But after the coordinate System is rotated, the Measurement / Probing should work in the „new coordinate system“. So the points will be touched in the „rotated angle“ and you have always the right point for probing. This is also how it‘s done on a 3D coordinate measuring machine. The Points are touched in the „vector direction“… This is a screenshot from the „vers.by“ Homepage I linked in the other thread: |
|
Oh, one extra point, can you please add an extra field for the „edge length“? |
This is for LinuxCNC where a command is sent to the controller to rotate the coordinate system. Grbl/grblHAL does not support that, instead the gcode itself is rotated in the sender. I would think that makes quite a difference. To make ioSender behave the same way the rotation has to be applied on the fly to every gcode command sent to the controller, even probing commands. I'll rather such add rotation support in the controller than the sender as I fear adding it to the sender will be a lot of work and quite messy...
Instead of using "Offset" as I do now? |
|
Ah ok, didn‘t know, that LinuxCNC works different in this area. In my opinion it would make more sense to add an extra field in the „rotation tab“ for the „edge length“ so that you have the normal „offset“ how far the probe clears the edge for the first touch off, and after it clears the edge it should drive the desired „edge length“ (maybe 100mm) for the second probing point. If it would be the „normal offset“, the distance is really small (for me around 5mm) and if I set it for the rotation to 100mm and forget to redo it, then it could crash into my workholding clamps or something similar. But maybe I just want to much :-) |
That would be pretty cool. It works for me as it is now. I have one part that needs finishing tomorrow. I want to add a chamfer on the back side and plan to use the rotation probing to get it spot on. Will let you know how it went. As for the naming of the offset vs edge length, it was pretty obvious what was what. But I'd welcome something like they show on vers.by website. Give each parameter a name (letter, number) and display them in the "probing wizzard" picture. That way it would be super clear to see wich parameter influences which move during the probing routine, and not just the angle probing, but all of them. |
|
@terjeio @einencool |
|
Look good, and when you are working with a touch plate with the hole for the corner it should work very good. But the calculation for users without touch plate is sadly not correct. But like I said, when the users are satisfied with it, then there should be a hint in the program. That the rotation should only be used if a touch plate with hole is used. Then everyone could decide for himself, if he will use it, or not :-) Because whole only using a 3d finder or something similar, the corner itself is not calculated correctly, the rotation itself is working fine... |
|
Well while I did make a corner probe, I used the hole center to find its own xy0 and not to locate zero on another part as the corner probe was the actual part being machined. I machined one side and then turned it around to make the chamfer. The larger plate underneath was just sort of a placeholder. Don't have a fancy 3d probe yet, but should it not be even easier and more precise to locate the xy0 with let's say a probe from Vers or Sorotec? I mean you can locate any feature in the part when doing the second side, like hole, boss, pocket etc. Or use a locating dowel pin, corner of a vise jaw, a jig... And just reference that in CAM as workpiece xy zero. I think there are not many occasions you have to rely solely on the xy0 in one of the corners. But yes, ideally it should work on the rotated corner as well. |
well, when the workpiece is not square to the axis, it is in this case not possible with a 3d Finder to probe the edge absolutely perfect. Like i mentioned a few posts ago, the calculation is not correct and so the x0y0 is not perfectly aligned. (See the picture of my 3D Finder, then you see that x0y0 is around 1mm off per side) When you add a touchplate with hole above the edge of the workpiece, it’s no problem with a 3D Finder, because the calculation for a round part is always right, and so the edge will be measured correct. if it’s not clear what i mean, I’ll add a sketch to show what i mean :-) :Edit and this is CENTER Finding with extra Touch Plate. and because of this problem the rotation function is not really usable because the X0Y0 is not set correctly |
|
@einencool can this be solved by adding a offset to corner probed XY position based on the angle and the diameter of the probe tip? |
|
Hmm, I can't imagine, that this will really work, because you never get the "real" edge. For my thinking it would only be possible, to probe all 3 points in one shot. Then you get the straight line and one point on the other side and then you can calculate the rotation and the edge... |
|
Let me join the drawing frenzy 🤣 Looking at some Haas CNC videos they probe both X and Y for angle for example.
On the other hand I find this to be most useful for double sided jobs. The first side easy to either align or machine so that its square with the CNC. But when doing the other side you most likely have a boss / hole, pocket feature somewhere in the part already. So you can probe that for XY 0 and also use that as XY 0 in CAM. That's something I did and it works. And you do not need a touch probe with a hole for any of that.
In the video I did make a touch probe, but I probed the probe itslef... So something like example no.2. If the hole was elsewhere it would not matter as it would rotate the gcode around those other coordinates. It maybe is a bit confusing example with the touch probe being machined.... Also, what seems to be a problem with using one? It's easy to make or buy one. |
|
The HAAS way should work even if the two sides are not at a right angle? Do you have links to the videos? |
|
Only one point from my side, and then you can do what you think... 3 points for a surface (Z-Axis) If you need more of this, then the software begins to compensate points, and what way you would rotate, if the workpiece has only 88dg and not a (theoretical) right angle? Just my 2 Cents... |
|
@einencool We can discuss more options. I just suggest what I think is OK based on how I use the CNC and what I've seen on many videos showing probing not only on hobby grade routers but mostly big VMCs. @terjeio https://www.youtube.com/watch?v=amWolMgEM-Q Here's the video from HAAS showing their probing macro. |
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.
The text was updated successfully, but these errors were encountered: