New problem: Far side Z motor skips/even reverses when commanded upward

LowRider CNC Troubleshooting
1

Hi, all. I’ve been reading through the troubleshooting posts, and have some ideas I can try, but could use some advice.

My LR uses an SKR 1.3 with TMC5160 drivers and the dual endstop binary compiled by @nightlink. I’m using that firmware as is, since I couldn’t manage to compile it on my own. I have not made any Vref adjustments.

A few days ago, I tried my first cuts on plywood, and at one point the router really dug in deep on the far side of the workpiece. I noticed that the flexible coupler for that Z motor was sprung/stretched afterwards. Maybe that was the beginning of my problem.

I’ve attached videos below, to illustrate what’s happening. It’s intermittent, but happens more often than not. The far side Z motor seems to miss steps, and even sometimes turn the other direction, when I am raising the gantry. This can happen at either 1 mm/sec or 10 mm/sec, and seems to happen somewhere in the range of about 20 mm from the home position. In one of the videos, you can hear that the motor seems to struggle/skip even when going down.

The gantry falls on its own with power off. The leadscrews are lubricated, and the leadscrew on the far side is nice and straight. The leadscrew and motor turn very freely in that trouble spot with the power off. Grub screws are tight. Leadnuts are loosened. I know that the XZ Main does not sit flat. I’ve read @barry99705’s posts about correcting that, but could not grok his instructions for loosening and twisting components, so I just shimmed the endstop switch on the near side so that both XZ Mains sit the same, small distance above the YZ rollers when homed.

Of course, all of this is happening just as my middle son is getting ready to move into his college apartment and has asked me to make him some flat pack furniture…

I’ve seen mentions of adjusting the max feedrates for the Z motors, but not sure if that’s my problem. thanks for reading this far. Here are some videos of the issue:

https://www.youtube.com/watch?v=hVaa43lXpT4

https://www.youtube.com/watch?v=SeptKkfg4fE

https://www.youtube.com/watch?v=XFtnShiQeVE

https://www.youtube.com/watch?v=udkbraHW6Bs

https://www.youtube.com/watch?v=cOBQKAP5Kw4

https://www.youtube.com/watch?v=-CdqstO12M8

2

Those videos are helpful. You can tell from the sound that it is skipping steps.

Are the 5160s talking to the skr? Some TMCs can operate in standalone mode, where the little trim pots are how you set the current. If these are properly talking to the firmware, then the firmware just sends the right amount over the SPI interface to tell the driver what to set it to. Sending an M122 can tell you a lot, and if you can get that feedback, put it here and I will explain it. If they are in standalone mode, then you have to adjust the pots or there’s no telling what they are set to. It is also possible that the firmware has set the values too low. Too low is skipped steps. Too high is overheating. On the TMCs, if they overheat, they can also turn down the current on their own…

Another issue might be an intermittent wiring connection. The motors never fail, but the wires often do. If you do have the skr talking to the 5160s, they can actually tell you if you have an open coil. At the bottom of the return from M122, there are rows for ola and olb. If there are Xs, it’s because the TMCs remember having “open loop on a” or “open loop on b”. s2ga is short to ground a. You can run a few up and downs, get it to skip, and then send M122 in the next minute or so and it will tell you if it detected a wiring problem. If it was really intermittent, like just touching enough to increase the resistance, it might not trigger the fault.

You will always benefit from the tubes going as smooth as possible though. So you should also try to figure out the misalignment of the tubing that is keeping it from laying flat. I think what Barry was writing (without remembering the post) is that the top tubes might have a twist in them, and if you loosen those holders enough for them to rotate in place, it can release the internal twist and let the gantry sit flat.

3

Thanks for your reply!

The motor drivers I have don’t have any trim pots on them. They are set up with one of their pins bent back per the advice of others here and, if I recall correctly, 4 jumpers in place underneath each driver.

Here are the results after the motor skipped pretty badly going up in 1mm increments.

ZProblem
ZProblem575×981 151 KB

By “top tubes,” do you mean the X axis tubes or the Z axis tubes?

Thanks again for taking the time to help me.

Bill

4

X axis. The big ones.

That M122 looks pretty good. Unfortunately. The stallguard having Xs on the two Z motors is intriguing. Sensorless homing isn’t enabled, is it? Or maybe that is just related to the fact that only those two motors are enabled.

I see stealthchop is enabled. Probably don’t want that. But you’d have to compile new code to turn that off.

The current looks ok. Although it could be a little higher, 850 or 900. I think you can set that with a Gcode.

5

M906:

I’m not sure how it would work with Z2, it might be E1, or Z2, or Z.

1 Like
6

Thank you. I’ll give that a shot.

7

If you switch the motor leads between the drivers (with the board powered off) does the problem switch sides?

8

Good question. I should see if it follows the motor or the driver. I’ll try that later.

9

Yeah, that’s giving me trouble. I can set Z, but that only seems to set the current for one motor on the axis. If try Z2, the “2” gets interpreted as part of the desired current value, so I get a current of 2900 on Z (or, if I include a space “M906 Z2 900” I get a current of 2 on Z). E1 doesn’t work, either, though that’s where Z2 is connected. Not sure how to set the current for both motors on the Z axis, as just specifying “Z” doesn’t do it, though from what I’ve read, it should. Any suggestions?

10

Sounds like the gcode interpreter isn’t matched to the task. You can change the value in the source code and reflash.

11

