Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spider 3.0 Stepper Stuttering on Power Up #148

Open
Print3DWorld opened this issue Dec 22, 2023 · 16 comments
Open

Spider 3.0 Stepper Stuttering on Power Up #148

Print3DWorld opened this issue Dec 22, 2023 · 16 comments

Comments

@Print3DWorld
Copy link

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
Copy link

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
Copy link
Author

Print3DWorld commented Dec 22, 2023

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
Copy link

cyberjak2k commented Dec 22, 2023

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
Copy link
Author

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
Copy link

cyberjak2k commented Dec 22, 2023 via email

@freezir12
Copy link

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

@cyberjak2k
Copy link

cyberjak2k commented Jan 19, 2024 via email

@cyberjak2k
Copy link

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
Copy link

kengeer commented Mar 11, 2024

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
Copy link

mirakct commented Mar 11, 2024

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
Copy link

kengeer commented Mar 12, 2024

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
Copy link

cyberjak2k commented Mar 13, 2024 via email

@Altirix
Copy link

Altirix commented Jun 14, 2024

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
Copy link

Altirix commented Jun 15, 2024

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
Copy link

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

@cyberjak2k
Copy link

I can confirm enabling the Ean pins works

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants