Not sure what I am missing here…very simple program of just a few holes. I recreated this drawing and still have the same error after post processing, when trying to pull up in FC. I am cutting other new and old programs just fine…file attached for reference.
Thanks!
paint tree v1.f3d (100.3 KB)
See if this works better. I did not take it thru post processing but the error is gone in the simulation.
Are you just cutting the holes?
paint tree v1Chelan v1.f3d (100.0 KB)
Can you share the gcode?
“Program speed not found” often means that there was no contour selected. Since there was an error in the Set-up, that might have neglected picking the contours correctly.
Look at the g-code. (Open in a text editor / notepad) The last line should say something like (PS150). The 150 refers to you highest cut speed. Higher up in the g-code you’ll see F statements after G1 commands. (Ex - G1 X0.5 Y0 F150) The F commandi is the feed / travel speed. In my example, feed is 150 ipm. This should maych you tool settings. Note - If you have rules / Fusion perameters set. Some feeds may be slower than straight line cuts. Look for the largest F value.
If your last line has no PS value, or PS0, repost.
Additionally, share the g-code (.nc file), and well look.at it.
Wasn’t there some fusion error people were having where it didn’t output a cut speed if all the cut paths were subject to rules and never reached programmed speed?
Yup. This is a known issue. Easily duplicated in F360 with all of the post processors (the ones that are forum customized, and the OEM). If I do any patterns that are strictly circles - no program speed found.
I just growl, open the file up in Text Document, add the program speed to the last line PSxxx save and go.
LOL! THAT is funny! Seems like an easy fix in the post processor…
Here you go. Seems strange that the F statements/speeds are what I expect, but PS0 at the end?
tree nc.txt (3.0 KB)
Well that might be it. because this is only cutting small holes and they never get to full cut “speed.”
This IS the last part of his gcode file:
G0 X0. Y-15.0075
G92 Z0.
G38.2 Z-5. F100.
G38.4 Z0.5 F20.
G92 Z0.
G0 Z-0.03 (IHS Springback + Backlash)
G92 Z0.
G0 Z0.15 (Pierce Height)
M3
G4 P0.5
G0 Z0.06 (Cut Height)
H1
G1 Y-14.9675 F110.
G3 Y-15.0325 I0. J-0.0325 F66.
G3 X0.0321 Y-14.995 I0. J0.0325
G3 X-0.0098 Y-14.969 I-0.0321 J-0.005
H0
M5
G0 Z0.5
M30
(PS0) <<<Here is your problem. Like Sticks and Terrance said just change this to (PS50) or whatever your cut speed is suppose to be.
PS is program total speed.
F stands for feedrate I believe, for each individual path.
Even a 4" dia washer with a 1.5 bore failed on my end.
That is interesting. I did not have that problem with this gcode cutting 2" circles out of a 4" flat bar but the cut never slowed down for the entire program so that might have been the difference.
M30
(PS47)
Ok, seems easy enough, and maybe I am missing something, but I am sure that I cant edit the gcode in a text editor and use that file??? So how/where do I make this change?
You CAN edit it in any text viewer/ word processor.
Just double click on it and it will open up your default text editor (most likely). If it doesn’t then when given the choice, just pick NotePad in Windows as your default viewer.
@Sticks, you are a genius!
So I ran a test with these circles:
Then I ran the post processor picking only the smallest circle that had the slow speed:
Here is the gcode with the problem child that will cause that error:
So maybe that is the lesson: If the full cut speed is never realized in the program then it will fail with that final entry. Perhaps that is a bug in the post-processor.
Thank you all for your help guys! Fixed the code and cut. This will help as I have had other programs do the same.
Stupid Post Processor!
This issue has been brought up a few times in the past.
If the majority of your program speed is not the standard feed rate issues will happen.
If you have a path that has most of the feed rate is optimized then change the standard feed rate to the optimized one for that path, instead of using optimization. or combined multi paths into your NC file.
For those that like to tinker, here’s where the post processor assigns the PS value:
if(getMovement() == MOVEMENT_CUTTING && feed > maxCuttingFeedRate){
maxCuttingFeedRate = feed;
This occurs at the start of Functions OnLinear and OnCircular. The intent is to compare the current feed rate to maxCuttingFeedRate, and update if larger.
However, something is happening to GetMovement() == MOVEMENT_CUTTING. They should be equal values and allow MaxCuttingFeedRate to update. Something in the reduced feed rate is triggering the fail at this point.
Just my .02
Edit - Ok, found something. When Feed Optimization engages, the cutting movement changes to MOVEMENT_REDUCED. If the entire G-code consists of speed optimized code, maxCuttingFeedRate will not update. I’m going to try to play with the logic so MOVEMENT_CUTTING and MOVEMENT_REDUCED are accepted.
Ok, here’s a solution:
Edit the post. The if(getMovement() line below occurs twice. Once in OnLinear and once in OnCircular.
if(getMovement() == MOVEMENT_CUTTING && feed > maxCuttingFeedRate){
maxCuttingFeedRate = feed;
}
Add the lowing line under each occurrence.
if(getMovement() == MOVEMENT_REDUCED && feed > maxCuttingFeedRate){
maxCuttingFeedRate = feed;
}
Save your post (ensuring .cps extension) and load / re-load into Fusions Post library.
Tested with a .5" circle on 2" square, only cutting the circle with feed optimization on. Before the edit, no program speed (PS0). After the edit, program speed occured (PS18 in my case.)
Please test and see if this helps!
This is my modified post (v1.7.1) -
FireControl-v1.7.1.cps.txt (18.7 KB)
If you use, remove the .txt extension!