Issues While Trying to Re-print My Umbrella Bracket

3d Printing / Slicers / Setup / Problems
1

I mentioned in a thread that my wife wants another pair of the umbrella brackets, to mount a 2nd umbrella to our deck railing. I ran into some issues: [LIST=1]

  • The 1st issue is the most bizarre. It was about 12 hours into the print of all 6 pieces (rear bracket, front bracket, 4 bolts) when, overnight, it suddenly stopped on top of one of the bolts. Everything was running (the printer is on a UPS), but nothing was happening. "Great", I thought, that's a bunch of wasted filament. The only difference between my normal printing and this one was that I copied the g-code file to the SD card and was printing from it, but I've printed from the SD card before without issue, so who knows.
  • I decided to go back to printing via USB from my old Microsoft Surface Pro, as I have been since early on in my testing/troubleshooting/calibrating phase.
  • I ran into a bit of an adhesion issue: not terrible, but annoying. One corner of the rear bracket, and 2 of the bolts, didn't adhere to the UHU stick as they do normally. I abandoned the print very early on. I applied a fresh layer of UHU and started again, but not until after I made some adjustments to Cura.
  • I have been concerned about the speed at which the bolts are printed, at least the initial layer. The heads of the bolts are knurled, which causes the hotend to be jerked back & forth pretty vigorously. I had also been curious about the "individual settings" button in the Cura Prepare window. I clicked on 1 of the bolts and then the button for the individual settings. In the search box I typed "initial" and was presented with a bunch of settings, all of them deselected. I put checkmarks into the [I]initial layer speed[/I] and [I]initial print speed[/I] right under it, then clicked Close. The window beside the initial settings button changed to show me the [I]initial layer[/I] and [I]print speeds[/I]. I changed the setting from the 15mm/sec I had been using, to 5mm/sec. I know, pretty slow, but I wanted to see what it would do. I also changed the overall [I]initial layer speed[/I] from 15mm/sec to 10. I started a new print. I was very pleased to see how much smoother the initial layer of the bolt heads went: 5mm/sec seems really good for them. In addition to the [I]initial layer speed[/I] changes, I also modified the [I]infill[/I] settings, changing the rear & front brackets to 30% and the bolts to 90%. [/LIST] I made another change as well. Since I'm using a tablet to control the print job, I decided I could also have it give me remote video access, to monitor the print job. I tried using the built in camera as the video source but it was too awkward trying to place the tablet in a position where it could get a decent shot of the printbed. So I grabbed my little 720p Microsoft Lifecam and plugged it into the USB hub I have connected to the Surface. The default Windows camera app didn't want to find the Lifecam, so I installed Open Broadcaster Studio. It was able to find the Lifecam, which is now mounted comfortably to the front 2020 rail of the printer:

    [IMG2=JSON]{“data-align”:“none”,“data-size”:“full”,“src”:“https://forum.drvax.com/filedata/fetch?filedataid=441&type=medium”}[/IMG2]

    We’ll see how this print goes.

    • 2

    When a print just stops then the GCode stream gets interrupted. Usually the usb connection got issues, when e.g. windows decides to go to standby.

    In your case I guess the sdcard with the GCode file got broken.

    Especially when cheap Chinese cards get combined with enabled power fail protection this happens quiet often, as during print the printer writes the actual print state to that as card, which causes it to eventually fail. Especially when small SD cards are involved it is more likely the same blocks are reused over and over, as the reserve blocks are minimal.

    3

    It was weird. The printer didn’t think the job was complete, I don’t think, because it didn’t return to home position. I will try a full format of the card using SD Card Formatter.

    4

    The printer isn´t thinking anything. :smiley: It just takes GCode lines and performs the action defined behind it. At the end it homes because your slicer told it to home by gcode command.

    It it does not get any more commands, it simply does nothing beside holding the temperature.

    Usually the printer stalls and melts all plastic around the nozzle, while ozing more plastic into spot it halted. I had it once with octoprint, but the printer itself will fail in the same way, when it is unable to read from SD card.

    Make sure to verify the formatted card or you may run into that same issue over and over and usually when you don´t expect it. :smiley:

    5

    OK, yes, technically the printer doesn’t think. What I mean is that the printer didn’t come to a point in the code where the next action would be to home the hotend, disengage the steppers, and turn off the heaters. I was simply trying to find a shorter way to say it, even if it’s not technically accurate in detail.

    The question is why it stopped executing code. Certainly, not being able to read the next g-code command from the file is high on the list of possible causes. A faulty SD card could obviously cause that. Unfortunately, SD Card Formatter did not run into any issues during the format. I plan to use SpinRite (in read-only mode) to check the card. It has proven quite capable at detecting flaws in SSD devices of all kinds.

    In the meantime, the new print is proceeding, running via USB from the Surface. The monitoring camera, too, is working well.

    BTW, I wanted to thank you for your feedback, and also to ask something. My printer is supposed to have power fail resume capability. I’m not sure if it still has that ability since I changed the firmware to TH3D Unified. Assuming it does, perhaps you can tell me if the reason the firmware writes to the SD card so much is because that’s how it keeps track of where to re-start a print after a power failure?

    6

    yeah, that is likely the reason. There is no other way to store the last position before a power failure. I have no clue about the firmware you used, but it should work somewhat the same.

    As I said before. those cheap chinese cards may even come broken from factory or have the wrong size. The easiest way to find out is probably to start a print and pull the power plug. Wait a few seconds and put the plug back in. The printer should start with a message about a failed print and asking you to continue. At least from what I know.

    You can also try sending the command M413 it should report if the feature is available/enabled or not. It usually can be turned on with “M413 S1” and off with “M413 S0” This likely requires enabled flash support (M500-M503) enabled in the firmware or power recovery is mainly useless.

    7

    Good suggestion for testing the auto-resume. It’s the thing I do to test UPS’. BTW, my printer is plugged into a 1500W sinewave UPS.

    I ran SpinRite on the card and it found no unreadable sectors, and completed all 8GB successfully.

    M503 definitely works; I’ve used it. Don’t know about M413; never used it.

    8

    The folks at the Raspberry Pi Foundation have a new tool for installing an operating system image onto an SDcard which also includes an erase option that will format the sdcard in FAT32 format which I have begun to use to format my cards. Raspberry Pi Imager runs on windows, macos and linux.