Closed terjeio closed 4 years ago
Sounds interesting, I'll give it a try when it will be released :-)
New release now available in the test branch. A compatible release of my sender application has also been published.
Hello, a lot of things happened during the summer break I once allowed myself. You have been very active. I have to work on everything that is new. Today I have taken a look at the new tool change mode and have also started a few attempts. Unfortunately I did not get very far with my attempts. Everything refers to Beta 4. My approach was to set workpiece Z zero point in the edge finder tab. Then I set the reference offset in the tool length offset tab. Unfortunately, when reaching the M6 command an error46 occurs. Is my approach wrong or is the mistake somewhere else? ;)
Regards Stefan
The new tool change functions requires the machine to be homed, error 46 relates to that. See the status line in your last image, the message is a bit misleading - should be changed... Perhaps I should issue a warning before the program is started if not homed and there are tool change commands?
Note that I am currently working on improving tool changing - it is not working correctly in all circumstances. I am currently busy with other work so it is likely it will be a few days before any updates are ready.
Sorry i forgot to tell you that the machine will be homed at every startup. The error also occurred after immediate homing. Maybe my approach is wrong too?
Perhaps I should issue a warning before the program is started if not homed and there are tool change commands?
Would certainly be very helpful to avoid such errors.
Note that I am currently working on improving tool changing - it is not working correctly in all circumstances. I am currently busy with other work so it is likely it will be a few days before any updates are ready.
O.k. I am curious about the results.
Could be that you have A-axis enabled? When homed the Home button should get a green background. Will have to check if a enabled A-axis is messing up checks in my code.
Could be that you have A-axis enabled? When homed the Home button should get a green background. Will have to check if a enabled A-axis is messing up checks in my code.
Yes the A-axis is activated, but only the linear axes are homed at my machine.
I have commited a new version to the test branch as well as a new sender beta. Hopefully this will behave better.
Hi terjeio, would it please be possible to write a small workaround how to proceed with a tool change, as you thought. After countless tests i can't find a solution. Of course everything refers to the last test branch grblhal and the last beta version of the GRBL GCode Sender. First of all, to make it simple, it's all about that: manual touch off (1) Here is a piece of g-code i use for testing: G17 G21 G90 T1M06(MSG,End Mill 8 mm wood) G0Z10.000 G0X0.000Y0.000 M3S18000 G4 P5 G0X0.000Y2.320Z3.000 G1Z-3.000F1400.0 G1X-0.305Y2.300F2800.0 G1X-0.619Y2.236 G1X-0.932Y2.125 G1X-1.233Y1.965 G1X-1.512Y1.759 G1X-1.759Y1.512 G1X-1.965Y1.233 G1X-2.125Y0.932 G1X-2.236Y0.619 G1X-2.300Y0.305 G1X-2.320Y0.000 G1X-2.300Y-0.305 G1X-2.236Y-0.619 G1X-2.125Y-0.932 G1X-1.965Y-1.233 G1X-1.759Y-1.512 G1X-1.512Y-1.759 G1X-1.233Y-1.965 G1X-0.932Y-2.125 G1X-0.619Y-2.236 G1X-0.305Y-2.300 G1X0.000Y-2.320 G1X0.305Y-2.300 G1X0.619Y-2.236 G1X0.932Y-2.125 G1X1.233Y-1.965 G1X1.512Y-1.759 G1X1.759Y-1.512 G1X1.965Y-1.233 G1X2.125Y-0.932 G1X2.236Y-0.619 G1X2.300Y-0.305 G1X2.320Y0.000 G1X2.300Y0.305 G1X2.236Y0.619 G1X2.125Y0.932 G1X1.965Y1.233 G1X1.759Y1.512 G1X1.512Y1.759 G1X1.233Y1.965 G1X0.932Y2.125 G1X0.619Y2.236 G1X0.305Y2.300 G1X0.000Y2.320 G1X0.000Y6.000 G1X-0.789Y5.948 G1X-1.600Y5.783 G1X-2.409Y5.495 G1X-3.189Y5.082 G1X-3.912Y4.550 G1X-4.550Y3.912 G1X-5.082Y3.189 G1X-5.495Y2.409 G1X-5.783Y1.600 G1X-5.948Y0.789 G1X-6.000Y0.000 G1X-5.948Y-0.789 G1X-5.783Y-1.600 G1X-5.495Y-2.409 G1X-5.082Y-3.189 G1X-4.550Y-3.912 G1X-3.912Y-4.550 G1X-3.189Y-5.082 G1X-2.409Y-5.495 G1X-1.600Y-5.783 G1X-0.789Y-5.948 G1X0.000Y-6.000 G1X0.789Y-5.948 G1X1.600Y-5.783 G1X2.409Y-5.495 G1X3.189Y-5.082 G1X3.912Y-4.550 G1X4.550Y-3.912 G1X5.082Y-3.189 G1X5.495Y-2.409 G1X5.783Y-1.600 G1X5.948Y-0.789 G1X6.000Y0.000 G1X5.948Y0.789 G1X5.783Y1.600 G1X5.495Y2.409 G1X5.082Y3.189 G1X4.550Y3.912 G1X3.912Y4.550 G1X3.189Y5.082 G1X2.409Y5.495 G1X1.600Y5.783 G1X0.789Y5.948 G1X0.000Y6.000 G0Z3.000 T2M6(MSG,V-Bit (60 deg 14 mm) wood) G0X0.000Y10.768Z3.000 G1Z-3.000F1400.0 G1X-0.264Y10.765F2500.0 G1X-0.530Y10.755 G1X-0.799Y10.738 G1X-1.069Y10.715 G1X-1.342Y10.684
btw a bracket in the bracket at the tool change command gives an error, seen in the second tool change command, tool2 ;) btw 2 the error error 46 is fixed in the last beta
If the bracket is the problem then your gcode is not compliant with NIST:
3.3.4 Comments and Messages
Printable characters and white space inside parentheses is a comment. A left parenthesis always starts a comment. The comment ends at the first right parenthesis found thereafter. Once a left parenthesis is placed on a line, a matching right parenthesis must appear before the end of the line. Comments may not be nested; it is an error if a left parenthesis is found after the start of a comment and before the end of the comment.
If the bracket is the problem then your gcode is not compliant with NIST:
no sorry the brackets were only a minor problem, they are very easy to delete.
The real problem is to know a tool change sequence, just as you thought. So here is a little tutorial on how the tool change should take place. As I said before, I can't really handle the wiki. A short description would be very helpful. I would like to help you a little bit, but I need to know the procedure to report possible errors.
With $341 = 1:
Select first tool in the program (tool 1 in your example) by issuing M61Q1
in the MDI. The Q
value is the tool number.
Select the probing screen and clear any tool offset in the Tool Length Offset tab - there will be a button there to clear it if it is set. [edit: "... any reference offset ..." -> "... any tool offset ..."]
Place your touch plate on top of your work piece and enter its height in the Touch plate/fixture height box.
Jog to place the tool in position over the touch plate and select the Edge finder tab and then probe Z. This will establish Z zero on top of the workpiece.
Select Tool Lenght Offset tab and probe again with Establish reference offset checked.
IMO the two previous steps should be combined into one, in the Tool Lenght Offset tab?
Remove the touch plate and start the program. The first tool change to tool 1 will be ignored as it is already set up.
When the next tool (tool 2) is selected the Z axis will back off to the home position. Jog to XY where you want to change the tool and change it. Place the touch plate on top of the workpiece again and jog into position to probe it. Issue $TPW
in the MDI (or run a previously created macro for it), this will establish the new tool offset. Remove the touch plate and press Cycle Start to continue the program.
"on top of your work piece" could be anywhere convenient to establish the reference needed, it does not have to be on top of the workpiece. If this is on a fixed position on the machine then $341 mode 2 or 3 may be a better choice.
I hope this helps for now - I am soon ready to dig into the tool change/probing stuff again so any feedback will be appreciated.
Thank you for this „manual“ :-)
I would like to test it tomorrow, so just two short questions for this.
IMO the two previous steps should be combined into one, in the Tool Lenght Offset tab?
Yes I would think that makes sense, because in the past I didn‘t know that you mentioned it this way.
So when I set the Z=0 on top of my Workpiece, then I can set the „Reference“ maybe in the Baseplate in front of my Workpiece (maybe 40mm deeper) and after a toolchange I can also set the second TLO in front of the Workpiece?
And I have to Enter „$TPW“ into the field in the bottom left? And this could be linked to an Macro which could be started with the shortcuts?
I want to use the $341=1 because sometimes I can‘t use the defined position for the TLS and then it would be easier to make it this way...
Oh, one more question :-)
When I use the 3D-Finder in my machine, I don‘t have a ATC-Spindle, so my Tool length changes every time. When I Set my X & Y Zero with the 3D-Finder, can I Set the Z-Zero with the 3D-Finder and reference it on the TLS and when I start the Program, I will be able to set the Offset with the TLS?
Well, that's something to work with.
Thank you very much for the short description.
I will definitely do some tests tomorrow and report very soon.
So when I set the Z=0 on top of my Workpiece, then I can set the „Reference“ maybe in the Baseplate in front of my Workpiece (maybe 40mm deeper) and after a toolchange I can also set the second TLO in front of the Workpiece?
Yes, this should work - it is important that the touch plate height is set correctly.
And I have to Enter „$TPW“ into the field in the bottom left? And this could be linked to an Macro which could be started with the shortcuts?
Correct. Cycle start will be ignored until this command has been run.
When I Set my X & Y Zero with the 3D-Finder, can I Set the Z-Zero with the 3D-Finder and reference it on the TLS and when I start the Program, I will be able to set the Offset with the TLS?
Not sure I understand or if this will work, you want to probe the touch plate with the 3D-Finder to set the reference and then set the actual offset by probing again with the tool?
When I Set my X & Y Zero with the 3D-Finder, can I Set the Z-Zero with the 3D-Finder and reference it on the TLS and when I start the Program, I will be able to set the Offset with the TLS?
Not sure I understand or if this will work, you want to probe the touch plate with the 3D-Finder to set the reference and then set the actual offset by probing again with the tool?
Yes i think you are right... i made a little mistake in my thinking...
I can’t connect the 3D finder and the TLS At the same time.
So i would like to touch off the workpiece directly with the 3d finder . Then touch off the baseplate Directly as the reference... I have to set the height of the probe plate also for the 3d finder, because only the difference between the two surfaces matter (i think) And after that i have to measure the tool length offset with the tool and the TLS on the Baseplate.
Would this be the right workaround?
I have to set the height of the probe plate also for the 3d finder, because only the difference between the two surfaces matter (i think)
You have to consider the difference between the probe and the tool as well?
Would this be the right workaround?
I could be, why not just try it to find out?
I'll try it today :-)
Just wanted to reduce my risk of killing the 3d finder, but now we are able to reduce all the speeds so I can push the button in case of any problems.
I'll report back, if it works or not. Then it could be really simple to measure the x y and z axis directly and then just generate the offset for the endmill
First results. I followed your instructions exactly and got the following error.
Also I do not get a clear button in the tab tool length offset.
But the tool window (Tool 1) turns green. No TLO is visible in the console either. The feed rate settings $344 have no effect or think only 1/10 of it. With $341=2 the same error message.
Probe Fixture @G59.3 works as described above except for the feed rate. The procedure is o.k..
In the Probing Tab only one entry is possible for the profiles. That worked once? :)
Hmm, very strange, I changed Tool no. 1 with the clickbox in the top right from your sender. This should be for testing my 3D-Touch
Then I changed to the Probing Tab and touched off my workpiece Z=0 Like @S2000Stefan said, the Dropdown for different Touch Probes doesn't work...
Then I changed to the "Tool length offset" tab and make the "Reference measurement" on the Baseplate Then I startet my GCode File (it is without turning the spindle on, it's only to see, if the workflow is correct.
It shows me in the status bar the message for Tool no. 1000 but the Z-Axis doesn't move up or anything else. After around 5 seconds (it's my waiting time for the Spindle) my Z-Axis drives down and wanted to go into my Baseplate. It was just starting in the next lines of the GCode.
Attached is the GCode File, can somebody tell me, whats wrong with it? It doesn't matter if I "Strip" the M6 command or not... Wechseltest atc.nc.txt
:EDIT: One question, what is the difference between Touch Plate and Fixture heigth ?
I have tested with a tool table enabled and not resetting the controller before each test - so I have missed some scenarioes. Testing a fix now.
I have edited the procedure above as I incorreclty wrote that any tool reference offset should be cleared, the correct one is any tool offset. The button only shows up if there is an offset active.
Note that setting the reference offset does not set any tool offset, it just records a reference for calculating the offset applied for subsequent tools. If set the reference offset is reported in a new message in the $#
report: [TLR:nnn]
.
Attached is the GCode File, can somebody tell me, whats wrong with it?
Likely nothing, I'll use it for testing - with the changes I have made it seems to run just fine.
One question, what is the difference between Touch Plate and Fixture heigth ?
Fixture height is not in use yet and may go away - or could be of use when probing with a tool at fixed touch plate @G59.3, this in to establish an absolute position above the table?
I think I should disable fields on the left side depending on which is relevant to the tab selected.
I've got a question for the Shortcut "Alt - R" for starting the Probing Routine.
When I press the Shortcut in the Software on the Keyboard, everything works fine. But when I try to use my Game Controller with the Shortcut set to Alt - R, it doesn't work.
Do you have an idea, why this doesn't work?
What I believe is a fix is now committed to master for testing.
The feed rate settings $344 have no effect or think only 1/10 of it.
Feedrate is reported back correctly in the sender, but I have not timed it yet. Do you see a incorrect rate reported back?
In the Probing Tab only one entry is possible for the profiles. That worked once? :)
It did, but a property change on the control has changed its behaviour in an unexpected way. I need work around that.
When I press the Shortcut in the Software on the Keyboard, everything works fine. But when I try to use my Game Controller with the Shortcut set to Alt - R, it doesn't work.
Does it trigger Cycle Start in the Grbl tab? I cannot think of any reason it shouldn't work for probing if it does.
Fixture height is not in use yet and may go away - or could be of use when probing with a tool at fixed touch plate @G59.3, this in to establish an absolute position above the table?
So I would like that and I understood that the fixture heigth is for a fixed touch plate @G59.3, which I would like to use.
Feedrate is reported back correctly in the sender, but I have not timed it yet. Do you see a incorrect rate reported back?
I can't say whether the advertisement is correct, I didn't pay attention to that. I mean only when the tool moves to the fixed touch plate @G59.3, it makes almost no difference if I enter 200mm or 3000mm feed in $344. I always feel that the cutter moves at 100/300mm.
It doesn't start anything, that very strange. But I have the same Problem when I wanted to start the GCode, it doen'st start it, it seems not to recognice the command.
While in Probing tab and press the "Start" hardware button on the Machine the program starts, and not the probing...
I updated the cnc and the first time it was the same problem as before, it still runs trough without waiting for Toolchange, then i restartet the sender and switched a few times between the tools in the top right corner, then i started it, but then this happens, when i want to touch of with the $TPW Command...
Ah, one extra point, the Z-Axis doesn't move up or anything.
I don't know, but if I understood it right, it should move to the top position when the "M6" Command appears...
What about the Strip or don't strip command, what does this mean?
I can't say whether the advertisement is correct, I didn't pay attention to that. I mean only when the tool moves to the fixed touch plate @G59.3, it makes almost no difference if I enter 200mm or 3000mm feed in $344. I always feel that the cutter moves at 100/300mm.
Regardless of the $344 setting the feedrate will be limited to the $112 setting (Z-axis maximum rate). Could that explain it?
It doesn't start anything, that very strange. But I have the same Problem when I wanted to start the GCode, it doen'st start it, it seems not to recognice the command.
Ok, then the command ALT-R is not recognized at all. Are there any test programs available that can display the generated keycode to see if it is correct?
While in Probing tab and press the "Start" hardware button on the Machine the program starts, and not the probing...
I'll have to check if that is possible to change - I have not coded for the hardware button to starting probing.
I updated the cnc and the first time it was the same problem as before, it still runs trough without waiting for Toolchange, then i restartet the sender and switched a few times between the tools in the top right corner, then i started it, but then this happens, when i want to touch of with the $TPW Command...
Error 46 is issued because the Z-axis is not homed: "When the next tool (tool 2) is selected the Z axis will back off to the home position." $341 mode 1 requires at least Z to be homed, 2 and 3 X, Y and Z.
The $TPW command will return an error if issued outside of the tool change sequence. Maybe I should just ignore it?
What about the Strip or don't strip command, what does this mean?
Strip means that the command is removed from the program on load of the gcode, Prompt will ask first. Should be set to No for M6 when you want run the tool change sequence.
Maybe the Command could be changed from "ALT - R" to something else, because windows recognizes the Command and makes a sound when I press it on the Keyboard, but I don't know what for the Command is. And I don't know, why it works directly in the Software and not with the general Shortcuts.
Please Don't change it to the Hardware button, that was not my intention :-)
After I closed the Software, because the Toolchange just runs through without waiting , I didn't home it and that's why the Error 46 appears. I read about it, and it appears in the Status Bar, but I don't know, why Error 3 comes up. Because I was running the Program, but the Spindle doesn't move up or anything else. But Maybe, I striped the Program, so that the command was not correctly...
because windows recognizes the Command and makes a sound when I press it on the Keyboard
You meant on the Game Controller? You wrote earlier that it worked from the keyboard.
ALR+R works for me on a Win7 machine, maybe Win10 is different and claims it for itself?
Please Don't change it to the Hardware button, that was not my intention :-)
Well, IMO at least it should be disabled when the Grbl tab is not open.
I don't know, why Error 3 comes up
This is likely from the $TPW command beeig issued when not in the tool change sequence.
Maybe it's a windows 10 issue, I'll try it. When I push ALT R in windows directly, then the sound comes up.
With error 3, the status shows, That I'm in tool change mode, in the picture a few comments above you can see it. And it shows me the message for tool "Schaft 1mm"
With error 3, the status shows, That I'm in tool change mode, in the picture a few comments above you can see it. And it shows me the message for tool "Schaft 1mm"
Not in the image above - the program was stopped due to error 46 (homing required). So in tool change mode but not in the tool change sequence. The tool change function called at the start of the sequence exited with the error Status_HomingRequired
:
static status_code_t tool_change (parser_state_t *gc_state)
{
if(next_tool == NULL)
return Status_GCodeToolError;
if(current_tool.tool == next_tool->tool)
return Status_OK;
// A plane change should invalidate current tool reference offset?
gc_get_plane_data(&plane, gc_state->modal.plane_select);
uint8_t homed_req = settings.tool_change.mode == ToolChange_Manual ? bit(plane.axis_linear) : (X_AXIS_BIT|Y_AXIS_BIT|Z_AXIS_BIT);
if((sys.homed.mask & homed_req) != homed_req)
return Status_HomingRequired;
if(settings.tool_change.mode != ToolChange_SemiAutomatic)
hal.on_probe_completed = on_probe_completed;
...
Please have a look directly above error 3, there is the message standing, and in orange there is standing Tool.
I home the machine after error 46... But the status messages are a little bit rare, so you can't see which tool is mounted when sending m61qxxx
I home the machine after error 46...
Then you have to restart the program - there is no way (yet?) to go back a little and restart the tool change sequence. Or do you still get error 46 after homing?
Edit: "no way (yet?)" - (yet?) has to go, homing will potentially change the machine positions used - so sorry, not possible.
Yes ok, now I restartet everything.
Loaded Tool No. 1 (3D-Finder) Measure Z=0 Make Reference measurement
start the Program Machine Z-Axis moves up and says tool Change. Change tool (T 1000), Go to Touch Probe Press "$TPW" Machine zeroes the Z-Axis (I needed two attempts, because I missed the Touch Probe with the second slow run...) Press Start Machine moves up (in some scary ways (not to the Position it endet up (X50 Y0 / it was something like X80 Y120...)) Then Z-Axis goes down with G0 and up again to Home Position then X50 Y0 and then Down to Z=2 Then the program runs till the next Toolchange Z-Axis up
I pushed the endmill 10mm deeper into the collet Go to Touch Probe Enter "$TPW" After that I pushed the start button Z-Axis goes up , drives X & Y some crazy ways and then goes to X50 Y0 Z-Axis goes down (in G0 speed) and down and down and down and down until I pushed the E-Stop button...
:EDIT: This shows up in the other tab
Strange, it works for me with your test program from above. I issue aM61Q1000
from the MDI before starting the program - then the first tool change is skipped, this can be done since the reference offset is already set with this tool. If I do not do so it still works.
Note that at the end of the tool change sequence (after cycle start is pressed) coolant and spindle is restored (a 4 second delay is added a part of that), then a rapid (G0) to Z home followed by a rapid the previous X,Y and finally a rapid to the previous Z is performed. When this is done the program will continue from the same position it were at before the tool change.
Here is the console log from my first run (console logs can be copied as text with CTRL+A and CTRL-C):
[VER:1.1f(MSP432).20200830:]
[OPT:VNMZSL,35,1024,3,0]
[NEWOPT:ES,TC,SS,PID]
[DRIVER VERSION:200818]
[BOARD:CNC BoosterPack]
[GC:G0 G54 G17 G21 G90 G94 G49 G98 G50 M5 M9 T0 F0 S0.]
[G54:101.809,71.066,-10.136]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G59.1:0.000,0.000,0.000]
[G59.2:0.000,0.000,0.000]
[G59.3:95.192,96.332,-16.335]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000,0.000,0.000]
[PRB:0.000,0.000,0.000:0]
[GC:G0 G54 G17 G21 G90 G94 G49 G98 G50 M5 M9 T0 F0 S0.]
[PRB:100.978,56.818,-13.345:1]
[PRB:100.978,56.818,-13.352:1]
[PRB:100.978,56.818,-13.355:1]
[PRB:100.978,56.818,-13.352:1]
[MSG: Schaft 1 mm]
[MSG: Schaft 2 mm]
[PRB:105.000,48.463,-7.427:1]
[PRB:105.000,48.463,-7.794:1]
[MSG:Remove any touch plate and press cycle start to continue.]
[MSG:Pgm End]
@einencool I have been thinking a bit, maybe its will be a good idea to add some setting flags for stuff like restore actions?
Maybe the Problem occurs after 2 or more Toolchanges?
In the Screenshot you can see, that the spindle is at X 50 Y0. Thats were the previous steps ends, but nowhere in the Programm is a value of Z-35mm and it was still with "G0-Speed" driving down
The strange thing is that it was still in Line 63 and the "Toolchange was "pending" but it was driving to his "old position" and a little bit deeper...
@einencool I have been thinking a bit, maybe its will be a good idea to add some setting flags for stuff like restore actions?
What do you mean with this?
Here is another file, which I wanted to test today, but I don't know if the names for the Endmills are a problem for the Sender. Since the probing didn't work as expected for me, I didn't test it with these, because this is the Test for around 6 Toolchanges in one Code File...
Maybe the Problem occurs after 2 or more Toolchanges?
I do not think so, I have run the same program over and over with no issues. Will check more.
Thats were the previous steps ends, but nowhere in the Programm is a value of Z-35mm and it was still with "G0-Speed" driving down
I see now, this is not correct. I have to try to replicate this somehow as it did not happen for me. Maybe add some debugging messages could help. Somehow the target position for the final Z is wrong, this is recalculated to take the new TLO into account.
What do you mean with this?
E.g flags for not restore the spindle, coolant and move back to the original position. Then this has to be done in the program. E.g. your program switch on the spindle and wait for it to spin up. As it is now it is a part of the sequence, with flags this can be made optional.
I will test with the program you just posted, thanks for that.
I'm glad that you try so many things to get this running :-) I absolutely can't help with these things.
The Spindle and coolant restore is not the Problem, this is in the PostProcessor and normally I don't have to change things there, for this test I delete all M3 commands, but in the future, I hope it will work so :-)
For the next time I think it would be good, to get a hint, that we have to restart the sender if we missed the homing before Toolchange. This was not clear for me at the beginning.
Your latest program "Fraeser Toolchange Test.nc.txt" completed without issues for me.
Looking at your log in the image above I see that you are probing at positions quite a bit apart. Are all at the same Z-level?
I absolutely can't help with these things.
You do with your testing!
For the next time I think it would be good, to get a hint, that we have to restart the sender if we missed the homing before Toolchange. This was not clear for me at the beginning.
Better documentation is needed for sure, and I'll see if I can add a warning about homing if there are tool changes in the program. Will have to add this in the sender. And homing should be done before any other step, e.g. the reference tool offset will be cleared on homing. Another check to be added...
The homing is normally the first thing I do with the machine, because at the end i let it go to the home position, and so it cost only 15 seconds till it's done ...
This was the "workflow" I was testing:
Mounted my 3D-Finder
Move to the Workpiece Top surface
Load it as "Tool # 1" (But I only click it in the top right corner of the first screen, because when I do it with M61Q1 I even don't get a status update in the console (this would be a great feature...))
Go to Probing / Edge Finder -> Probe Z and click the middle of the workpiece in the picture
For all Probings I have 39.14mm for the Touch Plate thickness (because I can't change Profiles between 3D-Finder and Tool Length Sensor (TLS))
Start Probe Z
Move the 3D-Finder above the Baseplate of the machine
Go to Tool lentgh offset tab
Then I set the reference offset in the tool length offset tab. (with clickbox enabled)
After that I remove the 3D-Finder because the setting for the Endmill Offset is done
Then I start the GCode, because the first thing is the Toolchange to maybe Tool # 1000
Axis moves up, I change the Tool and jog to the TLS which is standing but movable on my baseplate
Jog a few mm above the Touch-Surface and then I start the "$TPW" Command
After that, the Sender told me to start the Program by pressing Start, so I pressed the "Hardware Button" on my machine, the Z-Axis goes up, drives some crazy lines (when I remember right it drives up (Z=130), goes to the last position (X50 Y0) Then X & Y to another Position / Then X50 Y0 / Then drives Z=2 / then Z=130 / Then Z=2 and then to X0 Y0 ) (it was very curious)
And the first time when everything works as expected, the Z=0 Position was directly on the Workpiece surface
I thought this should work in this direction, and the first Tool seems to work fine...
If I understand correctly you are setting the reference tool offset by probing the base plate (or table surface) with your 3D-finder and then later the actual tool offsets by probing with the tool on the touch plate which is 39.14mm above the base plate?
If so that cannot work - the reference offset probe and all subsequent tool probes must be at the same Z position. If not the calculated tool offset will be wrong. What may work is to set the tool reference offset by probing with the 3D finder on the touch plate.
Nope ;-) Thats why i have the thickness Of 39.14mm for the „touchplate thickness“
When i probe the workpiece with the 3D Finder, the axis will go 3mm up and then the „actual Z value“ is 42.14mm. And when i Probe the Baseplate as reference it will also measure the 39.14mm. When the z axis drives up, i have a value around 3mm from the DRO.
The first toolchange to Tool 1000 works perfect. The endmill had no gap to the workpiece.
After the second toolchange, the spindle was 35mm under the surface (Z = -35mm) and this was true... the wood was around 37mm thick that was my testpiece, that i didn’t mount to the base, so i had it out of my way, because when it has been mounted, my machine would now have a big problem...
I have run a large number of tests now without beeing able to replicate exactly the same behaviour that you have.
A few problems have surfaced though:
grbl is bad at handling errors. IMO a program should stop running when an error is reported. Legacy grbl assumes the sender does not use agressive buffering (filling the input buffer with gcode commands) and stops sending when an error is reported. When agressive buffering is in use legacy grbl will continue executing gcode from the buffer. grblHAL will report the same error until a blank line or a $command is issued by the sender and skip the commands. A new problem surfacing with your test code is that it contains a large number of comments, and these will be treated as blank lines. Your first test did not stop on error as IMO it should due to this - comments were in the input buffer and these reset the error status allowing subseqent gcode to be executed. I'll have to fix this.
An oversight by me will result in the Clear button not beeing shown in the Tool length offset tab even if a tool offset is active. I will fix this is the next sender release. Until then two workarounds are possible: the first is to enable Parser state in the $10-setting (Status report options), the second is to first set the reference tool offset and then probe Z with the Edge finder. The second wil work since establishing the reference offset will automatically clear any current tool offset. It is important that no tool offset is active when probing Z with the Edge finder. I'll put a warning in the Edge finder tab if it is.
Can you enable Parser state in the $10-setting and run a few tests ensuring any tool offset is cleared before Z is probed with the Edge finder? I am interested in a console log from a failed test and also the Z value displayed in the DRO after the $TPW
command is completed, but before cycle start is pressed. Note that when Parser state is enabled the current state will be shown "live" in the Grbl tab, it will contain G49
when the tool offset is cleared.
Regardless of the $344 setting the feedrate will be limited to the $112 setting (Z-axis maximum rate). Could that explain it?
Sorry I had overlooked that question. No my maximum z feed rate is set to 3500mm/min and I would say the feed rate to the fixed touch plate @G59.3 is estimated to be a maximum of 300mm/min.
Something else I noticed, my controller is behaving a bit strange since the last updates. So I tried to play around with my settings to find out what could be the reason for this, I noticed that the $41 parking cycle can't be deactivated, once switched on you can't set $41=0 anymore. After reload there is always a 1 behind it. It also has no influence if I activate the #define ENABLE_SAFETY_DOOR_INPUT_PIN or not. Also it does not matter if I activate 3 or 4 axes. Controller is a STM32F1xx.
@ Einencool, is something of topic, may I ask which postprocessor you use in Vectric Aspire or is it self-written? Would it be possible to get the postprocessor?
Sadly I don‘t have the ability to work on the machine in the next days.
But one point I also figured out, while Probing the Z-heigth, it makes between the first and second measurement a little move up (0,5mm or what you type into the box) This Move seems to be done in „G0-Speed“ and not the speed set as the „Rapid-Speed“
Because I set it to 200mm/min for testing and the machine shakes with this little move with G0-Speed. Maybe you know what I mean...
@S2000Stefan I‘ll start my Laptop and upload the PP. It‘s the GRBL PP but modified, so that I can better see which Endmills are used :-) I‘ll upload the Version with G0 and G1 speeds The Version with only G1 speeds is better to change the speed with an encoder, but it has many empty lines only with Speed changes, and I don‘t know, how to fix this :-(
I have implemented three new tool change options and would like some input on what I have done and if it makes sense.
See the Wiki page for details.
I have not yet published the build needed - will do so soon to the test branch.