Tool change (M6) support discussion

[terjeio]

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.

[terjeio]

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.

What rate is displayed in the sender? I have $112=500 and $344=400 and it reaches 400 as it should. Not that I want this high speed as probing with higher speeds will result in more overshoot as it has to decelerate to a stop after triggering the touch plate. Do you have a touch plate that allows a lot of overshoot?

I noticed that the $41 parking cycle can't be deactivated

This is a bug, will be fixed in the next commit.

The #define for enabling this is DEFAULT_PARKING_ENABLE not ENABLE_SAFETY_DOOR_INPUT_PIN. Note that after changing settings in config.h and reflashing you have to reset the settings with $RST=* (for all) or $RST=$ (for just the $<n>-settings).

[terjeio]

This Move seems to be done in „G0-Speed“ and not the speed set as the „Rapid-Speed“

It is, will be fixed in the next release. Missed that when I rewrote for the new rapids feed rate.

BTW do any of you use the Vectric direct output to machine option?

[einencool]

@S2000Stefan Please see attached the desired PostP :-) I hope you can work with them, If you have any updates, it would be great if you share them, maybe I have some Problems in them :-)

In Lines 159 - 161 I have commented the G1 Speeds for Rapid speeds. If you want to test them, just uncomment them. I set the Z-Axis in another Line, because I didn't want the first move at the beginning of the Program to be from Z20 in a XYZ Move to Z=2mm if there are some fixtures in the way...

_CS Aspire GRBLHal ATC.pp.txt _CS Aspire GRBLHal.pp.txt

[einencool]

BTW do any of you use the Vectric direct output to machine option?

I don't use it :EDIT: I don't use it, because I normally don't make the drawings on the Sender PC (with Fusion or Vectric)

[S2000Stefan]

What rate is displayed in the sender? I have $112=500 and $344=400 and it reaches 400 as it should. Not that I want this high speed as probing with higher speeds will result in more overshoot as it has to decelerate to a stop after triggering the touch plate. Do you have a touch plate that allows a lot of overshoot?

I Have $112=3500 and $344=300 and on a trial basis $344=3000. I believe there is a problem of understanding on my part, having assumed that $344 is a trial for travel speed. This is probably not the case. I just noticed that the way to the fixed touch plate @G59.3 is very slow and I could adjust the speed with it.

Note that after changing settings in config.h and reflashing you have to reset the settings with $RST=* (for all) or $RST=$ (for just the $-settings).

O.k. I will try this one.

BTW do any of you use the Vectric direct output to machine option?

No I do not use.

@einencool Thanks for the postprocessors, I will have a look at them and if I can improve anything I will contact you again ;-)

[S2000Stefan]

Tool change mode $341=1 Manual touch off For example, I have just successfully carried out the tool change on my machine. The reset with $RST=* had probably been successful. :+1:

My procedure:

• Machine is homed at startup
• Clamping the first tool
• Fasten workpiece on clamping table
• zero point of the workpieceDetermine X and Y axis
• determine reference point for all tools, either on the workpiece itself or on any other point of the clamping plate and open the probing tab, select tool length offset, set a hook at establish reference offset and press start for Probing
• after successful reference probing, set z zero on the workpiece itself. Open the tab edge finder and run probing Z on the Workpiece
• then start the milling program, the first tool change is skipped and the second tool change moves the z spindle to z home max and the spindle stops
• Cutter change
• Then jog to the previously set reference point again and perform a probing run with $TPW in the MDI window
• Remove all touch plates or other and press start
• Z-spindle moves to z home max, then back to the last position and starts the spindle again
• The milling job is continued...

Tool change mode $341=2 Manual touch off @G59.3, also works according to the same scheme. :+1: The feedrate for position @G59.3 is now also G0, don't know what went wrong before. The only thing i noticed was that once while jogging two axes, x and z, were running at the same time, but i could not repeat the mistake. Now I can go troubleshooting.
;-)

[einencool]

So that means, you have done a "Reset" for the machine And you have switched the Z-Probe order from :

• Z-Probe on Workpiece then Reference Probing to
• Reference Probing and then Z-Probe on Workpiece.

That's all what was changed? I hope in the next days I'm able to test this also on my machine.

@terjeio The Reset for the machine, which option must be unchecked, that this will be done every time I flash a new Version from your HAL?

