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

[BUG] Unexpected and unwrited in Gcode trajectories on X or Y axes during printing. #780

Open
ThomaTheFrench opened this issue Aug 15, 2024 · 0 comments

Comments

@ThomaTheFrench
Copy link

Description

  • My printer is an Ender-3 V1 equiped with an BTT SKR mini E3 V3.0 with basic firmware + BTT TFT35 E3 V3.0 interface + BTT SFS V2.0 (connected to the motherboard) + BLTouch smart V3.1 (unconnected to the motherboard)

  • The firmware is in the basic version (I upgraded it with the one on Github to be sure) without sensor support (I used the basic software without sensor support, because I wanted to first print an adapter part for the BLTouch and then update the software to support the sensors).

  • THE BUG : At the start of a layer, during printing, a straigth trajectory not written in the Gcode occurs. This trajectory is done only on one axis (X or Y, it is random for each occurrence) up to the edge of the print area (evry time in positives coordonates) then returns to the starting point of the layer to continue as if nothing had happened. This happens 2 to 3 times for small prints (20x20mm and less than 1 hour).

Steps to reproduce

  1. Use the same configuration ( BTT SKR mini E3 V3.0 with basic firmware + BTT TFT35 E3 V3.0 interface + BTT SFS V2.0 (connected to the motherboard))
  2. Launch a print.
  3. Wait and observe.

Expected behavior

A normal print without random, unexpected and unwrited in Gcode trajectories.

Actual behavior

A print with random, unexpected and unwrited in Gcode trajectories.

Additional Information

I solved it : I unconnected the SFS V2.0 sensor from the motherboard. I supposed the signals from the sensor perturbate the motherboard (Probably, these signals was unexpected by the basic firmware).

It can be interesting to secure the firmware from unexpected signals on the non used and programmed I/O.

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

1 participant