OK, thank you. I used a pre-compiled binary the first time around, because the source code from TeachingTech had some kind of error. Here’s hoping that there is some updated, dual endstop firmware for the SKR1.3 available out there now…

12

There are. You can download some “pre-release” zips from the new Marlin Builder. It doesn’t have 5160 set, but you’ll need to compile it yourself anyway, so that is an easy fix.

1 Like
13

Thanks! I’ll give it a shot.

14

Thanks again for your help. I have one of the zips downloaded and the project open in Atom. Since I’m not really familiar with this, I hope you won’t mind four last questions:

  1. Am I correct in assuming that I simply change from the 2209 drivers to the 5160s in configuration.h, or does it need to be 5160_Standalone?
  2. I have a Makerbase TFT28 touchscreen. Is there anything I have to modify to use that?
  3. On my machine, the current firmware homes to what I guess would be the top LEFT corner, even though the gantry travels Y+ and X- to get there. Fortunately, the precompiled binary I found just worked. Where would I look in this project to make sure that’s how the new firmware will work. And if it won’t, what would I change?
  4. Finally, the reason for all this in the first place… where do I set the motor current?

I’ll try not to bother you after this!

15
  1. The standalone is when the driver is set up to work without the spi feedback. So, it should be 5160.
  2. Dunno. But I assume it is already set up because it just talks over serial port.
  3. This firmware homes to -Y, -X. But feel free to change it.
  4. In configuration_adv.h. If you search for “current”, you should find only one option active.

Bother me as much as you want. This is how I keep my brain occupied while waiting around for something better to do.

I don’t keep tabs on the current state of things, but vs code was preferred at one point over atom. They are both platformio, and I’m not sure why they care, but I know the marlin devs all use vscode, so I use vscode (in linux).

16

I really do appreciate it. I should show you my 6DOF motion simulator, which also decided to give me grief this week. With all of my failures, I’m sure I could singlehandedly keep your brain occupied. :roll_eyes:

I’ll give this a go with Atom, since I have it set up. If I flame out, I’ll try vscode.

1 Like
17

I’m sorry. I thought I had this, but my attempts to compile the firmware with platformio in Atom are failing. I tried VSCode, as well, but it was even worse. Initially, I was getting a “nothing to build” error, but I got around that by moving the platformio.ini file, and all the files in the Marlin folder into one place. Then the compiling started out promising, but failed with the following errors. Are you familiar enough with this to point me in the right direction to figure out the errors?

First, it gives me multiple iterations of the following, each time referencing a different .cpp file (I’m only including one example for brevity):

In file included from Marlin\src\HAL\LPC1768…/…/core/…/inc/MarlinConfig.h:41,

             from Marlin\src\HAL\LPC1768\../../core/serial.h:24,

             from Marlin\src\HAL\LPC1768\DebugMonitor.cpp:25:

Marlin\src\HAL\LPC1768…/…/core/…/inc/SanityCheck.h:1348:6: error: #error "Z_SAFE_HOMING is recommended when homing with a probe. Enable it or comment

out this line to continue."

1348 | #error “Z_SAFE_HOMING is recommended when homing with a probe. Enable it or comment out this line to continue.”

  |      ^~~~~

Then, it gives me these, just before stopping with a “Failed” message:

*** [.pio\build\LPC1768\src\src\HAL\LPC1768\DebugMonitor.cpp.o] Error 1

Compiling .pio\build\LPC1768\src\src\HAL\LPC1768\include\i2c_util.c.o

*** [.pio\build\LPC1768\src\src\HAL\LPC1768\HAL.cpp.o] Error 1

*** [.pio\build\LPC1768\src\src\HAL\LPC1768\HAL_SPI.cpp.o] Error 1

*** [.pio\build\LPC1768\src\src\HAL\LPC1768\eeprom_sdcard.cpp.o] Error 1

*** [.pio\build\LPC1768\src\src\HAL\LPC1768\eeprom_wired.cpp.o] Error 1

*** [.pio\build\LPC1768\src\src\HAL\LPC1768\eeprom_flash.cpp.o] Error 1

18

Those zips were compiled using platformio or they wouldn’t have been zipped. You shouldn’t have to move the files at all, but I’m struggling to figure out how that could have affected this error.

Are you sure this is the first error?

This looks like an error in the sanity checks, which are there to check the configuration for errors. I don’t know how that could have been ok when it was zipped, and broken now.

I am wondering if you’re somehow not opening the project correctly in platformio or not using the right compile button.

https://docs.v1engineering.com/learn/platformio/

What I would suggest is to not change anything in the zip because we know it compiled before. Once it compiles, change one thing at a time.

19

OK, thanks. Got it to compile as originally zipped using VSCode. Must be something wrong with the way I have Atom/Platformio set up.

The change that seems to trigger those sanity check errors is the one I made trying to ensure that my gantry will home to the top left of my table. That means moving Y+ and X-. I changed the following, thinking that it would tell the steppers which way to move when homing, but maybe I misunderstood:

#define X_HOME_DIR -1 (I left this alone)

#define Y_HOME_DIR -1 (I changed this to +1)

#define Z_HOME_DIR +1 (I also changed this to -1, thinking that it would move Z down to the Y roller, but this is what messed things up).

20

Well, sadly, with the new firmware flashed (at least as confirmed by the file on the SD card being renamed from .bin to .cur), my touchscreen no longer works, and I can’t connect via Pronterface. Probably something I did wrong. :persevere: