latest bugfix branch breaks tmc 2130 #11179
Comments
|
I added my two builds, one works the other does not. remove the .txt and unrar |
|
sorry i uploaded the wrong previous version. but i am still having these issues. apparently along the way marlin now requires endstop pullups to be enebled for this feature. but even after i get the errors to go away i still cannot get any motion out of the steppers. reverting to a previous version that still requires pullups works as it should, and the latest has no motion. |
|
4-21-18.rar.txt older bugfix with everything working as it should. latest bugfix has no motion. and no errors as i followed the rules in sanity check |
|
|
Reverted back to my April build and no issues. This latest build however will not move on any axis that has sensorless homing. I was running on a build previous to my April build and it didn’t require endstop pull-ups. My April build does. It could be that I was using a pre-configured example before April. And I missed something endstop related. But endstop pull-ups are not my issue. I fixed the pull-up issue and the latest build still does not move on x or y axis. Also from April build to current something else has changed. I was always able to enable sensorless homing and still use my z endstop like normal. Now it almost requires that z be sensorless as well. Even though I don’t it on z I now have to put my z axis sensitivity at around 14 to get it to not falsely trigger for whatever reason, even though I don’t even have it hooked up. If I set z sensitivity to 0 it considers it triggered already and so nothing moves. And I don’t know why because as I stated my z diag pin is unpopulated currently. I haven’t seen anywhere where anything has changed with sensorless homing so I am stumped on this one. Perhaps I’ll let another commit or two before I try again. Could just be something on my end. I’ve been digging and I can’t find any where where I messed up or any stray unintentional characters or anything. I did notice that another user was having issues with sensorless homing but after reading through their issues I couldn’t find anything relevant to my case.
…Sent from my iPhone
On Jul 2, 2018, at 11:39 PM, Scott Lahteine <notifications@github.com<mailto:notifications@github.com>> wrote:
* Either enable ENDSTOPPULLUPS or the individual axis pullups, but not both.
* Don't forget to use M502, M500 after flashing the firmware.
* If you're not using the X Max endstop for something, disable USE_XMAX_PLUG.
* If you're not using the Z Max endstop for something, disable USE_ZMAX_PLUG.
* Be sure to use the latest bugfix-1.1.x or bugfix-2.0.x branch so we're all on the same page.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMarlinFirmware%2FMarlin%2Fissues%2F11179%23issuecomment-402011112&data=02%7C01%7C%7Cd83dfc7f154a400a22c908d5e09f0528%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636661895940935133&sdata=91fJ5RIWEJqprWspXSCq3EBL4t26%2FX%2FgLA2SqPWTsWk%3D&reserved=0>, or mute the thread<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAB7M2pPHcHSpOnVpb8GMEUAvN16o7jNXks5uCvWYgaJpZM4U-sQZ&data=02%7C01%7C%7Cd83dfc7f154a400a22c908d5e09f0528%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636661895940935133&sdata=WyC%2B91tw3wOWVa03%2Bgv%2Blz%2BrFgIgmI%2BoV8LdwsDZB7M%3D&reserved=0>.
|
|
@wbarber69: Could it be related to this change. That change was done because the default configuration was dangerous to some boards. |
|
Hi, I'm having the same issues. I didn't need to invert the endstops logic before. My previous build was the bugfix-2.0.x from March: |
|
That was the first thing I tried, but if I invert what I had I get the X axis stuck in triggered: |
|
Yes, I'm using sensorless homing on both axes. I also have the pull-ups enabled. I tried enabling them individually and globally and it doesn't make a difference. |
|
Yes, except the current which is a little different. I also tried different values for the homing sensitivity. The M119 gcode reports the X endstop as TRIGGERED but the M122 says the TMCs didn't trigger: |
That The |
|
Which pretty much means it’s an electrical issue, or you’ve got something inverted the wrong way in firmware
…Sent from my iPhone
On Jul 15, 2018, at 5:02 PM, Scott Lahteine <notifications@github.com<mailto:notifications@github.com>> wrote:
That M122 output refers to the Overtemp Pre-Warn:
OT prewarn has
been triggered false false false false
The M119 command does report the current status of stallguard-based sensorless homing, but they will rarely show "triggered" because stallguard-based endstops don't stay triggered for very long — they're only triggered when a motor is actively hitting a barrier.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMarlinFirmware%2FMarlin%2Fissues%2F11179%23issuecomment-405121856&data=02%7C01%7C%7Cfd28ece26def475088ec08d5ea9e9e28%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636672889326774016&sdata=iVXvJIkmRLOppl14IyMG0NBbruyFiRoD1TcHQjeqVMw%3D&reserved=0>, or mute the thread<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAB7M2juv_AGbUGKEKdPc3G7k8RsDxY2rks5uG7vjgaJpZM4U-sQZ&data=02%7C01%7C%7Cfd28ece26def475088ec08d5ea9e9e28%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636672889326774016&sdata=rhyd8pZ2QTJrtBONsc3VN5Sox9Rnqqi4i0H21GO0t74%3D&reserved=0>.
|
|
It's not an electrical issue because my March build works just fine, and I'm using the same configuration. Both builds are uploaded in a previous comment. |
|
I'm experiencing a similar issue, and I'm still actively trying to nail it down. My build from 6/28 on the bugfix 1.1.x branch homes fine using sensorless homing on both X and Y. Using files from 7/19, my X stepper tries to home on the first G28 issued but it does so in StealthChop, rather than SpreadCycle. Obviously, stallguard won't work in StealthChop, so I shut off the machine before it rams the carriage into the endstop. After restarting the printer, the gantry assembly will raise on a G28, but the X and Y motors do not respond and eventually the printer is halted. X and Y will not attempt to home again unless I reflash the firmware. Re-flashing my build from 6/28 and again everything works fine... UPDATE: After exhaustive brute force trial-and-error, I've determined that my issue is related to this commit from 6/30.https://github.com/MarlinFirmware/Marlin/commit/718a22e8366aa66f95c7800dd56960cc31e05050 If I comment out those pin assignments (I do use the MKS GEN L board), then everything works fine again. Note that I am using the Stock Creality CR-10 display, if that makes a difference... |
|
I'm still having this issue, but I'm using a modified RAMPS board. I'm stuck my March build, and would love to update it. |
|
I am having the same issue. Never needed to invert my endstops before, and had sensorless homing working fine. Edit: I'm using the MKS Gen 1.4 board, and had it configured with the MKS_GEN_L board setting. I switched to MKS_GEN_13 (the correct board) and now everything seems to work with the inverted settings. |
|
I finally went ahead and recently tried to upgrade to the latest bugfix branch again, and low and behold i had the exact same issue. I finally figured it out though and its pretty stupid. Im using the mks gen-l board and when i define that board in my configuration it then uses the pins.h for that specific board. well after hours of trying to finally nail this problem down i had a eureka moment. in the past the gen-l pins.h would just forward to the generic ramps pins.h but somewhere along the line there was some changes made to the gen-l pins.h and there are actually two lines in there calling up the cs pins for the x and y. and since i use software spi for my trinamic drivers and those cs pins are declared in the standard pins.h thery are overridden by the gen-l pins.h.. after changing the necessary cs pin settings in the gen-l pins.h file im back up and running on the latest bugfix branch. |
|
I am having the exact same issue but I'm using an SKR V1.3. With sensorless homing enabled I have to invert the X and Y endstops and configure pullups for both X and Y. When asking X or Y to home the endstops trigger immediately no matter what the value of M914 sensitivity. |
|
Been there. Whoever had the brilliant idea to declare those two pins in the
MKS gen-l pins file broke my Trinamic setup several months ago and it took
me a while to figure it out. Note that in the “newer” 2.0.x firmware
versions, you can declare your cs pins in either configuration.h or
configuration_adv.h (I forget which) for Trinamic software spi which will
override the pins listed in your pins.h file. Just to make things more
confusing lol.
…On Thu, May 2, 2019 at 23:55 wbarber69 ***@***.***> wrote:
I finally went ahead and recently tried to upgrade to the latest bugfix
branch again, and low and behold i had the exact same issue. I finally
figured it out though and its pretty stupid. Im using the mks gen-l board
and when i define that board in my configuration it then uses the pins.h
for that specific board. well after hours of trying to finally nail this
problem down i had a eureka moment. in the past the gen-l pins.h would just
forward to the generic ramps pins.h but somewhere along the line there was
some changes made to the gen-l pins.h and there are actually two lines in
there calling up the cs pins for the x and y. and since i use software spi
for my trinamic drivers and those cs pins are declared in the standard
pins.h thery are overridden by the gen-l pins.h.. after changing the
necessary cs pin settings in the gen-l pins.h file im back up and running
on the latest bugfix branch.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#11179 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AI4NBGOQR6RWZQP32HWJEV3PTPAVPANCNFSM4FH2YQMQ>
.
|
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
I recently downloaded the latest bugfix branch today. I changed all settings to mimic what i was already using.. I had tmc 2130 drivers working perfectly with sensorless homing and everything. Now when i try to compile i get this error:
SENSORLESS_HOMING requires X_MIN_ENDSTOP_INVERTING and ENDSTOPPULLUP_XMIN when homing to X_MIN
I understand why its saying this, but i never needed to invert my endstops before, nor did I ever change these settings in any previous version of bugfix. I changed the settings it says to until the error went away but now i cannot get my x or y axis to move at all. I really dont know where to start here, as i have made this configuration setting for setting exactly as my old firmware, and now nothing works.
The text was updated successfully, but these errors were encountered: