Y Axis homing in reverse direction if acceleration increased
-
Yep - if all I change is this line from:
M201 X1800 Y1700 Z100 E3500to:
M201 X1800 Y1800 Z100 E3500The 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.
-
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?
-
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.
-
Can you provide the results of M122 and M98 P"config.g" as well?
-
@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: okM98 P"config.g" HTTP is enabled on port 80 FTP is disabled TELNET is disabled -
Hi,
Have you tried a slower Y axis speed during homing to see if that has an effect?
Frederick
-
@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.
-
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:0Expected 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 Y100I 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..
-
@tsitalon1 have you read my earlier reply?
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@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..
-
@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.
-
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?
-
@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?
-
@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.
-
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).
-
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.
-
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.
-
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.
-
@tsitalon1 said in Y Axis homing in reverse direction if acceleration increased:
42BTGHM809
http://cdn.sparkfun.com/datasheets/Robotics/42BYGHM809.PDF
This the one?
Based on the specs they seem like they should be fine.
Up to what current have you been running the 0.9 motors during homing? 25% of 1300ma? That's only 300ma
Have you tried running them higher yet? Was it that low just to get a reliable stall? What was your stall detection tuning process?
https://duet3d.dozuki.com/Wiki/Stall_detection_and_sensorless_homing
-
@tsitalon1 said in Y Axis homing in reverse direction if acceleration increased:
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.
Not really a valid comparison.
Sensorless homing doesn't provide any performance benefits over physical endstop sensors.
I use IR beam break endstop sensors which will never wear out and if properly installed cannot be broken by excessive axis travel.
On the other hand sensorless homing requires excessive axis travel to occur with enough energy to be reliably detectable - banging into the limit of the travel strikes me as a rather brute force way to home an axis.
And as you have found out it can have issues.
But the important thing is that you are happy with your printer and it does what you want it to they way you want it to do that.
So keeping tweaking the parameters until you get it sorted.