[terjeio]

The only thing i noticed was that once while jogging two axes, x and z, were running at the same time, but i could not repeat the mistake.

It is possible to jog several axes at the same time with the keyboard. Or did you use the Jog flyout for jogging? If jogging with the numeric keypad it could be that two keys were pressed at the same time, this since they can be quite close. But then not all keyboards support rollover for all combinations...

The Reset for the machine, which option must be unchecked, that this will be done every time I flash a new Version from your HAL?

You do not have to do this, @S2000Stefan had parking enabled and discovered a bug when he tried to disable it. To work around this bug he had to perform a settings reset.

[einencool]

The Reset for the machine, which option must be unchecked, that this will be done every time I flash a new Version from your HAL?

You do not have to do this, @S2000Stefan had parking enabled and discovered a bug when he tried to disable it. To work around this bug he had to perform a settings reset.

Ah ok, I thought that could be areason why my machine was doing so much strange things with the Tool changing ... I'll try it anyway when I'm next to the machine..

[S2000Stefan]

And you have switched the Z-Probe order from :

Z-Probe on Workpiece then Reference Probing to Reference Probing and then Z-Probe on Workpiece.

Yes I have changed that as it was suggested by terjeio above. But I don't think that was the reason for the problems I had.

It is possible to jog several axes at the same time with the keyboard. Or did you use the Jog flyout for jogging? If jogging with the numeric keypad it could be that two keys were pressed at the same time, this since they can be quite close. But then not all keyboards support rollover for all combinations...

I use a Wifi numeric keypad for jogging. But I am very sure that I did not press two keys at once, which the numeric keypad supports. I will keep watching this.

Note, would it not be possible to generate a button for the $TPW system command or does it already exist? Would be much more comfortable.

[terjeio]

Note, would it not be possible to generate a button for the $TPW system command or does it already exist?

Create one yourself by adding it as a macro. Macros will be assigned to a function key automatically and will get a button in the top toolbar as well. From one of my test senders:

[einencool]

That's a good point, As i can see in your picture, the probe workpiece button, is this assigned to the data in the Probing Tab, or is it just the „normal“ one that doesn’t fit with it? I also have a z-probe macro for my TLS, but i think i can’t use it when using the toolchange function, or is it possible?

[terjeio]

As i can see in your picture, the probe workpiece button, is this assigned to the data in the Probing Tab, or is it just the „normal“ one that doesn’t fit with it?

It is for my $TPW macro:

I also have a z-probe macro for my TLS, but i think i can’t use it when using the toolchange function, or is it possible?

If by this you mean while the tool change sequence is executing I believe you cannot. No regular gcode is allowed when this is active, only jogging. If a program is not running you can of course use it.

[S2000Stefan]

Starting position Tool change mode $341=2 Manual touch off @G59.3

The only thing i noticed was that once while jogging two axes, x and z, were running at the same time, but i could not repeat the mistake.

I could reproduce the error today:

• Machine homing on startup
• G54 G0 X0 Y0 drive to, select tool one
• G0 G59.3 X0 Y0, then select G54 again
• jogging to touch plate
• TLO Tab, Establish reference offset
• G0 X0 Y0, then touch the work piece with a macro z Zero
• load and start programme
• tool change is pending
• machine moves to G59.3 for tool change
• when i jog down the z axes all three axes are moving at once? I don't know if all steps have to be executed exactly the same way or if steps can be left out to reproduce the error?

Second thing I noticed today :

• Machine homing on startup
• Select no tool (none)
• TLO Tab, Establish reference offset
• after that only stop can be selected in the TLO Tab, is that what you want?

Unfortunately I can only test very little in the evening.

[terjeio]

I could reproduce the error today

Is this repeatable? Same with a cabled keyboard?

after that only stop can be selected in the TLO Tab, is that what you want?

Not sure what you mean by this, is only the Stop button active when you want set the reference offset? Or is this after the reference is set? Is there a message in the status line when this happens?

[S2000Stefan]

Is this repeatable? Same with a cabled keyboard?

Yes was repeatable, I will try again tomorrow evening with a cabled keyboard. What i can say is that if you press the z jogging button and all three axes are moved by releasing it and pressing it again a normal jogging was possible.

Not sure what you mean by this, is only the Stop button active when you want set the reference offset? Or is this after the reference is set? Is there a message in the status line when this happens?

Only after the reference value has been set. No message, I'm not sure anymore after pressing the stop button probing failed, but I will test again tomorrow evening.

[S2000Stefan]

Is this repeatable? Same with a cabled keyboard?

O.k. today tests were made with the cabled keyboard and the error occurred again. I made a small dirty video of it once. Please do not comment on the dirty machine. ;-)
And I really only moved the Z-axis at the end which I forgot to document with the video. https://www.youtube.com/watch?v=1uPWUl1pe_4 I uploaded the video just a few moments ago so it may take some time until a better version is available. Here is the macro I used to zero the workpiece:

Second thing I noticed today : Machine homing on startup Select no tool (none) TLO Tab, Establish reference offset after that only stop can be selected in the TLO Tab, is that what you want?

Surprisingly, I was unable to reproduce the second mistake today. Don't know what's going on there either?????

[terjeio]

So the issue happened after the movie is finished? With $341=2, after a tool change move to G59.3 then jogging z fails?

Surprisingly, I was unable to reproduce the second mistake today. Don't know what's going on there either?????

Gremlins? Things are getting complicated so a lot of testing is needed to make sure all corner cases are catched, but not easy to trace when the issue cannot be replicated.

[S2000Stefan]

So the issue happened after the movie is finished? With $341=2, after a tool change move to G59.3 then jogging z fails?

No, actually it is good to see, the milling machine approaches the G59.3 point to "change the milling cutter". After that i jog the z-axis in direction to the touchpad with z- down and there all three axes are moving although i only pressed z-down. Show two rotating ball screws and the moving portal. After that I release z-down and press z-down again. After that only the z spindle is turning which would be right.

Gremlins? Things are getting complicated so a lot of testing is needed to make sure all corner cases are catched, but not easy to trace when the issue cannot be replicated.

Yes, it's a pity that I couldn't reproduce the bug but I will find the gremlins ;)

[terjeio]

I believe I found the jogging bug, fix just committed. In my test machine the movement was so small I missed it during testing.

[S2000Stefan]

Thanks for the very fast bugfix. Will test it later today. 👍

[S2000Stefan]

Good news, the jogging error has disappeared. :+1:

Unfortunately i have to report that i did some test runs of the tool change afterwards, milling cutter up down, with macro zeroing or in probing tab z zero and so on and so on...

Did I get an alarm 2. The milling program was always the same. The coordinate system was always the same, machine was homed and the program always ran with the same settings. This was shown on the console. Pressing the reset button once did not help, i had to press the button at least 20 times until the programme was free again.

Note: pay attention to the DRO advertisement after the reset has been accepted. The machine has not been and will not be moved.

The Gremlin had struck again. :) As described above. But I think that the Establish reference offset probing was correct. Again, only stop was possible as selection. After pressing stop comes as msg Probing cancelled/failed. And when I jumped to the grbl tab the G-Code transmitter Beta6 is completely crashed. I also have pictures of it if desired. But it was only once today.

[terjeio]

What triggered the alarm? A cycle start or $TPW command? Anything else? Alarm 2 is only issued after a cold start or warm reset - just before entering the main processing loop. So something must have triggered a reset.

I have made some changes to the sender but need to test a bit more before committing an update. One annoyance for me is that the Stop button in the Grbl tab is not enabled when in TOOL mode. TLO probing tab is going to change a bit:

If you are willing to test during development I can make a zip-file available from my server, this as I am not too keen to commit and upload new releases to github just yet.

[S2000Stefan]

What triggered the alarm? A cycle start or $TPW command? Anything else? Alarm 2 is only issued after a cold start or warm reset - just before entering the main processing loop. So something must have triggered a reset.

It must have been a cycle start, because the spindle has started. Unfortunately I'm not sure anymore because I had done a lot of tests. Sorry, I will take a closer look next time.

If you are willing to test during development I can make a zip-file available from my server, this as I am not too keen to commit and upload new releases to github just yet.

Sure, would be happy to help you to development to perform some tests.

Something else, you recover the spindle and the cooling directly above the G59.3 position, in tool change mode 2, which I don't like because the spindle and the cooling usually go a long way across the table. Wouldn't it be better or possible to start the spindle and cooling above the workpiece, say at the position where the spindle moves to z-max, usually at X0 Y0 and z-max?

