Yes.
Yes.
I have one more try in me then it is bed time. This is such a bummer. I am a bit closer though.
Okay I think I have it now. I will know for sure tomorrow.
I set the end stops to NEG, and the Pulloffs to the negatives I need (Y-4 X-9) that seems to work. It does not survive a reboot so I need to get that in the yaml.
In the end that will actually make using the table easier. You should not need to add the start gcode to the Sandify files anymore. I am pretty sure that will handle all off it, might still need a G92, but I will test it tomorrow.
I also increased the motor current. Still more testing to do on that.
Okay it is working again.
My newest .yaml - I think I need to edit or delete the speed scalars in there it is not doing what I want during homing.
name: TMC2209 Pen Laser
board: unknown
kinematics:
CoreXY:
stepping:
engine: RMT
idle_ms: 250
dir_delay_us: 0
pulse_us: 3
disable_delay_us: 0
axes:
x:
steps_per_mm: 100.000
max_rate_mm_per_min: 8000.000
acceleration_mm_per_sec2: 300.000
max_travel_mm: 692.000
soft_limits: false
homing:
cycle: 1
mpos_mm: 0.000
positive_direction: false
pulloff_mm: 1.000
settle_ms: 250.000
seek_mm_per_min: 1000.000
feed_mm_per_min: 500.000
seek_scaler: 1.100
feed_scaler: 5.000
motor0:
limit_neg_pin: gpio.33
hard_limits: false
tmc_2209:
direction_pin: gpio.26
step_pin: gpio.12
r_sense_ohms: 0.110
addr: 0
run_amps: 0.500
hold_amps: 0.325
microsteps: 16
run_mode: StealthChop
homing_mode: StealthChop
use_enable: false
uart:
txd_pin: gpio.22
rxd_pin: gpio.21
baud: 115200
mode: 8N1
y:
steps_per_mm: 100.000
max_rate_mm_per_min: 8000.000
acceleration_mm_per_sec2: 300.000
max_travel_mm: 1306.000
soft_limits: false
homing:
cycle: 0
mpos_mm: 0.000
positive_direction: false
pulloff_mm: 1.000
settle_ms: 250.000
seek_mm_per_min: 1000.000
feed_mm_per_min: 500.000
seek_scaler: 1.100
feed_scaler: 5.000
motor0:
limit_neg_pin: gpio.32
hard_limits: false
tmc_2209:
direction_pin: gpio.25
step_pin: gpio.14
r_sense_ohms: 0.110
addr: 1
run_amps: 0.500
hold_amps: 0.325
microsteps: 16
run_mode: StealthChop
homing_mode: StealthChop
use_enable: false
z:
steps_per_mm: 100.000
max_rate_mm_per_min: 1000.000
acceleration_mm_per_sec2: 200.000
max_travel_mm: 300.000
soft_limits: false
homing:
cycle: 3
motor0:
null_motor:
spi:
miso_pin: gpio.19
mosi_pin: gpio.23
sck_pin: gpio.18
sdcard:
cs_pin: gpio.5
probe:
check_mode_start: false
start:
must_home: false
check_limits: false
deactivate_parking: true
arc_tolerance_mm: 0.002
junction_deviation_mm: 0.010
verbose_errors: false
report_inches: false
enable_parking_override_control: true
use_line_numbers: false
My new start Gcode. The last line just set the speed for the rest of the pattern.
$HY
G0 Y-4 F50
G92 Y0
$HX
G0 X-13 F50
G92 X0
G1 X1 F5000
The problem I am having now is it is pausing randomly during moves, even just long straight lines (so not a buffer thing). Drivers are not even really warm, and steppers are cold so not a thermal shutdown. Turned off the LEDās so it should not be a power thing.
I will try swapping the memory card, and maybe the ESP32. Maybe one is funky.
Hi everyone,
this thread was very useful to me so far and I finally got my wiring correct so the +x and +y axis are moving like intended! I am mostly using Ryansā config and using the TMC2209 Pen Laser board version 1 (1 iteration before current).
So when controlling by the web interface it is moving perfect linear in x and y but when homing the center is moving diagonal and in positive y even I have āpositive_direction: falseā in my configuration. I try to create short video this evening so you can understand my problem better.
Is your homing working flawlessly? Could it be a problem of my ESP32, even if everything is fine expect homing?
Make sure your Stepper current settings are high enough. It sounds like it might be too low and one of your steppers is overpowering the other. Orā¦make sure x+100 is actually 100 and same for Y. If the steps are wrong it would move diagonal.
I adjusted the current to the stepper values but that didnāt change anything. Going only X and Y works fine but homing is weird.
This is my Config file:
board: TMC2209 Pen
name: TMC2209 Pen
kinematics:
corexy:
stepping:
engine: RMT
idle_ms: 250
dir_delay_us: 0
pulse_us: 3
disable_delay_us: 0
axes:
x:
steps_per_mm: 200.000
max_rate_mm_per_min: 8000.000
acceleration_mm_per_sec2: 300.000
max_travel_mm: 565.000
soft_limits: false
homing:
cycle: 2
allow_single_axis: true
mpos_mm: 0.000
positive_direction: false
pulloff_mm: 1.000
settle_ms: 250
seek_mm_per_min: 1000.000
feed_mm_per_min: 500.000
seek_scaler: 1.100
feed_scaler: 5.000
motor0:
limit_neg_pin: gpio.33
hard_limits: false
tmc_2209:
direction_pin: gpio.26
step_pin: gpio.12
r_sense_ohms: 0.110
addr: 0
run_amps: 0.500
hold_amps: 0.325
microsteps: 16
run_mode: StealthChop
homing_mode: StealthChop
use_enable: false
uart:
txd_pin: gpio.22
rxd_pin: gpio.21
baud: 115200
mode: 8N1
y:
steps_per_mm: 200.000
max_rate_mm_per_min: 8000.000
acceleration_mm_per_sec2: 300.000
max_travel_mm: 1010.000
soft_limits: false
homing:
cycle: 1
allow_single_axis: true
mpos_mm: 0.000
positive_direction: false
pulloff_mm: 1.000
settle_ms: 250.000
seek_mm_per_min: 1000.000
feed_mm_per_min: 500.000
seek_scaler: 1.100
feed_scaler: 5.000
motor0:
limit_pos_pin: gpio.32
hard_limits: false
tmc_2209:
direction_pin: gpio.25
step_pin: gpio.14
r_sense_ohms: 0.110
addr: 1
run_amps: 0.500
hold_amps: 0.325
microsteps: 16
run_mode: StealthChop
homing_mode: StealthChop
use_enable: false
z:
steps_per_mm: 100.000
max_rate_mm_per_min: 1000.000
acceleration_mm_per_sec2: 200.000
max_travel_mm: 300.000
soft_limits: false
homing:
cycle: 3
motor0:
null_motor:
spi:
miso_pin: gpio.19
mosi_pin: gpio.23
sck_pin: gpio.18
sdcard:
cs_pin: gpio.5
probe:
check_mode_start: false
start:
must_home: false
check_limits: true
deactivate_parking: true
arc_tolerance_mm: 0.002
junction_deviation_mm: 0.010
verbose_errors: false
report_inches: false
enable_parking_override_control: true
use_line_numbers: false
And here I made a short video. First going -x then +y and then $HY. At homing it goes also in the wrong direction and I donāt know why.
By default it homes positive, we home negative. You need this on each axis.
positive_direction: false
Not really familiar with the language, but some things I seeā¦
On the ZenXY, Y needs to home first, and your configuration seems to show that, but X is moving first. If I am reading the configuration right, it is programmed correctly for homing, seems like Y is step 1 and X is step 2.
Then Y moves in the wrong direction. Neither axis seems to get to the endstop.
My thought is that maybe one of your motors is backwards.
Reverse one motor, and X motion will become Y motion, and vice versa. If this is what is wrong, then your machine will try to home Y first, and then X. If it moves in the wrong direction after that, reverse both motors.
Shoot my bad I swear I looked, I did not see that you already had it.
The movement in x and y in the video I forced by the web interface.
The homing process started in the 3rd move and it went diagonal.
At the moment I flipped my motors that often around that I have the same orientation than Ryan in his instructions (both positive movements are away from the end stops). However, even with homing (positive_direction: false) it is moving in the wrong directionā¦
Is it possible that I have a wrong / corrupted firmware on my ESP32?
That is very strange. I will say mine will go diagonal every so often and I have to reboot the board to fix it. I am assuming you have done that many times.
Just in case it is erroring on the order swap it to y=0 X=1 Z=3 for homing order, Dan could be on to something there. It might make sense, it could be a safety since Z has not been homed. Seems to be our only config difference.
Also Bart said I can get rid of the Zaxis in the config. Give that a shot as well, I got an error but have not tried again since he said it was fine to do.
Any chance it thinks your endstops are triggered, NO or NC swapped? Or triple check your endstop pins in the config.
I wish I knew more about fluidnc to help faster.
Ok, once you have thst, the motor orientations are correct.
The diagonal movement, however is not. A corrupted firmware that still talks to your gcode sender and moves the machine is unlikely. I am not familiar with configuration setup, the one machine that I set up with a Bart Dring board was using GRBL-ESP32 which was the precursor to FluidNC, and worked first time, so I never edited it.
I see differences in the syntax of the motor sections. In both axes itās motor0 (should one be motor1? Looks like noā¦) And therr is a blank line in the one on the Y axis, is that significant? Also there is no uart section for the Y axis.
I.see that the X axis motor has a limit_neg_pin and thr Y axis has a limit_pos_pin. Could it be going to the positive limit because you have not defined a negative direction stop?
I have one more Bart Dring board, I shoukd probably flash an ESP32 and try it out.
This is an error and a relic from the time I had my wiring wrong! I will change this in the config and give an update later this evening.
I am not sure but I think the uart declaration only happens at the first motor. (Information from wiki)
I changed the configuration to ālimit_neg_pinā but it didnāt change the direction. I also changed some other parameters but without any successā¦
Btw. the home x command ($HX) also have the diagonal movement but in negative x and negative y (to the lower left).
I hope I find some time on the weekend to dig deeper. For me it is weird that the normal x and y movement is working but homing has errorsā¦ probably I will change the software/ESP32
It is best to ask the team over at fluidNC, they are really quick to find issues or know why they might be there. There are only a couple of us around here that have even used it and as you can see we are all making guesses.
The team over there will know why exactly and probably in one or two questions.
This evening I resetted my ESP32, erased all the flash, installed the filesystem and installed the wifi firmware. Now itās workingā¦
I could saved a lot of time if I tried this way earlier^^
1 Like
Well that is interesting. Thank you for the update.
I wonder how the heck that could happen.
I did not realize how tricky the homing was going to be.
The main issue I have is that for X to trigger, the Y needs to be at least a few mm past the 0 trigger point.
I was trying to get to a clean $H, not just a script like $HY; G0 Y-2; $HX.
Setting Y: homing: cycle: to 1 and X: homing: cycle: to 2 makes them home in sequence with $H. Z should be set to -1, so it doesnāt ever try to move Z. IDK what itās doing now, because I removed all of Z.
Setting X: homing: allow_single_axis: to false should mean I canāt accidentally hit the X home button and have it crash because Y isnāt in the right place. That would break the script Ryan is using though.
I have been playing with mpos_mm and pulloff_mm for x and y. I think pulloff_mm for Y needs to be at least 3mm (because if I push it all the way to its hard limit, and move away, the endstop doesnāt clear until 3mm). I think X pulloff_mm needs to be set to 13mm, because it also doesnāt clear the stepper for 13mm if it is all the way in the corner.
Iām not sure exactly what the mpos does. I have two things left though:
- I need Y to be 2mm past the trigger point for its endstop when X homes.
- I want to be able to adjust where the zero position is relative to where the endstop triggers. I want the zero to be at the hard stop.
Maybe I will post the question for Bart and their bunch and see what they say. I havenāt even finished reading the docs though. So I should probably start there.
Yeah I do think there is a bug in the homing routine. Did you see my Gcode workaround?
$HY
G92 X0 Y0
G0 Y-18.5
G92 X0 Y0
$HX
G0 X-28
G92 X0 Y0
G1 X2 F2000
What!? Those numbers are huge. Do you have the right steps/mm set?
I did see the script above. I think I could make that work.
My workaround right now is to just reach under and move the table to the 0,0 
. I will see if I can find a way to make the firmware do what we want with just one $H.