-
I'm using a Duet Wifi to control a CNC router / mill that has a tool probe sensor which you can place on the work surface and probe the tool against. To do so I use the following macro
G10 Z0 ;Reset current tool
G1 Z20 F2000 ;Go to 20mm above (without any tool compensation)
M585 Z-5.3 F100 E4 L0 S1 ;Probe in Z-direction with Feedrate 100 versus endstop 4 active high, Z-5.3 = -20 + 14.7 (theoretical distance to zero compensated by the tool probe height)
G1 Z20 F12000 ;Move to the real Z20 with the now active tool compensationThis macro works fine for me. However there are some drawbacks to it:
You need to position the tool first in a defined distance away from the bottom of the probe (G1 Z20 F2000, assuming the probe is position on Z=0 as for CNC milling application it is often the case with mobile probes). Now depending on the effective tool length (which is not precisely known yet when this command is issued) this could potentially lead to a collision for tools longer then the zero length tool.
On most CNC machines with mobile tool probes you just position the tool manually close to the tool probe (not going to an explicit defined position) and then execute the probing command. I could not figure out how this could be done with the current implementation of M585. I think an implementation of M585 in the formM585 Z14.7 F100 E4 L0 S1
where Z would define the Z-value the tool is expected to have when it triggers the probe could make sense (in my case this would be Z14.7 which corresponds to the height of my tool probe) and rendering the step to go to predefined distance from the tool probe fist obsolete.
Further when probing completly automated with a fixed tool probe on most CNCs typically one has to enter an estimate of the tool length within a few mm first to avoid collision. However in my understanding this would not work either with the current M585 as it is not taken a previous tool compensation into account i.e. it is just overrideing the current tool-length with the new measured value instead of compensating with the one already set. This behavior in my opinion is just faulty for the current implementation as well as for a potential new implementation as described. -
The way I configured my probe for CNC milling:
- It is installed on the Z-endstop connector.
- Using command
M558 P7 I1 F200I configure it to be Normally Open, and use the Z-endstop and probe at 200mm/min. - Using command
G31 Z19.25I define the probe to be of Thickness 19.25mm. - My Z axis is also set to use Motor Load detection for a Max end-stop
M574 Z2 S3 - Due to the M558 and G31 commands, I can probe at the current XY location, using
G30which is inside my bed.g file (under sys folder), and this G30 can also be used anywhere or at any time I need to probe.
This allows me to Home upwards at any time, to get the tool out of the way of any stock in the machine.
In my custom Post Processor (HSM or Fusion 360 compatible), linked to in a thread around here (will get update soon), I have made a small wizard-style interface where the following happens:
- M5 is sent - this should stop the spindle.
- Z axis is moved to the safe location (can now be defined), or Homed (if the printer Homes upwards, like mine).
- The next tool is requested (using tool number from the tool library as well as descriptions). This interface have an OK and Cancel (OK continues, Cancel will stop the current job). Press the OK when the tool is changed.
- Now the interface will ask you to prepare your probe - my probe requires me to place the block below the spindle, and clip a crocodile clip to the tool, so this should be done before pressing the OK.
- The machine now performs the probe (G30) and brings up the next interface asking you to remove the probe (all of this while the spindle should be off). OK to continue.
- At this point your probe's thickness will be implemented using the command
G10 L20 P1 Z(where Z contains the probe thickness + 5mm). - Next the interface will either set the spindle speed, or ask you to manually set it (my machine requires a manual set). At this point the spindle should be on. OK to continue.
- Finally the wizard is complete and it can continue.
Using this, I have machined a few multi-tool jobs and it simply works.
-
Hello Jacotheron,
I just commented in your other thread before reading this...
I think you developed a valid work-around here. However as written in my other post I would prefer to work with real tool-offsets as like this I don't have to probe the tools before every operation (this is how I'm used to work on big CNC's with Heidenhain etc. I grew up with). And therefore I think having this modifications to M585 would be quite useful.
Best regards,
Marc
-
I simply figured my own way out as I had no experience in CNC until a few days ago - there may be better ways, but I haven't figured them out yet. I will look at your recommendations - being more like other CNC machines will make it easier if and when I get more.
For my tools, everything is manually installed as needed, so being able to probe for each one is perfect for me.
I still have to research this M585 command more.
-
The reason M585 behaves this way is because it was primarily designed for probing tool offsets in X+Y directions and if you know the approximate length of your tool in Z, there is usually no problem with starting from a predefined position.
However I agree it would make sense to be able to specify the expected endstop location because I did not consider the case of users trying to manually position the tool before starting the probe cycle. I will enhance M585 for this soon.
-
@chrishamm I agree that the current implementation could make sense for an automated tool probing with a tool fixed toolprobe. However this is not working as well for me as outlined in my first post...
@mwinterm said in Issues with M585 for CNC milling:
Further when probing completely automated with a fixed tool probe on most CNCs typically one has to enter an estimate of the tool length within a few mm first to avoid collision. However in my understanding this would not work either with the current M585 as it is not taken a previous tool compensation into account i.e. it is just overrideing the current tool-length with the new measured value instead of compensating with the one already set. This behavior in my opinion is just faulty for the current implementation as well as for a potential new implementation as described.
So for me to make sense this would look something like (assuming my tool is 22mm and my assumption of tool length is 20mm and my probe height is
G10 Z20 ; Set the estimate for the tool length
G1 Z20 F2000 ;Go to 20mm above (which would effectifely be 18mm as my tool is 2mm longer than estimated)
M585 Z-5.3 F100 E4 L0 S1 ;Probe in Z-direction with Feedrate 100 versus endstop 4 active high, Z-5.3 = -20 + 14.7 (theoretical distance to zero compensated by the tool probe height)
G1 Z20 F12000 ;Move to the real Z20 with the now active tool compensationSo the resulting tool compensation should be 22mm. However with the current implementation the result would be 2mm.
-
Hello,
Along my earlier proposals in this thread I created a modified firmware. To achieve I only had to change two lines of code in GCodes.cpp in the function
void GCodes::RunStateMachine
specifically
case GCodeState::probingToolOffset:original:
currentTool->SetOffset(axis, (toolChangeRestorePoint.moveCoords[axis] - currentUserPosition[axis]) + gb.GetFValue(), true);This implementation has as described two issues:
- An already existing tool-offset is not considered which leads to an unpredictable behavior without explicitly zeroing the old tool-offset before probing.
This could be addressed by my Version 1:
float OldOffset = currentTool->GetOffset(axis);
currentTool->SetOffset(axis, OldOffset + (toolChangeRestorePoint.moveCoords[axis] - currentUserPosition[axis]) + gb.GetFValue(), true);- Having to move to the predefined tool change position is not convenient and as well for manual probing and depending on the tool-length not always safe (to make it safe you have to first enter a reasonable estimate for the tool-length which however so far did not work correctly without the modification in Version 1).
Therefore I would propose Version 2:
float OldOffset = currentTool->GetOffset(axis);
currentTool->SetOffset(axis, gb.GetFValue() - currentUserPosition[axis] + OldOffset, true);This Version 2 is not requiring to go to a specific tool-change position before probing. So you can just just position your tool manually close to the probe and then press probe. However you still can preset an estimate of your tool length and go to the tool-change position prior to probing. It basically leaves you both options. Different from the other versions the Z parameter in the M585 call describes the height the tool is expected to trigger.
@chrishamm please let me know what your thoughts are. For me this currently works perfectly in both scenarios. If it makes to you I would be happy if it could make it into the regular code base.
Best regards,
Marc
-
-
@mwinterm said in Issues with M585 for CNC milling:
@dc42 Do you have any thoughts about this?
Regards,
Marc
Chrishamm wrote the M585 support and understand its purpose better than I do, so I'll wait for him to propose enhancements to it.
-
@mwinterm I don't see any problems with your version 2 but I'd like to keep the current behaviour of M585 because it is already used in production. What about introducing an S2 mode for this type of probing?
-
@chrishamm: First sorry for the late feedback your response somehow escaped me.
I would be happy to have version 2 under something like S2 and agree that the current behavior should be maintained.
But I would also implement Version 1 in parallel as I think it is completely consistent with the current behavior. It is just extending the current behavior to work as well with initial tool-offsets different from 0.
Finally if you like I can make a pull-request from my repository. However as it is so little code I'm not sure if it is not easier for you to directly include the few lines needed. Whatever you prefer just let me know....
