FYSETC / FYSETC-SPIDER

FYSETC Board - 3d printer motherboard for VORON and other open source project.
306 stars 147 forks source link

Spider 3.0 Stepper Stuttering on Power Up #148

Open Print3DWorld opened 7 months ago

Print3DWorld commented 7 months ago

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?

cyberjak2k commented 7 months ago

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

Print3DWorld commented 7 months ago

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.

cyberjak2k commented 7 months ago

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

Print3DWorld commented 7 months ago

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.

cyberjak2k commented 7 months ago

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 https://github.com/FYSETC/FYSETC-SPIDER/issues/148#issuecomment-1867118438, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGBRFDQYAQYI4B52XUN6VTDYKTO67AVCNFSM6AAAAABA7EWXSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRXGEYTQNBTHA . You are receiving this because you commented.Message ID: @.***>

freezir12 commented 6 months ago

i am facing the same issue, seems like the stuttering is mostly on the A and B motor ports

cyberjak2k commented 6 months ago

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 https://github.com/FYSETC/FYSETC-SPIDER/issues/148#issuecomment-1899892699, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGBRFDVUJWP7XM3LU2W4T33YPINIZAVCNFSM6AAAAABA7EWXSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJZHA4TENRZHE . You are receiving this because you commented.Message ID: @.***>

cyberjak2k commented 6 months ago

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

kengeer commented 4 months ago

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.

mirakct commented 4 months ago

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. Still a really bad move by fysetc to sell the boards in this state and not to acknowledge the problem (or did they?)

kengeer commented 4 months ago

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.

cyberjak2k commented 4 months ago

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 https://github.com/FYSETC/FYSETC-SPIDER/issues/148#issuecomment-1990093297, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGBRFDUFKB723CIX7JZFBFLYX2BUBAVCNFSM6AAAAABA7EWXSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJQGA4TGMRZG4 . You are receiving this because you commented.Message ID: @.***>

Altirix commented 1 month ago

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.

Altirix commented 1 month ago

Ok, for some reason the board just needs to be flashed with all of the EN pins pulled high.

Screenshot 2024-06-15 022902

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 PE9,PD9,PD15,PD4,PE5,PE3,PE8,PC5

cyberjak2k commented 1 month ago

Wow interesting find. I'll give this a try as issue came back over long time but other times doesn't do it.

cyberjak2k commented 4 weeks ago

I can confirm enabling the Ean pins works