-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Current workflow for semi-automatic tool changes #29
Comments
OK, looks like bCNC isn't following tool change protocol because it's tries to send commands from g-code file while grblHAL is in Tool state https://github.com/grblHAL/core/wiki/Manual-tool-change-protocol . That leaves us with the first question only. |
The behaviour depends on the $341 setting. The explanations for the different variants could be better though.
There has been a few but at the old repo.
Yes - as explained in the Wiki the sender has to acknowledge the tool change and allow jogging and setting offsets (and allow the special $ -commands depending on the mode - possibly via MDI or macro input).
It should be part of the sender specs? The tool change protocol is a grblHAL specific extension so it is unlikely any senders beside ioSender supports it? AFAIK some senders traps M6 and implements some kind of tool change protocol sender side, and some senders strips M6 altogether? |
Yep, that will help a lot. For some reason in Maybe it will benefit to have an explicitly specified physical tool change location in machine coordinates(something like G30 http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g30-g30.1 or maybe G59.2)?
Nice, I'll explore them. But right from the start I could confirm behaviour with soft limits alarm after tool change ( terjeio/grblHAL#225 ). My tests revealed it's connected to tool difference between probe tool and working tool, if probe is shorter, alarm is raised right after working tool returns to resume point in XY-direction and before Z-move. bCNC has the same behaviour because it makes return moves in working offsets and not via G53 or G28. So if it's not enough space in Z, soft limits alarm is raised.
Yes, bCNC has such implementation with WCS translation:
|
It should make one move - either to Z home or Z home - 1 depending on a setting. What are the g-code commands prior to the M6 in your program?
G59.3 is used by linuxCNC for tool changes/tool probing so I selected that for grblHAL too. I do not want to claim an additional position/offset, IMO modify your post-processor to move to a specific position on tool changes if you want a different position from what is already supported by $341. I have considered adding a setting for the initial Z target (as an offset from Z home), this is hardcoded now. Perhaps one for the probe retract distance as well: Lines 31 to 38 in b685e18
Is your g-code program moving to the Z home position before the M6? The tool change algorithm will move the controlled point (the tool tip) back to the position it had before the M6, if the new tool is longer that will be beyond Z home. Change the post-processor to move to a position with enough headroom or not move at all. |
Sorry for my delay with answer :-(
Yep, it's my bad, configuration difference with previous setup on plain simple grbl and bCNC. It's has G28 move for clearing probe/end mill from workpiece before first tool change(G28 position was set higher than used to be):
But still, if home position shown as Line 342 in b685e18
Anyway to which $-parameter
LinuxCNC doesn't have hardcoded tool change routine, it's basically scripted so anyone could alter tool change behaviour to suit they needs, in LinuxCNC no need to modify post-processor for every setup out there. My fellow LinuxCNC user says that G59.3 offset in no shape or form is designated as tool change position in LinuxCNC.
For clearing probe/end mill off workpiece I've G28 move in header:
Second tool change:
I think standard grbl post-processor in Fusion360 has same behaviour with G28 in header. Why in tool change routine move in work offsets is needed? Wouldn't TLO be applied in first moves after M6? |
Because I choose -1, currently it can only be changed by either editing tool_change.c or adding LINEAR_AXIS_HOME_OFFSET as a symbol on the compiler command line.
Z-motion is negative in the down direction, to avoid confusion I used a negative value. If I move it to a setting a negative value will be the most obvious for users too?
Issuing
Sloppy comment from me, IIRC it is commonly used as the location of the touch-off sensor often used in combination with tool changes. Sorry for that.
Yes I believe so. With grblHAL this causes problems with the tool change algorithm. Grbl does not support tool changes so I guess it was added as some kind of workaround?
I am not sure what you mean by this. TLO is applied by the tool change algorithm after probing is completed, then a move to Z home followed by a move to the original XY position and finally to the original Z position (before the M6) is performed. Perhaps setting the TLO should be delayed until just before the final Z move? |
I've done few test with Purpose of LINEAR_AXIS_HOME_OFFSET is to move axes away from home/limit switches during toolchanges, right? But if
Autodesk has strange policy about editing post-processors, it could be done without much discussion by anyone's request, so with G28 and M6 it was back-and-forth for a few times. I'm not sure what is background for that.
I think I would like to try using tool change routine without that final Z move, I don't see why it's needed. Maybe it is possible to comment or alter few lines of code in tool_change.c file so I could check it? |
Correct, why it has been done like this I do not know. Should it be changed to the $27 pulloff distance (with sign determined by the homing direction) to be consistent with Set machine origin to 0 set to false? There is another related issue that bothers me a bit, it is currently not possible to know if G28 and G30 positions has been explicitly set, they both defaults to 0,0,0 - and should in principle default to unknown (NAN)? In addition G28 and G30 should error out if the machine is not homed or the positions has not been set? There is a warnining in the LinuxCNC about not using these commands if not homed or positions not set - but I do not know what will happen if issued regardless...
Yes it is offset the
Yes, you may try that. The final move is required if not done in the gcode - impossible to know what a post-processor will output... IIRC this is where the move is performed: Lines 128 to 129 in 222ba55
|
I was checking LinuxCNC documentation for in depth explanations and I must say it has quite a different procedure for setting origin and home position. Should grblHAL use it as a reference? Online http://linuxcnc.org/docs/html/config/ini-homing.html
I think it should be at least consistent, if not then max travel distances($130,131,132) would be different between these two settings. Will it somehow affect rotary axes? Never had one, so no experience with them.
LinuxCNC documentation states that explicit setting of machine origin from axes home switches is needed for lathes. Chapter 3.7.11:
So maybe in grblHAL origin offsets from home switches(HOME_OFFSET in LinuxCNC) should also be used? BTW is HOME_OFFSET from LinuxCNC have something to do with LINEAR_AXIS_HOME_OFFSET in grblHAL???
I don't see why it would be a bad idea to post an alarm if the machine is not homed but G28/G30 commands are issued. Regarding checking if they were purposely set: if it's possible to do without much effort, it would be great to have such check, countless number of people had problems with G28 when it was enabled by default in Fusion360’s post-processor dialog and they didn't set that offset in grbl.
It's so many options(shared/separate limit and home switches, only home switches with soft limits, only limit switches) that it's tough to say what is a good idea and what is not :-)
Thank you, I'll try that. |
Hi. Blessings from outer space. Thank you |
@CHTUZKI You have to hook your code into two function pointers, see this incomplete example. The function pointers are |
HI. |
You should set the HAL function pointers to your functions and set the
No - and since your code is for you only you should name your init function that set the function pointers and capability flag |
Hi terjeio, I think i have a similar issue, and wanted to ask for your expertice. When i do my first M6 Toolchange (not tool length offset is set) , and my starting position is at zMax (machine origin 0,0,0) It will automatically move to g59.3, measure the first offset and return to zMax. If i now insert a longer tool, do the m6 toolchange it will measure, but then drive to zmax+ measured offset and hit my z limitswitch. So it seems for.me the m6 toolchange changes to machine coordinate system, and when going to zMax, it will trigger the limit switch. If i do these tool length sensor measurements in IO Sender manually, it will change the WCS. May i ask for your advice? Thanks Christoph |
It is:
And my settings are:
|
Thanks, I have to recap a bit...
No, it changes the tool offset only. However if a G28 or G30 with axis parameter(s) follows the M6 this will move to the position specified including offsets before moving to the saved absolute position. E.g. a G28Z0 may trigger the Z limit switch. |
I don't have any code loaded, i am just at machine 0,0,0. I type t1 m6 in the CLI, and it will do the first tool change with the short tool. Than i change to a longer tool , type t2 m6, and it will measure the second tool, return to z max, and hit the limit switch. And the MCS now shows 0, 0, 3.833 The Gcode i would use, would look like this: |
Ok, you start the initial probing from Z0 which is with the spindle fully retracted? This cannot work as there will be no headroom for a longer tool. Does it work with the spindle further down (negative Z)? It does for me. |
Yes exactly, i start at z0, which is the spindle all the way up. Yes when my i start the m6, with the spindle further down it works. Then it will travel to zmax, and go down to the position, where i started the m6 command, even if the new tool is longer than the previous one. Is there a workarround arround this? |
Yes - since it is not possible to return the controlled point (the tool tip) to the previous position unless there is room for the movement. Raising an alarm is IMO the correct action. |
Has this something to do with the hardcoded defines, mentioned earlier? `// NOTE: only used when settings.homing.flags.force_set_origin is true #ifndef TOOL_CHANGE_PROBE_RETRACT_DISTANCE Or does this something completely unrelated? |
No. But I believe you can add some headroom by increasing the homing pull-off distance ($27). |
Ok thank you very much for the quick response! i'll try the pull off distance first, but it will change the distance of all limitswitches, there is no explicit setting for z right? |
No. |
But you can add a startup command to move Z down a bit. |
Out of curiosity, why is return to previous even necessary? Doesn't the next operation after a toolchange move the toolhead to the start position? Seems like the redundancy is just a possible cause of error without a measurable benefit, unless there's something I'm unaware of? |
From NIST RS274NGC v3 paragraph 3.6.3: "The coordinate axes will be stopped in the same absolute position they were in before the tool change (but the spindle may be re-oriented)." I read that as the absolute position of the controlled point (tool tip) in the real world.
Via which path? IMO it is safer for the controller to return to the original position "known" by the gcode than having the CAM program add code (defined in the post) for movements from some arbritary position. It is simpler to just move the controlled point to safe Z (or Z clearance) before the the tool change and let the controller return to that position? |
i believe this is a clash between the common ATC usecase and our manual toolchange usecase.
While it says that the spindle may be reoriented, trying to force the same position of the controlled point may, as seen above, result in problems when switching to longer tools
Isnt the toolchange position also an arbitrary position just the same as the TLS location? And it could be argued that it is difficult to get the controlled point to a safe z since it's an arbitrary point below the spindle collet and defaulting to absolute z axis position at z-home is the 'safest' point there is regardless of the current TLO? |
Comment out this line (or more motion commands in the restore() function) to get the behaviour you want: Line 132 in 2f42b72
I might either make it a compile time choice or a setting to change the behaviour, the default will be the same as now for backwards compatibility. I am a bit unsure if you want motion to the original XY at Z0 or if you want to leave the controlled point where it was after touch off is completed. |
I would prefer move to G28 Z0 at the toolsetter and wait for next operation gcode to move to starting location. For example, if the first tool op ends at the opposite corner of the CNC from the toolsetter, and the second tool op starts next to the toolsetter, then there's a wasted move returning to the end of the first tool op location. Afaik a new operation will always start with an absolute XY in G5x to the next lead in starting point. |
What LoganFraser is trying to say is the current mode of operation for Semiautomatic Toolchange at G59.3 is:
this has the issue that it runs into problems when your G28 location is still at MCS 0 because the Z-Axis cant raise higher than the MCS without crashing or hitting limit switches. That is the issue that clehn8ok is encountering. (Proposed and confirmed workaround is setting your G28.1 to a lower z-height that accomodates your lagest tools so your last location is not at z-max) Result:
In my mind this behaviour would also still be in compliance with the NIST standard your posted. |
@Dietz0r The current sequence is:
This can fail because the intermediate target Z includes the tool offset. If you want to go to Z home you have to use G53G0Z0 and is what the tool change code does.
I do not agree - XY is not in the same position as before the M6 (and neither is Z). |
hmm... i must have missunderstood a lot then. thanks for clarifying and thank you for your patience explaining it. |
Setting |
Hi,
I'm curious what is the current workflow for tool changes at
Automatic touch off @ G59.3 ($341=3)
mode? Wiki has two places with descriptions( https://github.com/grblHAL/core/wiki/Additional-or-extended-settings , https://github.com/grblHAL/core/wiki/Manual,-semi-automatic-and-automatic-tool-change ) but they are not reflecting actual state of things. From wiki I had impression that firstly tool is moved to home position for physical change then it moved to G59.3 offsets for automatic touch off but my tests revealed that there no move to home position just lift in Z direction, then afterCycle Start
tool is moved to G59.3 offsets.Maybe there was some discussions about semi-automatic changes in grblHAL? Looks like search engine on github was changed recently and searching for anything has become quite difficult :-(
Also are tool changes in semi-automatic mode g-code sender dependent? How could I understand that sender handles tool changes correctly?
I'm trying to configure STM32F4 driver with custom BOB for BlackPill on my router setup(bCNC on rpi3 under NetBSD), I'm using latest bCNC sender, grblHAL configuration is:
I'm not sure why TLR reference was removed from parameters here after second tool change and replaced with TLO.
The text was updated successfully, but these errors were encountered: