I'm using an Arduino Uno and CNC Shield.

I’m using an Arduino Uno and CNC Shield. The Z axis is definitely going in the wrong direction. How do I go about changing the direction? When I jog the -z it raises the tool. +z lowers the tool. I have changed nothing in the GRBL settings other than the steps/mm to set proper travel with a dial indicator. Any help would be greatly appreciated.

two methods.
Either change a pair of the wires going into your controller or
Change the grbl config.

Assuming you have changed nothing then sending $3=4 via the serial widget should reverse the z axis.

I plan on using the same controller/shield on several machines. So I’ll run with the grbl config. All the Shields and motors I have are the same. When you say change a pair of wires are you referring to motor to driver or controller to driver?

Was meaning a pair to the motor.

That’s what I thought since we are using a shield. Not afraid to change the wiring. Just didn’t want to on a small " lets get it working Mill". I didn’t realize going through the serial widget, it would save the z axis setting. Thank you much. Still struggling with cp being consistent. Running gbrl 0.9?? Not 1.1. Had the calibration near perfect yesterday. Tried today and it was way off with the same settings for travel. The funny part is that the x and y settings are the same. The x axis was running 83 percent an the z axis was running 190 percent. I got to double digits after the decimal in the grbl widget and didn’t see any change on the
.000 Might try micro stepping a bit more. At this point the Mill can destroy itself as it has tried many times.

You have to choose your workspace.

Grbl workspace is stable but supports only grbl 0.9 and has issues with auto levelling.

The jpadie workspace supports grbl 1.1 and 0.9 and the autolevelling code is fixed. But there are reports of issues using inches based gcode.

Re your issues check the grbl config. Type $$ into the serial widget to check the current values. Then also check the micro stepping on your controller board. Perhaps you have different jumpers set. Or perhaps the board is imperfect and the jumpers have solder bridges.

Very possible on the shield. I had 8825 drivers that came with the first shield. They were impossible to set and the motors ran hot, the drivers overheated. One driver blew a hole through the chip in 2 places. I’ve ordered about 20 4000 series drivers, green and red, 6 Shields and I have plenty of controllers. I put in the green drivers and never touched them. They are never hot to the touch and the motors never get more than warm. Never hot. The seller sent me a new set of drivers and shield, no questions asked. I have checked all the jumpers, they are correct. I believe they are 1/8th stepping. I may try changing the uno and the shield. So the workspaces can be from different locations? I’m not in front of the computer at the moment.

Each workspace ingests different widgets. My workspace (jpadie) I extended for 1.1 support.

If the settings are not sticking then there may be something odd with your Uno. Or are you reflashing it? Doing so will zero the settings again

Usually sending a config command is sticky.

I’m not a CNC hardware guy but from an electronics perspective it sounds like too much power going through the chips. Heat sinking may help? But if you’re going for high end use and want to use the cheap chips then perhaps sinking plus a fan or an airpump will increase the longevity. I use the gshield with small steppers and they chips never get hot. But I mill PCBs (or try to) so the gantry is never under real stress and the motors never run too hard.

Never reflashed. The 4490??? Chips I’m using now are perfect out of the package. I heat sink all the drivers. So I’m assuming you go to chilipeppr and grbl, then choose jpadie as a workspace? Now you have me wondering what I am using for a work space. I’m still on the cp logo. I’ve never loaded a gcode file into cp.

They are URLs. So added /grbl for grbl 0.9x.

Basically if you are getting meaningful data in the axis widget then the messages are being parsed correctly.

If you are on grbl1.1x and use inches then you might have to do some work on forking the workspace and grbl widget for your own purposes. It has been on my to-do list for a long time. I have some working code but I have not tested it sufficiently to deploy

I just received my xPro V3 today to replace my TinyG. I had to reverse the wires on one of the Y axes (a axis) and the Z axis. It was much easier than figuring out immediately how to reconfigure those motors. Though I do need to get used to configuring with grbl. It’s a little different from TinyG. At least from what I’ve seen.

In grbl config is stored in eeeprom so doesn’t need to get sent as part of a start up block.

There is a config tool in the grbl widget. I am trying to build a more user friendly tool for grbl too but like all these things it is a question of finding enough time to sit and test the code properly.

I’m sure it’s just something I have to get used to, and I will. Can’t be that hard to figure out. I was pleasantly surprised that I didn’t really have to change anything to get the dimensions straight. I don’t know if that was because the site saved that to my machine even though I switched controllers.

I did, however, have a problem jogging my Y axis though. It moved very slowly. Not so much with X or Z. I really like the Z axis movement with my xPRO V, just got to adjust the Y.

The jog rate is limited in grbl to 200mm/min from memory. But you can also force the rate lower through the config. I will look at this though.

ok. thanks for the info justin