Y Axis homing in reverse direction if acceleration increased

tsitalon1

Hey guys,

Like title suggests, if I increase my X/Y acceleration from 1700 to 1800, the Y homing direction will go backwards during homing. To be a bit more clear, this only happens during homing.

Using the dashboard and manually selecting -XX on the Y axis results in the correct direction.

This is the oddest thing I've seen... need a bit of help here.

0.9º steppers (SparkFun Electronics / ROB-10846 / 42BTGHM809)

relevant config.g info:

M350 X16 Y16 Z16 E16 I1                                                 ; Configure microstepping with interpolation
M92 X160 Y160 Z403 E820                         	     	     	; Set steps per mm
M566 X1200 Y1200 Z150 E900                            			; Set maximum instantaneous speed changes (mm/min)
M203 X18000 Y18000 Z1800 E18000                             	        ; Set maximum speeds (mm/min)
M201 X1700 Y1700 Z100 E3500                                		; Set accelerations (mm/s^2)
M906 X1300 Y1300 Z1000 E700 I25                          		; Set motor currents (mA) and motor idle factor in per cent
M84 S10                                                                 ; Set idle timeout


; Endstops
;M574 X1 S1 P"!xstop"   				; X min active high endstop switch
;M574 Y1 S1 P"!ystop"   				; Y min active high endstop switch
M591 D0 P2 C"e0stop" S1  		                ; filament monitor connected to E0 endstop
M574 X1 Y1 S3						; configure sensorless endstop for low XY
M915 X Y S2 F0 R0

Relevant homeall.g:

M913 X25 Y25		 ; reduce motor current to 25% to prevent belts slipping
G91                      ; relative positioning
G1 H2 Z5 F4000           ; lift Z relative to current position
G1 H1 X-333 F5500        ; home X axis
G1 H1 Y-333 F5500        ; home Y axis
G1 X5 Y30 F4000          ; go back a few mm
G90                      ; absolute positioning
G30                      ; home Z by probing the bed
M913 X100 Y100

Phaedrux

Is it 100% verifiably related to acceleration?

What kind of a printer is it? Is the Y axis heavy?

tsitalon1

@phaedrux

Yep - if all I change is this line from:
M201 X1800 Y1700 Z100 E3500

to:
M201 X1800 Y1800 Z100 E3500

The Y axis moves the wrong way during homing.

It's a Core X/Y, not heavier than other HEVO builds, just using a MGN15 linear rail and direct drive extruder.

I updated firmware to 3.2.2 in hopes it was a bug, but there is no change in behavior after the firmware update.

Phaedrux

And if you change it back to 1700 it goes back to normal?

If you send M569 for that driver before and after does it stay the same direction setting?

Can you also test reducing jerk on Y a bit?

tsitalon1

@phaedrux

M569 P0 and P1 both report the below, even after the acceleration increase:

runs forwards, active low enable, timing fast, mode spreadCycle, ccr 0x101b4, toff 4, tblank 2, hstart/hend/hdec 3/3/0, pos 0

Reducing Y jerk from 1200 to 800 had no affect, still homing backwards on Y axis.

Can take a video if it will help.

Again, only happens when homing, dashboard movement buttons work normally.

Phaedrux

Can you provide the results of M122 and M98 P"config.g" as well?

tsitalon1

@phaedrux said in Y Axis homing in reverse direction if acceleration increased:

M98 P"config.g"

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.2.2 running on Duet WiFi 1.02 or later
Board ID: 08DGM-917NK-F2MS4-7JTD0-3S06L-KYSWD
Used output buffers: 3 of 24 (11 max)
=== RTOS ===
Static ram: 23460
Dynamic ram: 73344 of which 24 recycled
Never used RAM 15252, free system stack 189 words
Tasks: NETWORK(ready,182) HEAT(blocked,308) MAIN(running,379) IDLE(ready,20)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:00:36 ago, cause: software
Last software reset at 2021-05-10 20:12, reason: User, GCodes spinning, available RAM 15008, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 33.4, current 33.9, max 34.4
Supply voltage: min 24.0, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: position 0, standstill, SG min/max not available
Driver 1: position 0, standstill, SG min/max not available
Driver 2: position 0, standstill, SG min/max not available
Driver 3: position 0, standstill, SG min/max not available
Driver 4: position 0, standstill, SG min/max not available
Driver 5: position 0
Driver 6: position 0
Driver 7: position 0
Driver 8: position 0
Driver 9: position 0
Driver 10: position 0
Driver 11: position 0
Date/time: 2021-05-10 20:13:10
Cache data hit count 42781474
Slowest loop: 7.61ms; fastest: 0.22ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 1.1ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 170.05ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.25
WiFi MAC address 84:f3:eb:42:79:a2
WiFi Vcc 3.49, reset reason Power up
WiFi flash size 4194304, free heap 26696
WiFi IP address 192.168.1.97
WiFi signal strength -40dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0
=== Filament sensors ===
Extruder 0 sensor: ok

M98 P"config.g"
HTTP is enabled on port 80
FTP is disabled
TELNET is disabled

fcwilt

@tsitalon1

Hi,

Have you tried a slower Y axis speed during homing to see if that has an effect?

Frederick

dc42

@tsitalon1 the most common cause of a motor going in either direction is that only one phase is working. But in that case, the torque provided is also very low.

To check that it isn't a driver issue, you could move the Y motor cable to a different driver output on the Duet (with power off, of course) and make a corresponding change to the M584 command in config.g. Then see if the behaviour is any different.

tsitalon1

Getting very frustrated and starting to suspect a bad board.

I'll do my best to explain in clear terms, printer is setup as follows:
Core XY
Motors in front thus front left should be 0:0

