›

X axis randomly stops near top of prints. Happens on multiple printers randomly.

ryane3pryane3p
in Repetier-Server
I'm having an issue where the X axis stops moving and goes into disabled mode (meaning it can move freely by hand). This happens randomly on prints on different printers. Meaning, that if I take one gcode file (called A), and print it on printer 1, it would print fine sometimes. Other times, it the X axis will stop moving near the top, but the extruder motor and Y/Z axis will keep moving (dispensing filament and causing buildup and a potentially destroyed heat block and cartridge/thermistor from being covered in build up, and wasting a LOT of filament on longer prints). 

This does not happen when printing from the SD card, and when printing from Repetier, is very random. I am using Server version 1.2.0 on a Linux machine (i7 16GB RAM), and the logs show that the X axis move commands, but it does not move at all after it disables. This happens on longer prints and shorter prints, and on multiple printers (Ender 5 Plus, Ender 5 Pro, CR10v3, etc), all using different firmware (some made by me, others made by someone else). The wiring is fine, since without power cycling the printer, if I go to move the axis using the screen commands, it responds just fine. There are no communication drops in the log

This started happening around the beginning of November, and no other hardware or software changes have been performed otherwise. The motors are not overheating (the room temp is 65F), the wiring is fine (motors respond to control commands), and it does not happen with SD cards. Is there any troubleshooting I can do to figure this out?

Comments

  • RepetierRepetier
    Actually never heard about that a problem. Just to recap you are sending gcodes containing x and y positions and firmware takes them, but decides to ignore x axis but executes the other parts?

    First I would enable logging and also enable echo commands for debugging to see what marlin thinks it got.
    M111 S7
    should do the trick.

    Now if marlin says it got X position but does not move it is a marlin problem. 
    Do you have any idea what can cause marlin to ignore it?

    Would M18 X0
    https://marlinfw.org/docs/gcode/M018.html
    be able to do so? What happens if you have a x move outside allowed area - is it ignored or does it stop.

    My guess is that some command gets received with com error causing marlin to do that. On the other side all lines have checksums so marlin should request a resend on errors.

    When you see the timestamp when it happens with logging enabled you can check the communication around that to see any anomality and sepcial output from Marlin that would give a hint.

    Only hardware related issue I can think of is a hot driver, but that would get cold and also happen on sd card with same file.

  • ryane3pryane3p
    Thanks admin. I actually had the print fail from the SD card for the first time yesterday on one of the printers, so I think you are 100% correct the issue is a hot driver. I took the printer down from the shelf, and discovered that the mainboard cooling fan is only turning on with the parts cooling fan. I decided to wire it directly to the 24V mainboard input to draw directly from the power supply when the unit was turned on. I am going to check into the rest of the devices to see if root cause is the same there. If so, you definitely pointed me in the right direction of the culprit, thanks!
  • ryane3pryane3p
    Well, I made the improvements to the hardware, even adding a couple of directed 5015 fans to really cool down the driver. On one printer, I even swapped to a brand new replacement 4.2.7 board, and it still happened. 

    I'm not sure what the cause of the problem is, but this only started happening when I started using Prusa Slicer. That is the only thing I can think of that I changed. All the printers exhibiting this problem have been running fine for the last 2 years, and all of a sudden, they all started showing the same exact problem, and the only change I made was moving to Prusa. There could be a setting in Prusa that is overriding a firmware machine limit maybe, but for the time being, I'm going back to Cura, as that has been working fine for years.
  • RepetierRepetier
    When using marlin as firmware there is an option that adds command to change acceleration and some other things that you can disable to use factory defaults, just in case it comes from that. Apart from that there are just moves so nothing changing firmware behaviour.
  • ryane3pryane3p
    Just to add some final notes on this, the issue was with the slicer. It appears that it was overriding firmware settings which was causing the issue. I never bothered digging in to determine which ones, but as soon as I went back to Cura, the issue 100% stopped.
Sign In or Register to comment.