Dual axis issues

[demigh0d]

I'm trying to get dual y-axis working. I'm using the latest Protoneer RPi CNC hat v2.60 which the developer says has the same pinout as thier arduino cnc shield v3.51.

The board set to map the 4th driver to A3/A4 and the endstop is connected to the Z endstop (I'm not using the Z axis for anything else).

The Y-Axis motor works but the A-Axis motor never moves.

Here's me config

define HOMING_CYCLE_0 (1<<X_AXIS)

define HOMING_CYCLE_1 (1<<Y_AXIS)

define ENABLE_DUAL_AXIS

define DUAL_AXIS_SELECT Y_AXIS

define DUAL_AXIS_CONFIG_PROTONEER_V3_51

Any suggestions would be greatly appreciated. Duane

[jsagot]

Hi, i don't know anything about your shield but all shields have common working constraints : you can't mix axis like you did, unless you rewrite a whole bunch of grbl's code. What you CAN do is setup A to be Y's slave, they will share steps, direction and limits, just pay attention in which way the motors will turn (with belt the motors turn in opposite direction, with leadscrew you don't have anything to worry about). Your shield should have some jumpers to use for configuring A's behavior. Hope that helps

[demigh0d]

Dual Axis support was added to grbl last year. It basically mirrors either the x, or the y, motor to a 4th stepper driver. The benefit to this, over hardware jumpers, is that each motor has its own end stop so the gantry will be automatically squared during the homing sequence.

I did figure out the cause of my problem though. The pins defined for the dual axis in cpu_map.h were reversed. Putting an led on the step and direction inputs to the driver and watching it while moving the y-axis pointed me to the cause.

[doppelhub]

I don't like grbl's present dual-axis implementation... adding a completely separate pwm output is much more difficult than just disabling one of the steppers on a dual-axis (e.g. pulling one stepper's enable pin low). In addition, the "self-squaring" functionality requires each limit switch to trip at exactly the same point, which is difficult to adjust in the real world.

In my fork, I've rewritten grbl's dual-axis concept to disable one stepper (as mentioned above). I've also added a '$LS' command, which is run ONLY after the machine is known to be square (e.g. at the factory, by running the spindle across the build plate). $LS finds the delta between when the two limit switches trip, then stores that calibration data in EEPROM. After that, calling "$L" will always re-square the machine. I'm sure my "$L" implementation could be more concise, but I don't completely understand grbl's underlying motion planner, and so I stayed pretty high level. Anywho, the above behavior works perfectly in my fork:

https://github.com/Defdist/grbl1v1g_GG3_GrBLDC3v0

[ArjanDeVries]

Looking at the source code It should be:

define DUAL_STEP_BIT 4 // Uno Analog Pin 4

define DUAL_DIRECTION_BIT 3 // Uno Analog Pin 3

For my CNC shield i needed to remove a cloning jumper from my board and add a seperate wire to attach Pin 12 and Pin 13 to the right stepper pins ( for the clone it's different). Just did some measurements to find the right pins. ;-)

The only problem is still have is with my end stops. There is something wrong but i don't yet know what is wrong. (see #783 )

[cub69]

I don't like grbl's present dual-axis implementation... adding a completely separate pwm output is much more difficult than just disabling one of the steppers on a dual-axis (e.g. pulling one stepper's enable pin low). In addition, the "self-squaring" functionality requires each limit switch to trip at exactly the same point, which is difficult to adjust in the real world.

In my fork, I've rewritten grbl's dual-axis concept to disable one stepper (as mentioned above). I've also added a '$LS' command, which is run ONLY after the machine is known to be square (e.g. at the factory, by running the spindle across the build plate). $LS finds the delta between when the two limit switches trip, then stores that calibration data in EEPROM. After that, calling "$L" will always re-square the machine. I'm sure my "$L" implementation could be more concise, but I don't completely understand grbl's underlying motion planner, and so I stayed pretty high level. Anywho, the above behavior works perfectly in my fork:

https://github.com/Defdist/grbl1v1g_GG3_GrBLDC3v0

Is this strictly for Uno based boards or will it work with a mega based (e.g. MKS gen v1.4)?