lathe moving in inverted direction while jogging direction is correct.

this Gcode is producing negative value moves, I don't see negative values anywhere. despite the machine working properly in the negative and positive direction from Axis gui.  I don't see ANY place except near end of facing where the machine should travel in a negative direction from ZERO. I am doing dry runs, and I set my ZERO at some imaginary place safe from the chuck, and I am also getting errors for moves out of range which is a tough pill to swallow considering the lathe has 12 inches of positive and 4 inches of negative travel on the X and 42 inches of positive on the Z and 2 inchs of negative on the Z.  How exactly does linuxcnc look at zero g53 etc, becuase I have been through the doc yets again with little no insight as to how to properly configure a back tool lathe program. 

 

smc.collins wrote:

... and I set my ZERO at some imaginary place safe from the chuck...
 

That is not right... On a lathe you should set z=0  at the same place where the origin was defined on fusion cam. I don't have fusion 360 but I'm using inventor cam which should be about the same. To set the origin you have to open 'setup' then Work coordinate system (WCS) then you should have a selection of choices such as: 'stock front', 'stock back', 'chuck front' etc... as well as offset from those position.  Once selected you MUST set the same origin (Z=0) on linuxcnc.

Also, if the origin is defined as 'stock back' or 'chuck front' in fusion 360 (or any other CAM software) it is pretty much guaranteed that you will not have any negative Z values in the g-codes program.

Those lines are most probably wrong:

N14 G53 G0 Z1100.
N15 G53 G0 X810.

N14 will position the machine 1100 mm from the machine origin, which is 43.3 inches positive, slightly more than the 42 inches you've mentioned.

N15 is 810mm is almost 32 inches (dia) which is 16" radius, pretty much at the limit of the total X travel but I would check to  make sure  your lathe can reach this since 4 inches of negative travel for the X axis doesn't really make sense on a lathe.

I'll have to check my post settings, but honestly, zero should be centerline of chuck at chuck face, on every lathe made and increasing in value from there. is g53 relative or absolute in this instance ????

G53 is the machine coordinate (datum). I guess you can then say it is the 'absolute' position of the machine. Everything else (g54, G54, G56...) is derived from this position + or - offset.

none of this explains the inversion of travel relative to command.

I'll check my config but im sure my home is set to home positive. the machine homes to x12 00 and z 42.00. away from the $4000 chuck and $15,000 spindle
if the post is setting g53, is that relative to zero from work  or from machine zero ??


for giggles and shits, I loaded up the pawn example nc program and it works correctly. So obviously the issue is with the post processing from fusion360

I also did a bunch of extensive x100 etc type rapid move commands, and those all work as expected. 

So, am I right in thinking I need to turn off tool compensation in the computer ? I think that's what causing the big negative moves g42 data coming over at the top of the program, Mind you I don't really deal with Gcode much, I use cam, because frankly, the computer is better at toolpath generation than I am and certainly faster for complex parts. . 
 

smc.collins wrote:

for giggles and shits, I loaded up the pawn example nc program and it works correctly. So obviously the issue is with the post processing from fusion360

 

If this is the case then It's not the post processor itself, it is your work coordinates that are setup wrong in fusion 360. Under 'setup' -> 'WCS' make sure that the 'thingy' showing the orientation of the x y z axis have the Z axis arrow pointing toward the right (not the chuck). If not you can just click on it or use the 'Flip Z axis' checkbox. 

smc.collins wrote:

So, am I right in thinking I need to turn off tool compensation in the computer ?
 

Tool compensation is how fusion adjust the toolpath according to the type and shape of the insert. I'm using this all the time for every tools in my tool library. I believe linuxcnc can do the same job but I'm more familiar with the way inventor cam is doing it. In any case you have to use it somewhere. if not your path will be all wrong.

JPL wrote:

smc.collins wrote:

for giggles and shits, I loaded up the pawn example nc program and it works correctly. So obviously the issue is with the post processing from fusion360

 
If this is the case then It's not the post processor itself, it is your work coordinates that are setup wrong in fusion 360. Under 'setup' -> 'WCS' make sure that the 'thingy' showing the orientation of the x y z axis have the Z axis arrow pointing toward the right (not the chuck). If not you can just click on it or use the 'Flip Z axis' checkbox. 

  Yes, I am aware of the WCS and it is set with Z pointing away from the chuck, chuck face as ZERO and the X in the same fashion from centerline of work.  The problem with using tool offsets in the cam, is that, they are meaningless.  I did look into my lathe config, I got fairly focused on my toolchanger, I need to resetup the machine now and go over it again. Should be easy to get up and running however. I will go over the entire machine setup tommorow and see if there's any gotchas.