search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.28k stars 19.23k forks source link

latest bugfix branch breaks tmc 2130 #11179

Closed wbarber69 closed 6 years ago

wbarber69 commented 6 years ago

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.

wbarber69 commented 6 years ago

I added my two builds, one works the other does not. remove the .txt and unrar

error-6-1-18.rar.txt working-4-21-18.rar.txt

wbarber69 commented 6 years ago

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.

wbarber69 commented 6 years ago

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

thinkyhead commented 6 years ago
wbarber69 commented 6 years ago

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:

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://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 threadhttps://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.

marcio-ao commented 6 years ago

@wbarber69: Could it be related to this change. That change was done because the default configuration was dangerous to some boards.

joseandres42 commented 6 years ago

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: Marlin-bugfix-2.0.x-2018-03-14.tar.gz This is my new build: Marlin-bugfix-2.0.x-2018-07-13.tar.gz Removing the SENSORLESS_HOMING section from SanityCheck.h will let it compile, but one axis gets stuck in TRIGGERED state. Also, I'm using a modified RAMPS 1.4 board so I edited the pins_RAMPS.h file. Thank you :)

wbarber69 commented 6 years ago

Yeah as was pointed out before. There was a safety issue or something with the way all this was handled before. You now need to invert whatever you had before.

Sent from my iPhone

On Jul 13, 2018, at 3:59 PM, joseandres42 notifications@github.com<mailto:notifications@github.com> wrote:

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: Marlin-bugfix-2.0.x-2018-03-14.tar.gzhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMarlinFirmware%2FMarlin%2Ffiles%2F2194148%2FMarlin-bugfix-2.0.x-2018-03-14.tar.gz&data=02%7C01%7C%7C3197fe42e8b64d20fc2308d5e9038604%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636671123694792197&sdata=QbpOV2S%2F6lq0vYVAqXEQ4dNeS%2Fq7%2BK%2FAu%2F%2FHzUpeOPU%3D&reserved=0 This is my new build: Marlin-bugfix-2.0.x-2018-07-13.tar.gzhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMarlinFirmware%2FMarlin%2Ffiles%2F2194158%2FMarlin-bugfix-2.0.x-2018-07-13.tar.gz&data=02%7C01%7C%7C3197fe42e8b64d20fc2308d5e9038604%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636671123694802196&sdata=yv21CcXDC7a1aL%2FKTmHicE152d%2BH2rPNJ%2FhL7AmOPrc%3D&reserved=0 Removing the SENSORLESS_HOMING section from SanityCheck.h will let it compile, but one axis gets stuck in TRIGGERED state. Also, I'm using a modified RAMPS 1.4 board so I edited the pins_RAMPS.h file. Thank you :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMarlinFirmware%2FMarlin%2Fissues%2F11179%23issuecomment-404952565&data=02%7C01%7C%7C3197fe42e8b64d20fc2308d5e9038604%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636671123694812201&sdata=sa3SFN6OKQaaF%2B1jWRg9JIZsVQczpx06tyzxZ7LG6Yk%3D&reserved=0, or mute the threadhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAB7M2oM1aF8TVo2ty9xiK3aUizsU9po2ks5uGQovgaJpZM4U-sQZ&data=02%7C01%7C%7C3197fe42e8b64d20fc2308d5e9038604%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636671123694832217&sdata=t5V%2B32cULDq4mV8YcB0t7sV%2F%2ByAQ5aq1BxwXfrvVlko%3D&reserved=0.

joseandres42 commented 6 years ago

That was the first thing I tried, but if I invert what I had I get the X axis stuck in triggered: Send: M119 Recv: Reporting endstop status Recv: x_min: TRIGGERED Recv: y_min: open Recv: z_min: open I'm using sensorless homing in both X and Y axes.

wbarber69 commented 6 years ago

Are you using sensorless homing on the x axis? And do you have endstop pull-ups enabled?

Sent from my iPhone

On Jul 14, 2018, at 2:11 PM, joseandres42 notifications@github.com<mailto:notifications@github.com> wrote:

