Please help -- TinyG postprocessor flipping Z axis

[Anonymous]

Hi,

I'm setting up a Sherline mill with a TinyG controller and experimenting with Inventor HSM for generating toolpaths. Something weird is happening: all the Z-axis moves in the .gcode files I'm getting are negative signed, so that the tool moves up when it's supposed to move down and vice versa. There's no problem with X and Y, but where the simulation shows the tool moving down, the actual file tells my tool to move up. But my Z axis on my machine is normal -- machine zero is the top of the column, and when I send positive Z commands to it over serial, it moves down toward the workpiece like you would expect.

I can't figure out why the files are being generated with negative Z signs. X and Y are fine, and the simulation in HSM looks good - but for some reason, HSM apparently thinks my controller is running an inverted Z axis (when in fact it isn't) and it seems to be trying to compensate by flipping the Z direction. How do I tell it not to do that?

I have been running tests using a simple program to mill the top face off a block of wax. It works correctly when I manually go through the .gcode file and multiply all the Z coordinates by -1. I'm attaching both the original file and the modified one, along with the .cps config for TinyG (which I have not modified).

I feel like one line of code in the config should be able to fix this, but I'm a newbie and I am scared of breaking things -- can anyone tell me what mod to try? Thanks!!

[Anonymous]

I think I got it.

The config contains this declaration:

var xyzFormat = createFormat({decimals:(unit == MM ? 3 : 4), forceDecimal:true});

which is then used to create the following objects:

var xOutput = createVariable({prefix:"X"}, xyzFormat);
var yOutput = createVariable({prefix:"Y"}, xyzFormat);
var zOutput = createVariable({prefix:"Z"}, xyzFormat);

So I spun off a new format type which inverts the value of the variable, by adding this line:
var zFormat = createFormat({decimals:(unit == MM ? 3 : 4), forceDecimal:true, scale:-1});

And applied it to the Z axis only by changing the "zOutput" line from the block above to the following:
var zOutput = createVariable({prefix:"Z"}, zFormat);

Seems to have done the trick.

[Anonymous]

I like your correction! I'm not very experienced with this yet, but I might have a clue for your root cause.

I'm using a tinyG with a Shapeoko2 and I had to invert my Z axis to have it respond correctly in Chilipeppr (up=up). The Z-axis dimensions are still correct according to right-hand coordinates -- +Z is up and away from the XY plane. However, you say that +Z should be down, away from the Z-home position at it's top of travel. The post processing confusion might just be a miscommunication about Z orientation. I'm not sure which is correct or standard.

[Anonymous]

Yeah, you're actually right; I figured it out a day or two later.

I was confused about the conventions for Z axis travel - didn't realize that it is normal for the z carriage to move in negative space relative to the homing/zero switch, which marks the travel maximum, as opposed to X and Y which move in positive space with the homing switches marking the minimum.

So all that code manipulation was actually unnecessary - oh well!