[terjeio]

Bleeding edge version can be downloaded from here.

Some other changes than Tool length offset tab:

Stop button in the Grbl tab will now be enabled during the tool change sequence, this to allow a softer cancelling of a job than Reset provides.

Work Parameters box has been changed again, green background colour for the Tool dropdown is replaced by a "LED" to indicate TLO reference is set and a "LED" to indicate tool length offset active is added:

The TLO "LED" will not be visible unless $10 setting for Parser state is checked. Both require grblHAL on the controller?

The Center finder is enhanced, the diameter field has been replaced with X and Y size - this allows probing of oval/rectangular workpieces. Requested by @einencool.

---

Note: builds uploaded will only be lighly tested by me so be careful! Please report back both failures and successes.

[einencool]

The Center finder is enhanced, the diameter field has been replaced with X and Y size - this allows probing of oval/rectangular workpieces. Requested by @einencool.

Note: builds uploaded will only be lighly tested by me so be careful! Please report back both failures and successes.

Hello @terjeio It was a little other thing I requested ;-) I asked if it would be possible to get the measured dimensions displayed. So it would be possible to see the accurate dimensions of the Workpiece.

For example, I have a calibrated Ring from our company with exact known diameter (maybe 49,9996mm) And my 3D-Finder has a 2mm ball, but it moves while measurement, and I would like to know, which value I have to enter into the Probe Diameter field. So then it would be possible to adjust this. In some other Sender Programs it is possible to add a macro for automatic calibration, but I think this is overkill and it would be much more helpful to see the measured dimensions of the workpiece :-)

But nevertheless, your feature seems also to be very interesting ;-)

[terjeio]

I asked if it would be possible to get the measured dimensions displayed. So it would be possible to see the accurate dimensions of the Workpiece.

Sorry about that, I'll add dimensions to the status line. Note that several passes may be required to get the measurement from the exact center. I have coded the center finder with the option of entering number of passes in a field to do it automatically, but have not added that to the UI - don't know if it is needed.

[S2000Stefan]

I can report a partial success. After a restart and following the procedure described above, my tool change programme is running smoothly. I like the LED indicators in the GRBL window very much and find them very helpful. :+1:

Unfortunately, after deleting the TLO offset and running through the procedure and my test programme again, two errors occurred. Firstly, after the $TPW command the tool returned to its initial position, everything was ok until then, it delivered, then went straight up to z-max and then in rapid motion back down under the workpiece and wanted to go further under the table.
Break off my side.

The second time again everything o.k. until the $TPW command, after that the program wanted to do a second probing with very slow speed which I also aborted.

I also pressed Feed Hold once in a tool change cycle which caused the program to crash. Because the GRBLHal controller probably hung up, it was like resetting my STM32F103 controller. After that the controller was no longer accessible, only after a restart.

Unfortunately it was only a short test, but I will test a bit more intensive tomorrow.

[einencool]

I asked if it would be possible to get the measured dimensions displayed. So it would be possible to see the accurate dimensions of the Workpiece.

Sorry about that, I'll add dimensions to the status line. Note that several passes may be required to get the measurement from the exact center. I have coded the center finder with the option of entering number of passes in a field to do it automatically, but have not added that to the UI - don't know if it is needed.

When it is not much work for you, I think we can test it :-) When you could code it, that there will be normally only one Pass activated and if the user wants more passes, than he could adjust it. But only when it‘s not much work. Thank you :-)

Unfortunately, after deleting the TLO offset and running through the procedure and my test programme again, two errors occurred. Firstly, after the $TPW command the tool returned to its initial position, everything was ok until then, it delivered, then went straight up to z-max and then in rapid motion back down under the workpiece and wanted to go further under the table. Break off my side.

That sounds exactly like what happens to me the last weekend.

I think for testing I will reduce the Z-max Value for Rapid speeds to around 500mm/min just to have the abbility to have enough time to react :-)

[terjeio]

I'll add dimensions to the status line.

I probe with a milling bit and nothing locked down so precision is lousy...

I also pressed Feed Hold once in a tool change cycle which caused the program to crash.

Was the Feed Hold button enabled while the State was TOOL? It should not be. Only after Cycle Start is pressed should it be reenabled.

I migth have found a reason for crazy Z movements, and it may be related the jog issue before. It could be masked in my machine because it is small and I probe over relatively small distances to save time. I have modified the controller code a bit for this, I will run some tests and commit an update later (I think tomorrow).

[einencool]

Thank you for your great work 🥇 That‘s excellent :-)

And for the Z-moves, I hope that was the point. I hope I can do some small test runs tomorrow.

[S2000Stefan]

Was the Feed Hold button enabled while the State was TOOL? It should not be. Only after Cycle Start is pressed should it be reenabled.

Yes I pressed the hardware feed hold button after the cycle start when the $TPW command was ready and the spindle was on its way up at G59.3 to z-max and was recovering. I can't tell if the feed hold button was active because I was still in the TLO tab.

[terjeio]

I can't tell if the feed hold button was active because I was still in the TLO tab.

Another detail that I have missed... Ability to switch tabs while in the tool change sequence has to be disabled. Maybe I should filter out anything sent to the controller that is not allowed, only jogging, $TPW and real-time commands are.

[terjeio]

New sender uploaded, with improved interlocks. Still work to do on this in order to make it bomb proof it seems.

I will commit an update to grblHAL later, I have done some of refactoring of unrelated code that needs testing too.

Note that there are at least two issues with tool change that may bite:

• A Stop or Reset during the tool change sequence will leave the new tool active, it should be reset back to the previous. Fix under test.

• With $341=2 a cycle start before probing with $TPW will terminate the tool change, run the restore sequence and continue the program. Will be blocked in the next release (like $341=1 does). Also a message will be issued if a cycle start is issued early prompting for the $TPW command.

[terjeio]

I have finally managed to replicate the odd movements. More than one cycle start command after $TPW will sometimes trigger this consistently, if a noisy physical switch is used then this is more likely. I have added code to block this, will perform final testing tomorrow and commit an update if successful.

[einencool]

Ah ok, so this could be the clue. I have a simple and cheap button in front of my machine which is set as a normally closed switch. I didn’t think about bouncing from the switch. Could we just activate software debounce to solve this issue?

That said, i remember, when i drive onto a limit switch (also a cheap one), the machine raises an alert. So far so good. Bit when i reset the error and slowly drive away from the switch, it often raises a second alert when the switch switches from open to close. I never said anything about it, because i think it’s my fault with this cheap switches...

[terjeio]

New grblHAL version just committed.

With the previous version I was sometimes able to make the machine go amok if an additional cycle start was issued at the wrong time. Sometimes even a soft reset could not bring it of this crazy mode and I suspect this could be the reason for a controller crash/hang as well.

Another issue I found was that if the sender is exited when the controller is in TOOL state it could not initialize itself when started again, this due to it not beeing able to fetch status information from the controller. In the latest edge sender uploaded it now issues a stop command if TOOL state is detected, this to bring it out of the TOOL state. I think this is ok, however a question box could be presented so that the user can decide what is the appropriate action. Is this needed?

Could we just activate software debounce to solve this issue?

It is enabled by default? - I have to check. Anyway - the tool change code has to behave correctly even if the cycle start button is accidentally pressed more than once, so I have modified it for that. This modification should take care of any switch bounce as well.

Bit when i reset the error and slowly drive away from the switch, it often raises a second alert when the switch switches from open to close.

Maybe "slowly" is the clue here. Try a little bit faster to see if that helps.

[einencool]

New grblHAL version just committed.

With the previous version I was sometimes able to make the machine go amok if an additional cycle start was issued at the wrong time. Sometimes even a soft reset could not bring it of this crazy mode and I suspect this could be the reason for a controller crash/hang as well.

Another issue I found was that if the sender is exited when the controller is in TOOL state it could not initialize itself when started again, this due to it not beeing able to fetch status information from the controller. In the latest edge sender uploaded it now issues a stop command if TOOL state is detected, this to bring it out of the TOOL state. I think this is ok, however a question box could be presented so that the user can decide what is the appropriate action. Is this needed?

Thank you for digging into it :-) Sadly I have in the next week no possibility to check, because I'm on a business trip ...

Could we just activate software debounce to solve this issue?

It is enabled by default? - I have to check. Anyway - the tool change code has to behave correctly even if the cycle start button is accidentally pressed more than once, so I have modified it for that. This modification should take care of any switch bounce as well.

I take a quick search with Notepad++, but I only found src\grbl\hal.h (1 Treffer) Line 47: software_debounce :1,

But I don't know if it will fit this. And I thought on the old GRBL there was an option for this in the config.h, like this said: src\grbl\config.h (2 Treffer) Line 223: // NOTE: This option has no effect if SOFTWARE_DEBOUNCE is enabled.

Bit when i reset the error and slowly drive away from the switch, it often raises a second alert when the switch switches from open to close.

Maybe "slowly" is the clue here. Try a little bit faster to see if that helps.

This could be true, I have to watch it, because it doesn't happen all the time, so I think when I clear the Endstop with higher speed it will be fine...

[S2000Stefan]

I quickly made some tests with the new control software and the new controller software. Tested was: Tool change mode $341=1 Manual touch off Tool change mode $341=2 Manual touch off @G59.3

I could not find any errors in the tool change sequence, neither in mode 1 or in mode 2. :+1: :+1: :+1: But I have not tried any crazy things between the sections. ;)

The Gremlin has also appeared again at the very beginning, but only once and there was no software crash. Everything ran stable after that.

Something else, you recover the spindle and the cooling directly above the G59.3 position, in tool change mode 2, which I don't like because the spindle and the cooling usually go a long way across the table. Wouldn't it be better or possible to start the spindle and cooling above the workpiece, say at the position where the spindle moves to z-max, usually at X0 Y0 and z-max?

Thanks a lot, great work. The ones with coolant lubrication will thank you, now there is not so much sourness on the machine anymore. Super support, thanks again.

[S2000Stefan]

I have just done some tool change tests again and found no errors - everything runs very stable.

After that I did a corner test and a corner test with z-probe. And after that another inner diameter probing. Unfortunately I have to report that after the last start (fourth point) the z-axis was moving with G0 direction table. And could only be stopped in case of emergency. And as it is, I could not adjust the mistake?

[terjeio]

The Gremlin has also appeared again at the very beginning, but only once and there was no software crash.

I have seen this on one occasion now. I would like to know which position the tool is at if this happens again. Is it at the end of the probing sequence where the tool has moved back to the original Z position? Somewhere else?

After that I did a corner test and a corner test with z-probe. And after that another inner diameter probing. Unfortunately I have to report that after the last start (fourth point) the z-axis was moving with G0 direction table. And could only be stopped in case of emergency.

Strange, this must be due to the sender having an incorrect machine position for Z. This may be a bit delayed arriving from the controller on offset changes - but then it should be sent on the next real time report (if position is reported in work coordinates). A delay can be up to ten times the polling rate. The default polling rate is 200ms, so up to 2 seconds if this is not changed. So you have to be really quick to miss the offset beeing received...

At the start of probing a normal status request is requested and waited for, this to check if the probe is already triggered etc. grblHAL has a new status request command, report all. I have changed the code to use this if the sender detects if grblHAL is in use. I have also added a report all status request on tab changes in the probing screen. Hopefully this would ensure that this never happens again - otherwise we have another nasty gremlin to deal with.

The difference between a normal status request and the report all request is that the former may delay some report elements or even skip them if there is no change, the latter will always get all elements.

The edge version has been updated with these changes as well as a fix for saving new profiles.

[S2000Stefan]

Today the new edge version tested. I have played through some tool change sequences and could not find any problems. :+1: Further tests still have to follow. The new profiles can also be created again and saved in the probing tab.

I noticed a really small beauty flaw. There is one "from" too many? ;)

I also noticed that if I execute length offset in the Probing Tab Tool and then want to execute a macro from the tab, this is not possible. You have to select another tab first to be able to run a macro.

Also the probing speeds are somehow different although the values in the settings and the probing tab are identical. I made two very short videos to show this. The first shows an Establish reference offset probing and the second a $TPW probing. https://www.youtube.com/watch?v=oqH-kdlJ37I https://www.youtube.com/watch?v=ixYE5XQq1pE But it is somehow sought in the crumbs. ;-) Is that what they say?

[S2000Stefan]

After that I did a corner test and a corner test with z-probe. And after that another inner diameter probing. Unfortunately I have to report that after the last start (fourth point) the z-axis was moving with G0 direction table. And could only be stopped in case of emergency.

Strange, this must be due to the sender having an incorrect machine position for Z. This may be a bit delayed arriving from the controller on offset changes - but then it should be sent on the next real time report (if position is reported in work coordinates). A delay can be up to ten times the polling rate. The default polling rate is 200ms, so up to 2 seconds if this is not changed. So you have to be really quick to miss the offset beeing received...

I had forgotten all about it. I once made my thoughts about the complete mistake. Is it possible, because I always do my probing tests with loose parts, i.e. a piece of pipe which I simply place on my touch plate and feel it move slightly, that there might have been a very quick double touch during probing, which caused the error? I mean the crazy z movement.

[terjeio]

I noticed a really small beauty flaw. There is one "from" too many? ;)

Oops, I'll fix this.

Also the probing speeds are somehow different although the values in the settings and the probing tab are identical.

There is one value "missing" in the settings - Rapids feed rate, I will have to add that to make them behave in the same way.

Is it possible, because I always do my probing tests with loose parts, i.e. a piece of pipe which I simply place on my touch plate and feel it move slightly, that there might have been a very quick double touch during probing, which caused the error?

Who knows? It is very hard to find out what caused this issue if it is not easy to replicate. Anyway, I have made a change in the real time report parser, this to get rid of a doubled property change event when both the work positions and the offsets are changed in the same report. If this causes the problem then the WPF framework is acting up, which is unlikely. But better coding from my side to only fire one event...

[S2000Stefan]

Today I programmed a test milling program with three tool changes and tried it out in different constellations and settings, no errors occurred, everything was ok. Then i assigned different tool numbers 1, 4 and 23. The milling program ran smoothly until tool 23 was ready. In the tool window there was an empty window, so tool 23 was not displayed. After the $TPW probing the program ran through correctly until the end. Only the tool window was empty. Do i have to tell grblhal before how many tools i want to use?

After that I wanted to do more tests and there he was again the Gremlin. :-) At the Establish reference offset probing only stop was selectable. So the Establish reference offset probing runs correctly and completely. The z-axis was then at Z1.896mm. The z-axis was also at the set height of 4mm above the sample. After pressing stop and re-pressing the Establish reference offset probing, everything went through correctly. Z-axis was then at Z1.886mm. Then I noticed that I forgot to set to tool 1, so it was still tool 23 selected, empty tool window as described above. After activating tool 1 and re-establishing the Establish reference offset Probing the error came right back. There the z-axis was also Z5.288mm, stop and re-establish reference offset probing again, everything was o.k. and the z-axis was at 5.288mm. Milling programme start and the first tool change, tool 2, the G Code transmitter crashed. Spindle above the workpiece, milling spindle recoverd moved to start position (last program point before the milling cutter change) then the spindle should have accelerated to S9000 - that is exactly where the crash occurred. Spindle did not accelerate, so I would say that the G Code Sender crashed when the milling program was transferred. After that the connection to the GrblHal controller was not possible. Had to reset GrblHal to be able to connect.

Hope this helps you a little bit and you understand everything I mean.

[terjeio]

In the tool window there was an empty window, so tool 23 was not displayed.

This is a UI issue, I have changed the code a bit so hopefully working now. It should not affect the behaviour of the program.

Do i have to tell grblhal before how many tools i want to use?

No. And I have recently removed the limit of max 255 tools.

After that I wanted to do more tests and there he was again the Gremlin.

Are you able to replicate this now?

Then I noticed that I forgot to set to tool 1, so it was still tool 23 selected, empty tool window as described above. After activating tool 1 and re-establishing the Establish reference offset Probing the error came right back.

There is no need to reestablish the reference on setting the tool with M61, the reference is not tied to a specific tool. It could be argued that a M61 should clear the reference though, what do you think?

A tip: selecting a tool with the drop-down in the Work parameters box sets the current tool by issuing a M61 command if there is no program running.

the G Code transmitter crashed.

Is there anything in the Windows application event log related to this?

After that the connection to the GrblHal controller was not possible. Had to reset GrblHal to be able to connect.

You could not even connect with a terminal program such as PuTTY? Or could you connect but got no response?

Hope this helps you a little bit and you understand everything I mean.