Expected homing behavior:
print head should move to far left and then to the very front.

I was able to tweak the acceleration, homing speed, and homing current to get it somewhat consistent, meaning with the below parameters, I was able to get it to home over and over again properly - about 10 times... not printing in between, just home-all, move head via dashboard buttons to ~ 150:180 and home-all again

M201 X2000 Y2000 Z100 E3500                                			      ; Set accelerations (mm/s^2)

M913 X30 Y25		; reduce motor current to 25% to prevent belts slipping
G91                     ; relative positioning
G1 H2 Z5 F4000          ; lift Z relative to current position
G1 H1 X-333 F5000       ; home X axis
G1 H1 Y-333 F5500       ; home Y axis
G1 X5 Y30 F4000         ; go back a few mm
;G90                    ; absolute positioning
G30                     ; home Z by probing the bed
M913 X100 Y100

I heated the bed to 65 and the nozzle to 230, performed the same test above and got very inconsistent results:
Print head moved straight forward, did not move left at all.
next homing sequence the print head moved far left, but then moved backwards.
Tried a few more times with no changes and it worked as expected.

Printed a very small amount - less than 1 minute of printing, after which I immediately tried to print the same model by using the print again button, results during homing:
Print head moved straight forward, did not move left at all.

I am beyond shocked at these results... no clue what to do now..

dc42

@tsitalon1 have you read my earlier reply?

tsitalon1

@dc42 said in Y Axis homing in reverse direction if acceleration increased:

@tsitalon1 have you read my earlier reply?

Yes, but I'm unsure how to.

So you are suggesting I use my Extruder 1 driver and map the Extruder 1 to the Y axis using the M584 command?

If so, what else would I need to change to test that? I assume I would need to comment out other things..

fcwilt

@tsitalon1 said in Y Axis homing in reverse direction if acceleration increased:

So you are suggesting I use my Extruder 1 driver and map the Extruder 1 to the Y axis using the M584 command?

Power off
swap Y and E cables at the Duet
Power on
edit M584 to match the new cable connections

That should do it.

Of course if you have some sort of problem with the Duet the E stepper may begin to malfunction.

tsitalon1

Used M584 to map drive 4 to Y.

Homing worked fine 4 times straight.

Tried a print, after printing I tried the "print again" button and this time when homing it went straight forward without even attempting to move left or right.

It only happens when homing, but could this be a bad motor?

Phaedrux

@tsitalon1 said in Y Axis homing in reverse direction if acceleration increased:

but could this be a bad motor?

Do you have a spare motor to test with?

Were you using the same cabling?

tsitalon1

@phaedrux said in Y Axis homing in reverse direction if acceleration increased:

@tsitalon1 said in Y Axis homing in reverse direction if acceleration increased:

but could this be a bad motor?

Do you have a spare motor to test with?

Were you using the same cabling?

not another 0.9º motor. I have plenty of 1.8º steppers, I recently moved to these for finer resolution. These have integrated wiring, so I had cut my harness and make connectors for them. there's about 6-8" of wire with two connectors for each motor

Switching back to the 1.8º steppers is doable, but non PnP at this point.

tsitalon1

Swapped the X and Y motors, ran another test - same outcome.

was hoping it would follow the bad motor but it did not...

could be wiring, but then why only does it act this way during homing..

could something in my slicer end Gcode cause this issue to manifest on the next homing routine?

I wouldn't think so since home-all resets all movement methods (relative vs absolute).

tsitalon1

So some interesting news..

I switched back to the 1.8º steppers, reconfigured my steps to 80 steps/mm.

power cycled and tried homing, print head moved left and then backward on Y.

I increased homing current to 40% from the initial 30% and it homed correctly. Tried homing 10 times and 10 times it was perfect.

Tried the 2 prints back to back to see if after the 1st print it would misbehave on the homing sequence. to my surprise it did not, it's working flawlessly.

Thinking the back to back print outcome was a fluke, I tried it 3 more times, and all 3 times it was perfect.

The fact that even with the 1.8º steppers I saw backwards movement on Y until I changed homing current (same as I saw with the 0.9º steppers) makes me think my 0.9 steppers are fine, especially since they print without any issues.

Does this mean I have a bad board that is super sensitive to inductance and current draw of stepper motors, or is this expected behavior?

I couldn't for the life of me find a homing speed/current combination that produced consistent results with the 0.9º steppers.

I would prefer to go back to the 0.9º steppers as they are finer resolution and quieter.

fcwilt

@tsitalon1

I take it you are trying to use sensorless homing on X and Y thus the reduction in current?

If so I would suggest simply installing endstop sensors - no need to reduce current - problem goes away - even with 0.9 steppers.

Just FYI, I would never use sensorless homing - it seems to me it is akin to stopping your car by running into the car in front of you instead of using the brakes.

tsitalon1

@fcwilt

I hear you and I don't completely disagree, but I did spend a good chunk of money for one of the most advanced 3d printer main boards on the market and I believe I should be able to use the advertised features of this board.

Since we are making comparisons, that's like buying a new Corvette and detuning the motor just to save gas money... Doesn't really make sense.

Sensorless homing should work and seems like it does with 1.8° steppers. So there's really no reason it shouldn't with 0.9° steppers.

I searched this forum for the same model 0.9° steppers I'm using and I couldn't find a single post that wasn't my post... Seems like I bought some steppers that either no one uses, or at least no one bothered to mention in the forum.

Who knows, maybe I just bought the wrong steppers.

I would but new 0.9° steppers tomorrow if we (the group) believe my board is fine and I just possibly ran into a compatibility issue.