Super weird problem lcnc doesnt follow path

Hi guys, this one problem has me really confused, will try to explain as much as i can.

I own a cnc router, recently finished, learning tons of stuff. Already managed to make some cool parts, but for some reason im having a problem with this particular setup.
The main thing is: linuxcnc doesnt want to follow the path, the screen shows exactly the same thing as the fusion simulation, but when the machine is actually cutting and doing the path, on the first pass, the machine doesnt follow the path at all, (pics of machined wrong path and of the screen with the actual correct path) On top of it, the screen shows the wrong path that the machine is doing. And Btw, other geometries in the same file (with more curves and straight lines as well) are beeing followed like they should.

drive.google.com/open?id=1zYmR5qAgcJFBxVzJypps4bOH8q9Fozxe3A Picture of the Actual machine path (wrong)

drive.google.com/open?id=1-CdvlQb9JoFcX0vD8pQSAfD8J9uiyPmfPg screen of linuxcnc and what it should do.

Things that i ruled out (im new and learning so i could be wrong):

g65 tolerance is set to 0.2mm But: the second pass of that same geometry is being followed like it should. and only the first pass is off.
with that said, i ruled out too: machine stiffness and flex, missing steps.

i've tried to search on google, and the different sections of the linuxcnc forum, but i couldnt really find anything very similar.

Additional information to rule out stuff:
Tried different configurations of fusion 360 with what it used to work for me on the 2dcountour settings (passes, geometries,etc)
Tried the (all) and (milling) post process options for the fusion 360 pp setup.

i truly didnt come up with any other thing that could be causing this, but again im new to all this. Maybe someone with more experience can chime in and tell me where to look.

Thank you for your time.
Frank.

I have seen this on my machine with gcode I wrote when testing the machine for the very first time. I know nothing about gcode or CNC.

I solved it by putting a small Z movement after the movement to the corner. I have not seen it with any gcode generated by sheetcam.
You are not moving with G0 moves are you?
I don't know if it helps, but here's the preamble the POST inserted.

I understand, however the files i am making have 4000 lines, i dont think its viable to add small z movements on each contour. no, im not moving with G0 moves,
Thank you for your input

I believe that your problem has to do with G64 settings.
linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G64
G64 controls the path blending done by the Trajectory planner. The default setting in Linuxcnc is G64 with no tolerance. Which results in Linuxcnc moving the machine as fast as possible (or the programed feed rate) with no slow downs for corners, beyond what is required for the machine to touch the programed path at at least one point. Adding a path tolerance to the G64 command like this G64 P0.001, will result in the machine slowing at corners so that the path will will remain within Px machine units of the commanded path.

Todd wrote:

I believe that your problem has to do with G64 settings.
linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G64
G64 controls the path blending done by the Trajectory planner. commanded path.

I agree with Todd. Can you put a ballpoint or felt-tip pen in the spindle? Run the program at very slow speed and see if you get the more complicated pattern shown on the screen capture. You can tape paper to the spoil board to do the pen test.
If you get the right pattern at extremely slow speed, then you need to increase the acceleration limits in the .ini file. There are acceleration limits in both the [TRAJ] section and in the [JOINT_n] sections.

Ahh, and because it seems your user units are mm, these acceleration limits need to be cranked way up. Several hundred mm/sec^2 would be the minimum.

Jon

okey guys, this is going to be embarrasing, but i actually had g63 p0.2 instead of g64 p0.2 ; and it solved the issue. (and to top it off on the OP i said g65 instead of G64...)
YES im going to the dummys corner. but still, i didnt thought by far this code was the problem, as the second pass of the same exact geometry was absolutely perfect! and at the same time, the "new" blended path was WAY off of what it should have been. oh well..

Thanks everyone for your patience, please dont say bad words to me

Frank

Glad to hear that you found the problem. Sometimes simple typos like that can be the hardest problems to find. At first glance your mind sees the error as what it should be rather than what it is.