Spider 3.0 Stepper Stuttering on Power Up #148
Comments
|
I've seen this if I reboot my pad 7 and it sometimes did it till it was reconnected to by the pad 7. As if when the brain stops talking to it and the board is sent a reset signal , or if the power to the mainboard is on before your host MCU it will do it till the host MCU starts talking to the Klipper firmware on the board. Haven't found a resolution but I don't think it's the PSU |
That would be a horrible thing to need to fix with hardware on a mainboard, should be a feature in the board to wait for the host to speak to the board before any feedback goes over those lines.. could cause injury or damage to steppers if something dumb happens? In hardware obviously we use contactors and relays in series to control each component powering up, and if a link is down there is no power to the servos/steppers.. and this wasn't really an issue that I recall on the previous spider boards so maybe I will investigate the schematic more and see what's different on those lines. |
|
I look forward to your findings then as I think it would be partially software initiated. As I did do a few tests with Marlin and never saw this trait before moving it to Klipper |
With the holidays I will probably take a little bit, and it's still early for the 3.0 board so we are lonely still lol; but since it's shipping now I am sure we will have more things pop up. The disconnecting of moonraker/mainsail due to the hardware acting up is just my main headache right now. Also, this issue could tie into the fact that sometimes after already having done a print, or just sitting for several hours powered on will cause my X axis to home in the wrong direction for absolutely no reason. I have to hard power cycle the mains switch, and then re-home and it's the correct direction once again. I do use sensorless, and it all works great but sometimes this is a damn headache to cycle power on it. |
|
Tbh I use endstop switches, I leave the printer on all the time even just
idle. Kind of a burn in test. Never had it disconnect yet so can't comment
…On Fri, 22 Dec 2023, 01:29 Print3DWorld, ***@***.***> wrote:
I look forward to your findings then as I think it would be partially
software initiated. As I did do a few tests with Marlin and never saw this
trait before moving it to Klipper
With the holidays I will probably take a little bit, and it's still early
for the 3.0 board so we are lonely still lol; but since it's shipping now I
am sure we will have more things pop up.
The disconnecting of moonraker/mainsail due to the hardware acting up is
just my main headache right now. Also, this issue could tie into the fact
that sometimes after already having done a print, or just sitting for
several hours powered on will cause my X axis to home in the wrong
direction for absolutely no reason.
I have to hard power cycle the mains switch, and then re-home and it's the
correct direction once again. I do use sensorless, and it all works great
but sometimes this is a damn headache to cycle power on it.
—
Reply to this email directly, view it on GitHub
<#148 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGBRFDQYAQYI4B52XUN6VTDYKTO67AVCNFSM6AAAAABA7EWXSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRXGEYTQNBTHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
i am facing the same issue, seems like the stuttering is mostly on the A and B motor ports |
|
I've had it with z motors as well but it's not consistent
…On Fri, 19 Jan 2024, 07:21 freezir12, ***@***.***> wrote:
i am facing the same issue, seems like the stuttering is mostly on the A
and B motor ports
—
Reply to this email directly, view it on GitHub
<#148 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGBRFDVUJWP7XM3LU2W4T33YPINIZAVCNFSM6AAAAABA7EWXSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJZHA4TENRZHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Just as an add-on point if you disconnect the USB cable and power on just the printer without the pi obviously being connected I have seen this trait and in some cases it affected both z motors as well as a and b. Almost as if they were being randomly stepped mainly in one direction. Still unsure of the cause but with a marlin firmware on the board it never seemed to do this so I'd have to guess it's something about the way the drivers act at that point |
|
I am having the same issue, and it is really bad on both M0 and M1. I build a Voron Trident and my A & B motors are forcing itself in a homing direction that eventually crashes the motors after a power on. Fysetc needs to come up with a fix for this, otherwise I will be forced to dump this board and move on to another manufacturer. Really sad, since everything else has been solid. |
Maybe Check the slots seperately. For me having M1 connected caused the same unusable style of stuttering towards the homing position. When not connecting the 'faultiest' channel it became usable and only shortly stutters on powerup (what others here describe). The severity has also decreased with time over the last two months. |
|
I checked all my wiring and removed the wire that came with the jumper for M0 and 1 (24v to 48v), it also seemed a little loose. I replaced it with a solid core wire and now the stuttering is gone completely. |
|
I have to admit I do think you are right with regard to connection if
anything as mine started finally doing it again I thought it was a software
change I made a while back. So I wiggled the connector still the original
wire and it has stopped doing it. Think I'm going to redo the connector on
it and maybe trip a little soldering because whether it's solid wire or
it's stranded wire should not matter but connect to the pins will be the
big thing
…On Tue, 12 Mar 2024, 03:42 KenBob, ***@***.***> wrote:
I checked all my wiring and removed the wire that came with the jumper for
M0 and 1 (24v to 48v), it also seemed a little loose. I replaced it with a
solid core wire and now the stuttering is gone completely.
—
Reply to this email directly, view it on GitHub
<#148 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGBRFDUFKB723CIX7JZFBFLYX2BUBAVCNFSM6AAAAABA7EWXSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJQGA4TGMRZG4>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Also have this issue, tried to replace the AB motor power jumper but no luck, still does it. my current speculation is, that when you start up you will draw a lot of power to lock all the motors. when these motors lock the capacitors for these drivers get drained, this is worse for the A B motors as they use the 24v to 48v jumper which adds resistance, just enough that those caps cant keep up as the others all have a higher priority. (idfk not like ive done EE, pure speculation) im going to try wire my psu directly to the A B motor input voltage and see if they are happier. |
|
Ok, for some reason the board just needs to be flashed with all of the EN pins pulled high.
super weird. but that actually stopped this behaviour. im not sure how people have had success with just doing something to the power jumping connector Pins to set |
|
Wow interesting find. I'll give this a try as issue came back over long time but other times doesn't do it. |
|
I can confirm enabling the Ean pins works |
Having some weird power-up issues now when the printer sits for awhile the mainsail won't connect any more, and when I go to power-cycle the steppers are buzzing on the start-up for awhile before settling down. Almost like the pi and board are giving some feedback during power-up. Anyone else have this or ideas?
The text was updated successfully, but these errors were encountered: