Pretend ATC Idea

Software / Firmware Jackpot Board / FluidNC
41

Jason,
I’ve been studying your commands for this. I saw that you set #<TravelZ> to -20, and when the first G38.2 (probe) is done (after installing tool 1), Z doesn’t move up. Then you have it move G1 G53 Z#<TravelZ> F900 which went down -20 (as it was assigned). I was expecting that and hit the Emergency stop right away, but wanted to validate my understanding of your code.
Should there be a move command to raise the bit up after the G38.2 command so it will clear the workpiece? Since the gcode doesn’t know what that is (yet), I’m guessing a safe rise amount would have to be provided.

This is becoming a very good exercise for me in learning the different G/M codes and coordinate systems that are available. For my workflows, I just set up in G55 (or greater) and once I have my bit moved/jogged to where I want the X=0, Y=0 to be, I then zero out those axis on the FluidNC WebUI. Now I see how G53 works in relation to G55 (and the others).

42

So, I home before running it which should set Z0 as the top in G53. Then when you probe, that should set Z0 in G54 (or whatever coordinates you’re in). So, when I do G1 G53 Z-20, that should move up to Z-20 in G53 (20 from the top). I’m in G90 for that move so it’s absolute. If you were in G91, it would be a relative move and move down 20.

43

ah, got it. That makes sense. Let me play some more. I was just copying and pasting each line in on the terminal. I may have missed a line somewhere (kind of going crossed eyed, maybe :smiley:)

ok. Just re-did it. I didn’t miss any lines. When I home, my Mpos Z (machine position, aka G53 ?) shows 87. If I replace the G1 G53 Z#<TravelZ> with a Z20, it moves up to a Mpos Z of 20. If I used -20, it tries to move the Z axes to a Mpos Z of -20 (deep into my table :blush: ).

I’ll try some more experiments with G90 vs. G91 to see why what you stated isn’t working. I’m learning so much.

44

ok, my config is for a MPCNC so when I home Z it goes up and it is set at 87. I changed that variable so it is now defined as 85.
I ran a simple job (50mm square where it gets pocketed by a 1/4 bit, then it runs around the edge with a ball nose). It seemed to run fine.
I did add the following lines after the move to the workpiece probe location:

M0 (MSG, Place probe on Workpiece to Probe Again)
G4 P2

This way, it gives you a chance and a reminder to move the probe/or place the probe on the workpiece :slightly_smiling_face:

When it came to changing from tool 1 to 2, something didn’t work. It moved to the Tool 1 location and prompted to have the tool removed. Then it moved to the probe location and continued to probe. [when it promoted me to remove tool 1, I just let it down a little bit so there would be a bit length difference.] Not sure why selecting ‘resume’ didn’t execute the lines where it moves to tool 2 location. I’m studying it some more.
I found my error. I was placing sections within the EstlCAM ‘Text’ parts and I missed the variable assignment for which tool is in use, therefore, it was going to Tool 1 location and not advancing. My error. :man_facepalming:

1 Like
45

Ah, yea the Z difference makes sense if you have an MPCNC.

Yea, I can understand that. My intent was that was covered with this line but depending on location, I can see where another pause could be helpful.

M0 (MSG, Keep Probe Attached - Moving to Workpiece to Probe Again)

Note that the dwell (G4 P2) is only needed if you’re switching between hold and run quickly multiple times in a row. It’s just to give the WebUI long enough to see the state change. Otherwise, it gets confused. Well, at least my hold monitor extension gets confused.

Just to add some context for anyone else reading this, since I shared it in a private message, here is my current sample gcode. I actually lost the one I last ran but it should be this except I removed some extra debug messages.

_pretend-atc-test_debug.gcode (4.3 KB)

2 Likes
46

I’m still pondering this and trying to figure out why it is skipping moving to Tool 2 location. It is as if the #<ToolNew> does not get incremented. In the gcode you provided, it is manually set. I’m trying to put this segment in the ‘Tool Change:’ Texts part of EstlCAM (v12.138B):

#<ToolNew> = #<ToolNew> + 1
$HZ
M0 (PRINT, Move to Tool #<ToolCurrent> Location)
G0 G53 X#<ToolCurrentX> Y#<ToolCurrentY>
M0 (PRINT, Remove Tool #<ToolCurrent>)
#<ToolNewX> = [#<Tool1LocationX> + [[#<ToolNew> - 1] * #<ToolSpacingX>]]
#<ToolNewY> = #<ToolLocationY>
G0 G53 X#<ToolNewX> Y#<ToolNewY>
M0 (PRINT, Install Tool #<ToolNew>)
#<ToolCurrent> = #<ToolNew>
#<ToolCurrentX> = #<ToolNewX>
#<ToolCurrentY> = #<ToolNewY>
M0 (MSG, Move to Probe Location)
G0 G53 X#<ProbeLocationX> Y#<ProbeLocationY>
M0 (MSG, Attach Probe)
G38.2 Z-110 F200 P0.5 (probe down set thickness)
#<ProbeZ> = #5063
M0 (PRINT, Probe Z = #<ProbeZ>)
G4 P2
#<ProbeZOffsetNew> = [#<ProbeZOffset> + [#<ProbeZ> - #<ProbeZOriginal>]]
#<NewZZero> = [#<ProbeZOriginal> + #<ProbeZOffsetNew>]
M0 (PRINT, Probe Z Offset New = #<ProbeZOffsetNew> - New Z Zero = #<NewZZero>)
G4 P2
G1 G53 Z#<NewZZero> F900
G10 L20 P0 Z0
G1 G53 Z#<TravelZ> F900
M0 (MSG, Remove Probe, Turn on Router)

Note: I have all the parameter definitions put into the ‘Program Start:’ part of the Texts section within EstlCAM.
I’m not seeing anything that would cause it to skip those lines, but I’m probably missing something as I’m learning about parameters and the scope they work in within FluidNC.

1 Like
47

Are you initializing ToolNew to 0 at the start? If not, that line won’t work.

I would also add some debug to confirm the value.

48

Yes. It gets initialized in the ‘Program Start:’ portion within EstlCAM. So when the .gcode file comes out of EstlCAM, it does show that it is initialized to 0 and then it gets set to 1 before the first tool change and cut.

1 Like
49

I’ll be off grid in the mountains for a few days but I can look at it when I get back.

6 Likes
50

ok, after sleeping on this I figured out where this went wrong. The line:
#<ToolNew> = #<ToolNew> + 1
needs to be:
#<ToolNew> = [#<ToolNew> + 1]
The square brackets [ ] need to be around any arithmetic equation. It now increments the #<ToolNew> parameter from 1 to 2 (and I’d assume to 3 and so on when more than 2 bits are used). I’ll continue to test later today when I get the chance :wink:

3 Likes
51

https://images.app.goo.gl/yQwmkkN7WEW2mgYm6

well shoot, that did not work very well :frowning:

4 Likes
52

Yep. That makes sense.

53

Ok. I worked on this on and off. I’ve got it working well and it seems to keep the depths/z offsets correct. I like it, so Jason, hats off to you for coming up with this. I’ve saved it as a separate EstlCAM post processor so I can switch between PPs depending on the job or what I’d like to use.

For EstlCAM post processor texts, this is what I’m using:
PROGRAM START:

(Project <project>)
(Created by Estlcam version <version> build <build>)
(Machining time about <time> hours)

(Required tools:)
<tools>
#<ProbeLocationX> = 10
#<ProbeLocationY> = 0

#<ToolSpacingX> = 35

#<Tool1LocationX> = 45
#<ToolLocationY> = 0

#<ToolCurrent> = 0
#<ToolNew> = 0
#<ToolCurrentX> = 0
#<ToolCurrentY> = 0
#<ToolNewX> = 0
#<ToolNewY> = 0

#<WorkpieceProbeLocationX> =20
#<WorkpieceProbeLocationY> = 20
#<TravelZ> = 85

G21
G90
G94
G92 X0 Y0

#<ToolNew> = 1
$HZ
#<ToolNewX> = [#<Tool1LocationX> + [[#<ToolNew> - 1] * #<ToolSpacingX>]]
#<ToolNewY> = #<ToolLocationY>
G0 G53 X#<ToolNewX> Y#<ToolNewY>
M0 (PRINT, Install Tool #<ToolNew>  <n>)
G4 P3
#<ToolCurrent> = #<ToolNew>
#<ToolCurrentX> = #<ToolNewX>
#<ToolCurrentY> = #<ToolNewY>
G4 P3
G0 G53 X#<ProbeLocationX> Y#<ProbeLocationY>
M0 (MSG, Attach Probe)
G4 P3
G38.2 Z-110 F200 P0.34  (probe down set thickness)
#<ProbeZOriginal> = #5063
G1 G53 Z#<TravelZ> F900
M0 (MSG, Keep Probe Attached - Moving to Workpiece to Probe Again)
G0 X#<WorkpieceProbeLocationX> Y#<WorkpieceProbeLocationY>
G4 P3
M0 (MSG, Reposition probe to Workpiece)
G4 P3
G38.2 Z-110 F200 P0.34  (probe down set thickness)
#<ProbeZWorkpieceOriginal> = #5063
#<ProbeZOffset> = [#<ProbeZWorkpieceOriginal> - #<ProbeZOriginal>]
G1 G53 Z#<TravelZ> F900
G4 P3
M0 (MSG, Remove Probe,  Attach Dust Cover,  Turn ON dust collection and ROUTER to RPM=<s>)

PROGRAM END:

G90; Restore absolute mode
$HZ
G0 G53 X#<ToolCurrentX> Y#<ToolCurrentY>
#<ToolCurrent> = 0
M0 (MSG, JOB DONE!!!  TURN OFF ROUTER!!!  )
M30

TOOL CHANGE:

#<ToolNew> = [#<ToolNew> + 1]
$HZ
G0 G53 X#<ToolCurrentX> Y#<ToolCurrentY>
M0 (PRINT, TURN OFF ROUTER!!!!  Remove Tool #<ToolCurrent>)
#<ToolNewX> = [#<Tool1LocationX> + [[#<ToolNew> - 1] * #<ToolSpacingX>]]
#<ToolNewY> = #<ToolLocationY>
G0 G53 X#<ToolNewX> Y#<ToolNewY>
G4 P3
M0 (PRINT, Install Tool #<ToolNew>  <n>)
#<ToolCurrent> = #<ToolNew>
#<ToolCurrentX> = #<ToolNewX>
#<ToolCurrentY> = #<ToolNewY>
G0 G53 X#<ProbeLocationX> Y#<ProbeLocationY>
G4 P3
M0 (MSG, Attach Probe)
G38.2 Z-110 F200 P0.34  (probe down set thickness)
#<ProbeZ> = #5063
#<ProbeZOffsetNew> = [#<ProbeZOffset> + [#<ProbeZ> - #<ProbeZOriginal>]]
#<NewZZero> = [#<ProbeZOriginal> + #<ProbeZOffsetNew>]
G1 G53 Z#<NewZZero> F900
G10 L20 P0 Z0
G1 G53 Z#<TravelZ> F900
G4 P3
M0 (MSG, Remove Probe,  Attach Dust Cover,  Turn ON dust collection and ROUTER to RPM=<s>)
2 Likes
54

@jeyeager I’m not sure what’s going on here. This all made sense to me before and the math looked right, but it seems that when my 2nd tool gets put on and the NewZZero is determined, it is off by about the thickness of my ‘probe plate’ (aka large washer). it comes down and thinks the z0 spot is now higher than it really is.

Here is a very heavily edits gcode that I’m using to test (all the ‘cutting’ moves have been taken out).

test_patc.gcode (3.1 KB)

Did I miss something from your original code?

55

Not sure about the specifics of your situation, but in general, for any probing, you don’t want to set Z=0, you want to set Z= (probe thickness).

1 Like
56

Not sure. My touchplate is also only half a mm thick so I might not have noticed if it was off.

57

Bartman - yes, I agree. My terminology may not be 100% correct :wink:

Jason, I did a test with using a thicker probe and I saw the delta was bigger.

So I am just going to subtract the probe thickness from the # variable.

#<NewZZero> = [#<ProbeZOriginal> + [#<ProbeZOffsetNew> - probe_thickness]]

where probe_thickness = the measured thickness of the probe you use (or the value used with the G38.2 statements)

After testing this, it worked for me and it looks like the 2nd tool comes down to the proper spot.

(your comment about the thickness of the probe you use made me think about using a much thicker probe because then it would be very obvious by looking at how far off it was.)

58

Anyone willing to post a video showing this in action? I am interested in seeing how this works in reality.

59

This is a not great video I recorded a couple months ago. I think it gets the idea across.

1 Like
60

Thanks, this is helpful. I am trying to imagine if you can make this slightly easier. What if you have a permanently mounted probe plate in the tool change area that has a plug that mates with a plug on the core connected to your controller input. One wire to the permanent probe plate and one to the magnet. It moves over for tool change you plug it in and place the magnet on the bit and then probe. Now this is the part I am not sure of. Somehow, the thickness of the material is used to calculate the offset and you don’t need to probe on the material. You just unplug and go. I would have to think about this a little bit, but could you set the starting height in the CAM program to the material thickness? Or, is there a way to get the material thickness from the post processer and use the value in your code? Is measuring the material thickness with a micrometer as repeatable as probing on the material, or would this just cause more variability in Z height?

1 Like