Are you involved in this project?
I can see there is a socket for putting in different stepper motor driver modules.
You didn’t answer my question on how you are powering the toolhead and what the wiring looks like.
Are you involved in this project?
I can see there is a socket for putting in different stepper motor driver modules.
You didn’t answer my question on how you are powering the toolhead and what the wiring looks like.
Ah sorry,
Yes I made that project.
The USB-Source is here:
The cable is a 1m 100W PD-Cable with E-Marker.
I think it’s from Anker, but I’m not sure.
I think you need to have somebody review your design and layout who’s experienced in this type of circuit. What you’re doing here is not trivial and will require somebody to do a deep dive into the design - especially in regards to the power supply and the TPS25740B.
Just after a cursory look, you’re light on the stepper motor capacitance - TMC states:
You have 50μF.
If you look at commercial boards that have sockets for the stepper motor driver module, they typically have a 100μF electrolytic capacitor that fits between the two 8 pin header sockets:
There are a number of other areas that I think need to be reviewed, especially in regards to the USB 3 power specification in regards to changing loads. I’d be surprised if the specification was written with changing inductive loads (ie stepper motors) in mind which could be why you’re seeing so much noise/ripple.
It’s an interesting project and I wish you luck but I think you need to get a second eye looking at what you’re doing to get an idea of what’s happening here.
the 100uF low ESR cap is in the first schematic Sheet, top left (C10, low ESR SMD Alumina-Cap)
Plus the additional 50uF you already spotted.
The reason why the 100uF cap is not directly inbetween the driver is space constraint. Space is actually one of the hardest constraints in this project.
I am a electrotechnical engineer, but on this project I’m completely on my own. Reviewers for OpenSource Projects are very hard to come by.
You are free to make reviews, I’d actually be glad if I have another person looking at it.
Be aware that I designed this circuitry over a year ago, so I do not have everything in my head right away
The USB-C Specification is definitely not specified for switching Inductive loads, but that’s nothing I can change now
After for like 4h now, I think I finally found the source of that ripple.
First of all, idk why, but I got a whole lot of cap-values wrong for the buck-converters on the toolhead, all fixed for now.
However that would not be the actual problem.
Turns out, the PD-Supplying buck-converter has a relatively bad transient response which I’m in the process of fixing. A simple ferrite around the USB-Cable going into the toolhead reduced the measured voltage ripple under full toolhead load from ±700mV to ±100mV for now, I’m aiming for even better response with some snubber circuitry around the feedback pins.
Over various improvements, I reduced the voltage noise from ±700mV to about ±200mV Ripple now.
I also checked thoroughly with my scope for the mentioned 1V/us voltage transients in the TMC2130 Datasheet. AFAIK I’m well below that transient.
Still no luck, the error persists.
It only happens on specific prints though, not all prints are prone to that failure.
But if a print fails with OLA/OLB than its consitent.
Not always on the same Layer, but always in that print.
If a print is “good” I can print it over and over again, no problems.
For example:
This Fails:
this fails not:
The Print time and the amount of objects printed simultaniously does not affect if its “good” or not.
I have this for quite some time now and I can’t seem to find a pattern what works and what works not.
Unfortunately, I don’t have any hard advice to offer. One thing I noticed, though, is that you seem to be using tmc2130 drivers with stealthchop enabled. These old tmc drivers did not have a very good implementation of stealthchop and they were prone to strange errors. In particular, your description of certain prints reliably failing while other prints reliably succeed is reminiscent of reports we used to get with stealthchop.
As a test, you might want to try using spreadcycle instead of stealthchop and just check if the problem persists.
Maybe that helps a little,
-Kevin
Oh, thats a very good point!
thank you I’ll try that out!
Edit: sadly it did not work.
I grabbed some fysetc TMC2209 (which have a stupid pinout compared to anything else I’ve seen around) but got it working with UART communication.
I’ll now try with these “newer” drivers if they spit out a different error or do not error-out at all.