Strange Motor Controller Failures

dc42

@bpislife said in Strange Motor Controller Failures:

What I noticed is that the frequency across the two windings are off by about 600Hz. Is that supposed to be that way?

AFAIK that's entirely possible, because each winding has its own chopper. If you change the motor position a little, the frequencies will probably change a little.

It's probably best to use the 2 channels in differential mode so that you see the voltage across the stepper motor winding.

BPisLife

Ah good one. Let me try that and I will report back.

BPisLife

@dc42 Ok here is the output.

Across 2A/2B:

Across 1A/1B:

BPisLife

@bpislife I noticed that the square wave period never changes. On a good stepper driver as the motor moves the period adjusts. On the bad drivers the period remains the same even if I physically turn the motor manually while it tries to turn.

BPisLife

@bpislife
As a side note: I was able to run the motor no problem my plugging it into a port with a motor that was working. This definitely confirms there is something wrong with the drivers themselves or the hardware that supports it.

dc42

It does sound as though there is something wrong with the drivers, but it's a very odd fault. Does the mark-space ratio change if you vary the current using M906 or M913, or if you command the motor to move by very small amounts?

BPisLife

@dc42 no, speed doesn’t seem to matter. I changed current and also no change. I did adjust the steps/mm and the space between sqaure waves changed.

Edit: the still image doesn’t do it justice as it is very much a twitching unclean square wave so the controller at least appears to be trying to move but can’t. I won’t if the logic in the motor control burned out? Like I was saying before we did get a series of brown-outs/surge from a really bad storm. It’s odd that only the controllers with large motors survived. That said it was only this printer that had an issue. My other 3 have no problems.

BPisLife

This post is deleted!

BPisLife

@bpislife I also just realized that are it standard QFP with no thermal pad. I am going to replace the main driver ICs as those are a pretty straightforward board level repair if this isn’t covered under warranty (only a month old).

dc42

Let me see whether I can sort out a warranty repair or replacement. Which country are you in?

BPisLife

@dc42 USA, already reached out to Filastruder.

BPisLife

@bpislife Just to close this out, the warranty process is taking too long for me so I decided to replace the motor controllers on the Duex 5 first just to prove it was in fact the motor controllers (before I take on the DuetWifi).

Just to be clear that isn't a complaint at the warranty process but more my own impatience.

Replacing the motor controllers resolves the problem on the Duex 5 and I am sure it will resolve the issue on the DuetWifi also. 2 down 3 more to go. Will report back here once I replace the final 3.

dc42

Thanks for the update. This is a really strange fault, we've not seen anything like it before. The only way we've seen these stepper drivers fail before is open-circuit or short-circuit output mosfets. Very occasionally we've seen incorrect status reports that we suspect was caused by a bad soldered joint on one of the SPI pins.

BPisLife

@dc42 well after all that it worked for the duex5 but when I changed all on the duetwifi and ran the motor, I had to upgrade the wiring on the motor and when I turned the unit off and back on, all 5 MCs we’re toast. I fixed one MC in the duex5 again but it didn’t solve it this time.

Turns out that the solder joints on the Vin for the duex5 were cracked (ie connector loose) so I resoldered them but MCs are stil actng badly. I will attempt one more MC replacement. Strange that it worked now it’s not.

if this continues I will remove everything and go one at a time. I also plan on testing the power supply to make sure it is in fact functioning properly and not providing a power spike.

My thought on the MC is that the logic of the MC is getting cooked.

BPisLife

@dc42 Well this is embarrassing/hilarious/sad etc. see below.

The issue was the motor current (original M906 statement) and nothing at all to do with the drivers. No idea why it worked after replacing the drivers before then failing but whatever, it works now.

After going to the latest firmware (though downgrading back to 2.0 didn't fix it) the issue showed up as I descibed in this post. It dawned on me (light dawns over marble head) to just verify the M906 statement was read and behold this statement :

M906
Motor current (mA) - X:1000, Y:1000, Z:1000, E:0, idle factor 60%

Yup, must not be valid and to be honest, I don't remember where it came from, why it isn't valid, why it would work for a month then suddenly not work, but whatever the reason I don't need it.

M906 X1000 Y1000 Z1000 E1000:1000:1000:1000:1000:1000:1000:1000:1000 I60 ; Set motor currents (mA)

I changed it to just M906 X1000 Y1000 Z1000 E1000 and boom everything works.

So now that I spent time replacing 5 motor controllers for nothing, I can now say that I at least replaced them successfully, haha! If anyone ever needs it done, just PM me. I am IPC certified.

dc42

OK, I can see what happened. Prior to firmware 2.01, after allocating drivers to X, Y and Z all the remaining 9 drivers out of the possible 12 total used to default to extruders. This led to problems if you sent e.g. M350 E64 because drivers 10 and 11 are external drivers only, so 64x microstepping can't be applied to them by the firmware, resulting in an error message. So in firmware 2.01 I changed it so that only 7 drivers default to extruders. But I didn't reckon on anyone listing 9 extruder drives individually in M906!

I'll add an item in the upgrade notes.