Your feedback is very much appreciated, thanks for that. However, I have to say I am not fond of seemingly random errors... I hope we soon can get rid of those.

I have added the internal edge finder today, when doing that I decided to rewrite the probing code to issue commands in machine coordinates as much as possible. This triggers a new round of testing for me before I upload any updates, and I believe it should make the code more robust.

[S2000Stefan]

After that I wanted to do more tests and there he was again the Gremlin.

Are you able to replicate this now?

No, unfortunately not, the error only occurred after 10-15 milling programs with three tool changes each. It was just noticeable that it only occurred after I had not selected the first tool. So the tool window was empty.

There is no need to reestablish the reference on setting the tool with M61, the reference is not tied to a specific tool. It could be argued that a M61 should clear the reference though, what do you think? A tip: selecting a tool with the drop-down in the Work parameters box sets the current tool by issuing a M61 command if there is no program running.

So I first have to read myself cleverly to answer their question. Unfortunately I am not familiar with the M61 command. ;)

Is there anything in the Windows application event log related to this?

Where can I find that? I am just a mouse shooter, operator. Let's goggle that. ;)

You could not even connect with a terminal program such as PuTTY? Or could you connect but got no response?

Afterwards I only tried to establish a connection with the G Code Sender.

However, I have to say I am not fond of seemingly random errors... I hope we soon can get rid of those.

These are the stupidest mistakes there are, but the good thing is that there are no sudden movements of the milling machine.

I have added the internal edge finder today, when doing that I decided to rewrite the probing code to issue commands in machine coordinates as much as possible. This triggers a new round of testing for me before I upload any updates, and I believe it should make the code more robust.

Sounds very interesting.

[einencool]

Hello @terjeio One question about the probing tabs. I mentioned it in another thread about the probing of the Z-height Would it make sense from your side of view to change the order of probing for the height of the workpiece to have always the same depth of touching the surface?

When it would probe the height at first, then you could move the Z-Axis always to maybe Z=-3mm to touch the side. Now you jog by hand to a always slightly different height.

I think that would make sense to change it. But I don't know if you have done it this way in the new tab.

Bit nevertheless, thank you for any further optimizing :-)

[terjeio]

New [edge version] of sender (http://www.io-engineering.com/downloads/) uploaded.

• Refactored probing to use machine position moves as much as possible. I hope this has not broken anything.
• Added internal edge finder.
• Added display of current block number executing (technically last ok'ed block) in status line.
• Added option of adding number of passes to run in center finder.
• Added \<Ctrl>+\<Shift> as keyboard shortcut in the MDI to reenable keyboard jogging. This as keyboard jogging is disabled when the MDI has focus and tabbing may move focus elsewhere.

I also noticed that if I execute length offset in the Probing Tab Tool and then want to execute a macro from the tab, this is not possible. You have to select another tab first to be able to run a macro.

It works for me, another Gremlin? Is this replicable, and if so for all macros regardless of content?

Is there anything in the Windows application event log related to this? Where can I find that? I am just a mouse shooter, operator. Let's goggle that. ;)

Control panel > Administrative tools > Event Viewer then Windows Logs, Application (in Win7, if you have a later version it may be hidden somewhere else).

You could not even connect with a terminal program such as PuTTY? Or could you connect but got no response? Afterwards I only tried to establish a connection with the G Code Sender.

Did the sender fail to open the port or was it waiting on the controller?

One question about the probing tabs.

@einencool : I am sorry I am not able to follow your argument. I need a more precise explanation. From where (which tab) and what you want to achieve.

@S2000Stefan : Maybe I have forgotten so I ask again just in case: do you have an EEPROM connected to the controller?

[einencool]

I only meant the order of the moves for probing with "activated Z-Probe"

For example on edge finding: Now it is:

• Jog to Position where the probing should start.
• Axis moves to the side, goes maybe 5mm down from this position and then touches the side of the workpiece.
• then move up and to the other edge
• move down 5mm,
• touch the surface
• move up
• move maybe to position X3 Y3
• Z-Probe the height

I think it should be changed to:

• Jog to Position where probing should start
• first Z-Probe the surface
• then move x mm to the side and drive maybe 5mm under the touched height of the workpiece
• touch the side of the workpiece -... And so on

Hopefully you can understand my explanation :-)