I specified material as MDF, the feed rate of 2000, plunge rate 200, and Depth Per Pass as 3. When running the job what I observed was 1mm per pass. What determines the actual Depth Per Path used in the Gcode?
Hi,
i observed that z axis going down in a ramp.
it goes constantly a little bit down and not the hole 3mm per pass at once.
this i recognised in my last project; so i will test with more speed.
M10;L|20|Outline|Bit 6mm|Esterna|6.00|14.85|PROFILO|5a262257-871e-4191-951f-1fbcea19a927
G01 Z0.000 F300 S6000
X680.935 Y1277.973 Z-0.039 F1000
G02 X684.525 Y1280.312 Z-0.116 I2.941 J-0.590
G03 X745.291 Y1272.099 Z-0.193 I79.509 J359.347
G01 X748.724 Y1272.333 Z-0.232
G03 X769.547 Y1288.021 Z-0.309 I-3.122 J25.806
G02 X769.591 Y1288.120 Z-0.386 I2.763 J-1.168
G03 X774.737 Y1313.420 Z-0.463 I-50.212 J23.387
G02 X774.737 Y1313.604 Z-0.540 I2.998 J0.104
G01 X776.157 Y1367.061 Z-0.579
G02 X779.154 Y1369.981 Z-0.656 I2.999 J-0.080
G01 X926.220 Y1370.037 Z-0.694
X931.220 Y1370.038 Z0.767
X941.220 Y1370.042 Z0.728
X951.220 Y1370.046 Z0.690
X956.220 Y1370.048 Z-0.849
X1358.140 Y1370.199 Z-0.887
X1363.140 Y1370.201 Z0.574
X1373.140 Y1370.205 Z0.536
X1383.140 Y1370.208 Z0.497
X1388.140 Y1370.210 Z-1.042
X1579.154 Y1370.282 Z-1.080
Look at Z axis.
I hope i understand your question right an answered right.
chab
2 Likes
Yes, I observed the Z axis moving down in ramp at the rate of 1mm per pass, not the 3mm per pass I had expected.
1 Like
Hi there, Goliath the cutter descends in a spiral along the track, so it always makes downward movements, so it will start out cutting at 1mm and work its way down to 3mm when the first turn is completed. Then a further turn will be necessary to define the cut made and actually cut it out of the panel. Values which obviously vary according to the thickness of the panel.
3 Likes
I did another run. This time I did get the expected Depth Per Pass. Both jobs where using a 6.35mm bit.
The difference between the two jobs was in job 1 I specified a plunge rate of 200, and Depth Per Pass as 3. For job 2 I specified a plunge rate 300, and Depth Per Pass as 3.18. I suspect a bug in the Gcode creation that is tied to the Bit size and Depth Per Pass selection. Someone would need to do further investigation to determine if my suspicion is valid.
1 Like
We can check if there is actually a problem in the G-Code, could you please send us the log file and project? You will receive an email shortly with a guide on how to extract and send them to us.
As of this morning, I believe I have found the errors of my my ways. Even though I am using the 6.35mm bit supplied wit the Goliath, I had created a new bit definition for it for plywood to have a default feed rate setting of 2000. In doing that, I had neglected to set the flute length, and had left it at 1mm. This does explain why I observed 1mm per pass when I requested 3. It does not explain why I got 3.18mm when 3.18 was requested. If I can locate the correct logs, I will send them to Springa.
2 Likes
Hi begordon1981, we kindly ask you a clarification about depth per pass, did you set 3 or 3.18?
We are therefore waiting for your log files so that we can better verify the situation.
I was not able to reliably identify the correct log file to send in. I am planning another run in the next week or two. At that time I will attempt to repeat the problem while keeping track of the log files to send to Springa.
1 Like
Hi@begordon1981
The log files are all notepad files (simple txt) and you can open them with notepad. They is a lot of information and it is all date stamped you can check for the correct date and time if you temember and you can check it and send to springa.
Good luck
1 Like
I was able to look at the files. There are several on the date in question and I was uncertain which to send, and did not want to create a problem by sending the wrong one. I will be doing another run in the next few weeks. I believe I can reproduce the issue, and keep track of the log files so I can send a meaningful log file with appropriate description at that time.
2 Likes
Great, we look forward to hearing from you.
For what reason does Slingshot/Goliath go down in a spiral motion? This means that you still have to do one full loop extra and that the plunge rate is not used…
By the way, Slingshot/Goliath start with a Z-axis value of about -0,01 mm… so the first cut is taking almost no material away in the first half of the track… Not very efficient if you have a large part.
This also means that a combined upward/downward spiral milling bit is not usable because it needs a minimum depth to plunge at the start (no ramping down)…
We determined that Goliath should make spiral cuts as this allows it to overcome a more constant force.
Moreover, thanks to this moidity, the milling cutter never stands still and therefore the risk of burning wood is far lower.
So we confirm that at the moment a combined upward/downward spiral milling bit is not usable.
However, if you would like other cutting logics to be implemented, please let us know. 
In the case of “open tracks” Goliath starts with z almost zero and at the end of the track, z equals the “Depth per pass”. But then it gets weird… when returning to the beginning of the track, Goliath keeps going down acoording the depth per pass… this means that when Goliath is back near the beginning, the router is busy milling material TWO TIMES the depth per pass!!
The same applies for all following passes, be it towards the end or back towards the beginning of the open track…
1 Like
Hi Koenraad, thanks for your feedback, Goliath’s behaviour is not correct with respect to the parameters, so we will take the necessary steps to solve this as soon as possible.