After configuring their Marlin fork and adapting it to the MPCNC the basics worked ok. I spent quite a bit of time trying to get sensorless homing to work. In the end I managed to get it working, but homing is very harsh. The steppers take a couple of seconds (or more) to realize they hit the corner. I have often have to kind of push and/or pull the gantry a bit to make it stop homing. The steppers make an awful noise because they are essentially skipping steps and repeatedly crashing into the corners. This seems to be related to TMC2209 drivers, there is an open issue on Marlin’s github for this.
Then I had the problems I wrote about in this thread. During a move, the steppers would sometimes just disable themselves and loose all torque. At first I thought it was only the Z axis, but it happened on all axes. The Z stepper being disabled (even temporarily) is just more apparent (and more disastrous). I replaced the TMC2209’s with DRV8825’s I still had lying around and thought all my problems were solved.
Then I made a few semi-successful parts, but I noticed that some of the bearings were a bit loose. I guess that’s just part of breaking in the MPCNC. So I tightened everything up such that all bearings grip the stainless steel tubes (but not too tight). I double checked the belt tension, and made sure everything runs smoothly when I move the gantry by hand.
But then, when I just do a simple linear move (G1), sometimes one stepper looses synchronization with the stepper on the other side and the gantry is pulled out of square. Then the stepper that was still working starts skipping steps because there is a lot of friction when the gantry isn’t square anymore. This happened with the DRV8825’s, so it was not caused by possibly faulty TMC2209’s.
I then replaced the SKR Pro with an old RAMPS board, and used the same DRV8825’s. The problem no longer happens. Everything works fine. The steppers stay in sync and aren’t losing any steps.
On the SKR Pro I was using 5 drivers and I configured Marlin (or rather, the BigTreeTech fork of Marlin) to use dual X and Y steppers. On the RAMPS I used 3 drivers with Ryan’s MPCNC_Ramps_T8_16T_LCD_32step firmware.
Anyway, I’m going to stick with the RAMPS and ditch the SKR Pro. Still not sure what the actual root cause is, but it works now.
Yes I did try the SKR with DRV8825’s. With the TMC’s a whole axis seemed to fail at the same time. With the DRV8825 single steppers seemed to fail, so the gantry was pulled out of square. I was using 5 independent drivers on the SKR for both the TMC’s and the DRV’s.
I have not tried the TMC’s on another board. So while I first concluded that the TMC’s were problematic, it might have been just the SKR board the whole time.
Those boards and those drivers are still super new. Almost every day they are changing the firmware to try and get them to work fully. Just 2 days ago they added sensor less homing current on the new tri’s so it would not bash the ends so hard. Considering they still mess with the original trinamics I am not touching my 2209’s for a while. It’s a bummer but Marlin is moving so fast now a bunch of PRs are fixing things that broke days earlier. I think they are going to need some sort of system to slow it down a bit to save some work. It is both good and bad.
I would give that board and drivers a try in a month or two.
I dove into the source code a little when I was trying to get the sensorless homing to work correctly. While it’s is fairly tidy, Marlin is definitely a huge ball of spaghetti of #if’s and #define’s. It’s nearly impossible to understand how all configuration options affect the actual code that is being compiled. I understand they need to keep code size to a minimum, but it’s no wonder they break stuff that was working before or that newer things take a lot of time to get working properly.
Yeah. And the person working on the skr boards probably doesn’t have dual X and Y, so no one tests that config until it gets to you. There are so many forks and there is no way to test every combination of settings. I’m sure it’s very frustrating.
Facinating. Did you cool the board and drivers? If MONITOR_DRIVER_STATUS was enabled, did M911 report any overtemperature warnings from TMCs?
The symptom of losing all torque on a random stepper, especially with “dumb” drivers (DRV8825) sounds a lot like drivers tripping their overtemperature circuits and shutting down. It is my experience with this board that TMC2209 step sticks need forced air cooling to sustain even 1.6A. The same is true for DRV8825-s. RAMPS cover that Ryan has on thingiverse comes with a cooling fan slot for a reason.
I never used the bigtree fork. Here’s the last Marlin version I tested on this board, although not extensively:
I did not use forced aircooling, no. I did feel the steppers and the heatsinks of the drivers at various times, and they weren’t warm at all. It’s only 10 degrees C (50 F) in my garage. With the DRV’s, I also left them on (at standstill) for a while to see if they would get warmer, but they didn’t.
I did have MONITOR_DRIVER_STATUS enabled, but haven’t used M911.
It did cross my mind that overtemperature is a likely root cause. But on the RAMPS I used the same drivers under the same conditions without issues. So I just gave up and stuck to the RAMPS. If I go back to the SKR in the future I will definitely use forced cooling.
I did not think of the scenario where something on the SKR board is overheating. I did not try to feel the temperature of the chips. But it would be a pretty bad design issue if that would be the case I think.
Anttix, are you using the SKR Pro on an MPCNC? With Marlin? Or did you only do some testing and never used it in anger?
I used it for a few weeks but I had to give it back so I currently have a different board on my machine. I have ordered my own from Aliexpress but it’s at least two more weeks until it gets here.
This is super weird. Even at 10C the drivers should get noticeably warm. My DRV8825-s will get too hot to touch if I push 1.6A through them.
It gets pretty hot here in Texas in the summer, but it’s winter now and a week ago when I did my last tests with SKR Pro, there was a pleasant 25C in the garage. I saw thermal shutdown on DRV8825-s without forced cooling. TMCs are smarter and don’t get warm until they actually have to push the machine around. They did run cooler than DRVs to touch when under load but still generated overtemperature warnings. Marlin can reduce current and will log the condition if configured to do so.
EDIT: If the drivers are running cold maybe motors are not getting full current. I would check all the regular current knobs (software settings and trim pots) also SKR Pro has a separate power input for motors, may be worth checking the cables/connection to it.
My drivers/steppers weren’t stone cold, but just about luke warm I’d say. Nowhere near “too hot to touch”, but there was definitely current flowing through them. I had all drivers set to 800mA.
You can configure the holding current of a TMC at standstill as a percentage of max current. I tried changing that from 50% (the default) to 100% during the troubleshooting process, and even at 100% at standstill they were only getting luke warm.
I might try again at a later date, after I get some work done with the RAMPS and memories of the whole process fade a bit I’m a software engineer, and while some bugs in software can be hard to find, at least there are good tools for it (and I have a lot more experience). Problems with hardware are very frustrating in comparison… especially when compounded by complicated firmware such as Marlin that’s very hard to debug in real-time.
What steppers do you use? 800mA is pretty low for the fat 59Ncm steppers so you probably have smaller ones. I had a 42Ncm stepper on Z and it did start to lose steps and sink but only after I bumped speeds and accelerations well beyond MPCNC defaults. These may be worth checking if you did your own firmware config.
I would suspect wiring problems more than temperature with such a low current. Did you plug dupont connectors (the kind that steppers usually come with) straight into SKR Pro or did you make an adapter / new cables? The pins on JST connectors (the kind SKR boards use) are a lot shorter and only barely reach the metal inside of the dupont plug. Pressing the plug all the way to the bottom and securing with a dab of hot glue will work but replacing the connectors or making an adapter cable is recommended.
EDIT: On the other hand if you do have 59Nm steppers that only take 1A of current then these must be really high impedance ones. If you’re running at 12V then TMC-s can never drive these properly because back EMF is way too close to the supply voltage. This may actually be true for some 42Nm steppers as well. Reprapfirmware.org has an EMF calculator to check if supply voltage is adequate for the specific steppers.
The steppers are 4.2 Ncm. I used the default speeds. I also tried an extremely low Z plunge rate of 0.4 mm/s. The speeds and torque were not the problem. The steppers just stopped working and lost all holding torque. I don’t know if they would start working again after a little while, but cutting 20mm deep with the end mill rubbing on wood and making smoke did make me want to turn off the whole thing asap…
At first I indeed had dupont connectors, but I replaced them with the proper JST connectors and made sure the connection was good. I also hot-glued the connector to the stepper. Didn’t make any difference.
Interesting point about the TMC’s with 42Nm steppers! I had no idea. I’ll definitely keep this in mind if I use them on a future project (if any).
Approximate peak back EMF due to rotation per motor: 10.6 V at 120.0 mm/s
Approximate peak back EMF due to inductance per motor: 17.4 V at 120.0 mm/s
It gets worse at higher speeds, if I wanted to use these to drive a 3D printer with 16T pulleys at 200 mm/s, the supply voltage would have to be 30V or more
Thanks for the tip on the calculator. That’s great!
Also my MKS Gen L also has the JST XH connectors which are awful when trying to use with dupont connectors. I (apparently) toasted a motor driver a few days ago due to the barely viable connection with dupont connectors. Losing a motor driver is no big deal but not being able to trust the connection is no good. I’m going to have to make a little pigtail with a true JST connector.
So far I have not had any of the problems listed above. My sensor less homing is working well. The drivers stay in sync from front to back.
However, I have one huge problem. My SKR Pro 1.1 freezes (locks up) in the middle of a part. I’m working on trying to understand the problem better. I can not communicate to the SKR, but the motors are still holding torque. I’m forced to reset the controller.
I wanted to post this to let everybody know the SKR Pro 1.1 has problems… I’m suffering them now. I really like the price and flexability the controller has.
Also, the TFT35 display has bugs in the screen that prevent starting prints from the SD card on the SKR. I found ways of working around it. It should be just a firmware issue. I looked around and determined the problem is pretty deep in ether memory management or or library.
At the moment I’m dead in the water but I hope to solve these problems. If not, on to another controller.
Also, getting good firmware for the SKR Pro 1.1 is hard. I got lucky and found a branch that fixed the SDcard slot. I guess Big tree tech is slow to updating their branch. Most of the features on the board don’t work. Can’t use the USB, SDcard requires hard to find firmware fixes. Wifi seems to work though.
I just unplugged the TFT35 from my SKR Pro 1.1 and for the first time a large part didn’t lockup middle of the part. If this is the case, perhaps my SKR Pro 1.1 is working great and it just has an issue with the TFT port talking to the TFT35. Not sure what I’m going to do. I really like the TFT35 screens and it makes jog moves and setting home so easy.
I got my SKR Pro 1.1 and TFT35 3.0 Working finally. No problems. No more crashing. No more gantry running into the wall. If you need help let me know and I can share my source code. I will say that by default the SKR Pro 1.1 firmware has problems right out the gate unless you go to a 3rd party repository that already fixed the issues. Same goes with the TFT35 screen.
I’m a software engineer, and while some bugs in software can be hard to find, at least there are good tools for it (and I have a lot more experience). Problems with hardware are very frustrating in comparison… especially when compounded by complicated firmware such as Marlin that’s very hard to debug in real-time.