1. Got a question or need help troubleshooting? Post to the troubleshooting forum or Search the forums!

Partially Solved Printer Skipping All Print Commands

Discussion in 'Troubleshooting' started by savan2, Jul 4, 2022.

  1. savan2

    savan2 New Member

    Joined:
    Jul 4, 2022
    Messages:
    4
    Likes Received:
    0
    Hi,

    I have an old R1 that I've recently gotten working again. Its an old Kickstarter R1 running Marlin 1.1.6 with a BLTouch for mesh leveling. I'm using an LCD controller with SD reader for input.

    It was working flawlessly for a while, but its become more finicky lately and now it wont print at all. It will run the commands built into the controller, but it skips all the move and print commands in the gcode. For example in the following code, it will get up to temp, auto home, mesh level and then sit there as the progress bar races to 100% and then decide the print is complete.

    Code:
    ;FLAVOR:Marlin
    ;TIME:258
    ;Filament used: 0.266462m
    ;Layer height: 0.3
    ;MINX:104.106
    ;MINY:114.196
    ;MINZ:0.4
    ;MAXX:120.894
    ;MAXY:130.805
    ;MAXZ:6.6
    ;Generated with Cura_SteamEngine 4.13.0
    M82 ;absolute extrusion mode
    M117 Getting up to temp!
    M140 S80.0 ; Set Heat Bed temperature
    M104 S270.0 ; Set Extruder temperature
    M109 S270.0 ; Wait for Extruder temperature
    M190 S80.0 ; Wait for Heat Bed temperature
    G28 ; Home all axes
    M117 Auto bed-level GO!
    G29 ; Auto bed-level (BL-Touch)
    G92 E0 ; Reset Extruder
    M565 Z0 ; Fixed Z offset at start
    G1 X0.1 Y20 Z0.3 F5000.0 ; move to start-line position
    M117 LET THE PURGE BEGIN!
    G1 X0.1 Y200.0 Z0.3 F1500.0 E15 ; draw 1st line
    G1 X0.4 Y200.0 Z0.3 F5000.0 ; move to side a little
    G1 X0.4 Y20 Z0.3 F1500.0 E30 ; draw 2nd line
    G92 E0 ; reset extruder
    G1 Z1.0 F3000 ; move z up little to prevent scratching of surface
    M117 Autobots! Roll Out!
    G92 E0
    G1 F3600 E-1
    ;LAYER_COUNT:20
    ;LAYER:0
    M107
    G1 F900 Z0.9
    ;MESH:20220703-Vol-Knob-Repair-Insert_v1.stl
    G0 F3272.7 X109.51 Y116.282 Z0.9
    ;TYPE:WALL-INNER
    G1 F900 Z0.4
    G1 F3600 E0
    G1 F900 X110.88 Y115.78 E0.11647
    G1 X112.5 Y115.591 E0.24666
    G1 X114.121 Y115.78 E0.37693
    G1 X115.489 Y116.282 E0.49325
    G1 X115.677 Y117.304 E0.5762
    G1 X115.752 Y117.491 E0.59229
    G1 X116.086 Y117.995 E0.64055
    G1 X115.912 Y117.931 E0.65535
    Etc...
    I've tried playing around with the start code thinking past me may have made a mistake in tweaking the prep-code, but stuff like changing the G1 to G0, or commenting out the M565, replacing the M82 with G90, Even skipping all the prep code and just diving right into the print commands... Nothing seems to be making a difference. It just refuses to print.

    I'm baffled, so any ideas would be appreciated,
    Thanks
     
  2. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,719
    Likes Received:
    7,326
    I would start by suggesting that you roll back to the stock firmware and test to rule out aything with that.
    If that does not help then go back to your modified version and we can troubleshoot that knowing that it is NOT related to the firmware rules out a lot.
     
  3. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,719
    Likes Received:
    7,326
    Whjile you are at it I would say try another slicer just as a data point and try ot using the Sd card as well -- drive the printer directly from the host program (at least then any errors will show up and let me know what they are).
     
  4. savan2

    savan2 New Member

    Joined:
    Jul 4, 2022
    Messages:
    4
    Likes Received:
    0
    Haven't tried changing the firmware yet, but I have tried switching to slic3r, which did not help.

    But I also tried skipping the SD card and it prints fine with Cura over USB.

    I'll try a different SD card to see if thats it, but since it worked for part of the process I'm starting to suspect its something to do with the LCD controller
     
  5. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,719
    Likes Received:
    7,326
    If the LCD controller is where the SD card reasder is then that is a very good thing to suspect. The original beta has an SD card hung off of the Arduino, but the R1+ should have had one on the LCD.
     
  6. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,719
    Likes Received:
    7,326
    On the plus side the LCD controllers are not very expensive if irt needs replacement.
     
  7. savan2

    savan2 New Member

    Joined:
    Jul 4, 2022
    Messages:
    4
    Likes Received:
    0
    The new controller arrived today and on my initial test everything worked as intended. Then on the second print (with the same g-code) it repeated the origional faulty behavior. The only oddity in between is that the BL-Touch seemed to be in a fault state which caused it to refuse to lower in Z height during the auto home. A reset resolved the lowering issue, but was then followed by the original faulty behavior.
     
  8. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,719
    Likes Received:
    7,326
    Have you tried printing directly from the host program on a PC? ... as a test.
     
  9. savan2

    savan2 New Member

    Joined:
    Jul 4, 2022
    Messages:
    4
    Likes Received:
    0
    Yes, I did test that and it was successful. That is what lead me to suspect the controller as the issue. But is infeasible as a long term solution. My printer is set up in a utility room at the far end of the house from my PC and I don't have a laptop I can use as a host. Originally I got the LCD controller because USB prints were failing mid way due to dropped connections, so I will need to find out whats causing this erroneous behavior. Theoretically I could set up an Octoprint server, but after replacing the LCD I'm not confident the issue wont persist.
     
  10. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,719
    Likes Received:
    7,326
    Octoprint is the best way to do remote printers (even if it doesn't impact your current problem)
    The Pi replaces the desktop unit driving the printer controller board.
    Worst case the LCD is not really expensive (under $30 if you dig around), but for me the best solution was OctoPrint. Being able to monitor/control your printers with a web browser is win. I have not actually used the LCD controllers since -- mind you they all have them since most of them predate my experience with OctoPi

    I'd suggest as well reloading the firmware on the printer (just reload whatever you are currently using). I would really NOT expect that to sort it, but it is quick and rules it out.
     

Share This Page