That was the first thing I tried, but if I invert what I had I get the X axis stuck in triggered: Send: M119 Recv: Reporting endstop status Recv: x_min: TRIGGERED Recv: y_min: open Recv: z_min: open

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMarlinFirmware%2FMarlin%2Fissues%2F11179%23issuecomment-405043746&data=02%7C01%7C%7Cce0628b66f3d4cec1d4808d5e9bd95ed%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636671922835281740&sdata=W5q93b58zu%2B2jHRllVeJFfqFkIGCw4cJ0PO722mdtIM%3D&reserved=0, or mute the threadhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAB7M2sg0DsLc6J0NlWcLDTiXgoFSallaks5uGkJZgaJpZM4U-sQZ&data=02%7C01%7C%7Cce0628b66f3d4cec1d4808d5e9bd95ed%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636671922835281740&sdata=6n%2FHH%2BmaIjD2mzKN0g8XG7l%2BctAPiLfSNTcpiYLDFb8%3D&reserved=0.

joseandres42 commented 6 years ago

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.

wbarber69 commented 6 years ago

Does the x axis and y axis have the same setting?

Sent from my iPhone

On Jul 14, 2018, at 7:16 PM, joseandres42 notifications@github.com<mailto:notifications@github.com> wrote:

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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMarlinFirmware%2FMarlin%2Fissues%2F11179%23issuecomment-405058125&data=02%7C01%7C%7Cf1507353631341533d1008d5e9e824be%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636672105607517844&sdata=mEmCyK1C%2BOtZCrC7nPwFlSN6YZ4lcRlyXL%2FMgAimEKQ%3D&reserved=0, or mute the threadhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAB7M2uI5IZaGHK6NDBJY_ADzGy6BAalrks5uGom_gaJpZM4U-sQZ&data=02%7C01%7C%7Cf1507353631341533d1008d5e9e824be%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636672105607517844&sdata=U5JCocz61SJxUkYBB2h%2Babre8ff9U1%2Fo8DOJN9ZNhcA%3D&reserved=0.

joseandres42 commented 6 years ago

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: Recv: been triggered false false false false

wbarber69 commented 6 years ago

Did the wire come loose?

Sent from my iPhone

On Jul 15, 2018, at 4:58 AM, joseandres42 notifications@github.com<mailto:notifications@github.com> wrote:

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: Recv: been triggered false false false false

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMarlinFirmware%2FMarlin%2Fissues%2F11179%23issuecomment-405080124&data=02%7C01%7C%7C6a4fe84de4a240495dbe08d5ea39811a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636672455051762019&sdata=01YI85ypS8g5PaPDs4WycNHTlmkEdXCg4dVj2QWhbgg%3D&reserved=0, or mute the threadhttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAB7M2qJBJr2Zs9-CCWxFCiuhKxXEgCwNks5uGxI_gaJpZM4U-sQZ&data=02%7C01%7C%7C6a4fe84de4a240495dbe08d5ea39811a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636672455051762019&sdata=j1TIIPv9ZxQ2WzA7UrOcWScPF1%2B8INiEn4gckhk18pA%3D&reserved=0.

thinkyhead commented 6 years ago

but the M122 says the TMCs didn't trigger

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.

wbarber69 commented 6 years ago

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 GitHubhttps://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 threadhttps://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.

joseandres42 commented 6 years ago

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.

seandop commented 6 years ago

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...

joseandres42 commented 6 years ago

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.

GibsDev commented 6 years ago

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.

wbarber69 commented 5 years ago

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.

RiRilot commented 5 years ago

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. I'm using the latest build of Marlin 2.0. Board is correctly defined as BIGTREE_V1_3

seandop commented 5 years ago

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 notifications@github.com 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 https://github.com/MarlinFirmware/Marlin/issues/11179#issuecomment-488934191, or mute the thread https://github.com/notifications/unsubscribe-auth/AI4NBGOQR6RWZQP32HWJEV3PTPAVPANCNFSM4FH2YQMQ .

github-actions[bot] commented 4 years ago

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.