Understanding G code to motion translation

Developers
1

I’m doing some preliminary investigation here, to understand how it works, without having actual hardwere operational.

Using the rp2040 MCU and the following sample G-Code (below) just looking at the output, it is homing X first but it looks like motions for X and Y. Is this normal or a bug in this configuration?

GCode:

G21 ; set units to millimeters
G90 ; use absolute positioning
M83 ; extruder relative mode
G28 W ; home all without mesh bed level

G92 E0.0
G92 X0.0 Y0.0 Z0.0
G1 X132 F1000.0
G1 Y60.0 E1.0 F1000.0 ; intro line
G1 Y100.0 E9.5 F1000.0 ; intro line
G92 E0.0 ; reset extruder distance position

MCU Motion:

allocate_oids count=16
# LED
config_digital_out oid=10 pin=gpio25 value=0 default_value=0 max_duration=0
# Heat bed sense
config_analog_in oid=11 pin=gpio26
# Heat Bed
config_digital_out oid=12 pin=gpio27 value=0 default_value=0 max_duration=60000000
set_digital_out_pwm_cycle oid=12 cycle_ticks=1200000
# Fan
config_digital_out oid=13 pin=gpio12 value=0 default_value=0 max_duration=0
set_digital_out_pwm_cycle oid=13 cycle_ticks=120000
# X
config_stepper oid=0 step_pin=gpio0 dir_pin=gpio3 invert_step=0 step_pulse_ticks=24
config_endstop oid=1 pin=gpio2 pull_up=1
config_trsync oid=2
# Y
config_stepper oid=3 step_pin=gpio4 dir_pin=gpio7 invert_step=0 step_pulse_ticks=24
config_endstop oid=4 pin=gpio6 pull_up=1
config_trsync oid=5
# Z
config_stepper oid=6 step_pin=gpio16 dir_pin=gpio19 invert_step=0 step_pulse_ticks=24
config_endstop oid=7 pin=gpio18 pull_up=1
config_trsync oid=8
# E Sensor
config_analog_in oid=14 pin=gpio24
# E Heat
config_digital_out oid=15 pin=gpio22 value=0 default_value=0 max_duration=60000000
set_digital_out_pwm_cycle oid=15 cycle_ticks=1200000
# E Stepper
config_stepper oid=9 step_pin=gpio20 dir_pin=gpio23 invert_step=0 step_pulse_ticks=24
finalize_config crc=2334479221
###########################
# Heat bed
query_analog_in oid=11 clock=13320000 sample_ticks=12000 sample_count=8 rest_ticks=3600000 min_value=12005 max_value=32303 range_check_count=4
queue_digital_out oid=12 clock=2400000 on_ticks=0
# Part fan
queue_digital_out oid=13 clock=2400000 on_ticks=0
# E sensor and heat
query_analog_in oid=14 clock=13680000 sample_ticks=12000 sample_count=8 rest_ticks=3600000 min_value=1171 max_value=32331 range_check_count=4
queue_digital_out oid=15 clock=2400000 on_ticks=0

# Home - set X Trigger ?
trsync_start oid=2 report_clock=3000000 report_ticks=1200000 expire_reason=2
stepper_stop_on_trigger oid=0 trsync_oid=2
stepper_stop_on_trigger oid=3 trsync_oid=2
trsync_set_timeout oid=2 clock=6000000

# Home X - associate operation to trigger ?
endstop_home oid=1 clock=3000000 sample_ticks=180 sample_count=4 rest_ticks=2999 pin_value=1 trsync_oid=2 trigger_reason=1
# X Prepare for motion
set_next_step_dir oid=0 dir=0
# X - Initial movement, to prime MCU code?
queue_step oid=0 interval=3044000 count=1 add=0
# Y Prepare for motion -- WHY IS THIS HERE?
set_next_step_dir oid=3 dir=0
# Y - Initial movement, to prime MCU code?
queue_step oid=3 interval=3044000 count=1 add=0
#
# X/Y acceleration phase of motion
#
queue_step oid=0 interval=14453 count=2 add=-4186
queue_step oid=3 interval=14453 count=2 add=-4186
queue_step oid=0 interval=7896 count=5 add=-699
queue_step oid=3 interval=7896 count=5 add=-699
queue_step oid=0 interval=4952 count=8 add=-200
queue_step oid=3 interval=4952 count=8 add=-200
queue_step oid=0 interval=3431 count=11 add=-54
queue_step oid=3 interval=3431 count=11 add=-54
#
# X/Y Cruse phase of motion
#
queue_step oid=0 interval=3000 count=346 add=0
queue_step oid=3 interval=3000 count=346 add=0
queue_step oid=0 interval=3000 count=200 add=0
queue_step oid=3 interval=3000 count=200 add=0\
... etc. ...
2

In my MCU configuration I had commented out the ‘enable_pin’ as on my current SMART_RAMPS board with a MEGA2560, all enable pins on the drivers are hardwired enabled.

Is it possible, at this point in pipeline, the code requires at least a logical enable_pin from the MCU?

In the MCU, if the stepper is disabled, the motion for that stepper is ignored in code?

3

Hmm. well, I’d defined those enable pins and besides the configuration difference, the only other difference is here, another step that appears to enable the pin.


# Home - associate operation to trigger ?
endstop_home oid=1 clock=3000000 sample_ticks=180 sample_count=4 rest_ticks=2999 pin_value=1 trsync_oid=2 trigger_reason=1
# This is triggering the enable pins on both?
**queue_digital_out oid=14 clock=3024000 on_ticks=0**
**queue_digital_out oid=15 clock=3024000 on_ticks=0**
# X Prepare for movement, set direction
set_next_step_dir oid=0 dir=0
4

So, to get some hardware confirmation here, I’d hooked up the Pico Pi to a logic analyzer to see what is happening and for sure, it is homing X & Y at the same time (attempting too), hitting a timout, then homing Z.

Is it normal to home both axis in corexy kinimatics? The output above looks like it only sets up the trigger for the one axis and then the other. You’d think both triggers would be set up at same time if it was homing both together.

Screen Shot 2022-01-15 at 12.45.14 AM
Screen Shot 2022-01-15 at 12.45.14 AM1344×428 37.4 KB

5

Corexy kinematics require both motors to move to create purely X or Y movement. If only one motor is moving, the print head will move diagonally.

6

dough! of course. that takes some getting used to. :man_facepalming:

7

Ok, moving allong on the path of understanding. In that logic analyzer shot above, notice how the direction pin is set a full 1/4 second before any movement begins. I wonder why the delay? To allow time for motion queue to fill up in MCU?