Jump to content

BookSwapSteve

Dormant
  • Posts

    5
  • Joined

  • Last visited

Everything posted by BookSwapSteve

  1. Hi, Sorry delayed on adding more findings after my initial set, @nccwarp9 you might find this helpful... The issue happened again to me after my last post, however I had inspected the gcode file on the SD Card after saving and it appeared to be correct (included the footer padding which was absent on the bad files). However the print failed at the end in the random way, when I put the SD card back into the PC the gcode was again corrupted at the end of the file. I tried a few more slice, export and view cycles and every time it appeared OK, however when I removed the SD card and re-inserted it the file would always come out corrupted (Even when I used the "Eject" option!) However, when I saved the gcode to local disk and then copied over using Windows explorer (remove, re-insert SD card) I did not see the issue (I only tried this once though, so hardly scientific!). I've since moved to a different SD Card and not had the problem (although very limited printing since then). Hence I'm more convinced it's a strange SD failure, and/or something weird in Cura's file writing that's triggering the issue. Although how it picks up strange gcode is still puzzling, but given my SD cards tend to be used only for gcode files then it's possible it's picking up data from an old file. I'm guessing theirs some kind of cache on the SD card that gets cleared when power cycled which is why the file appears to be ok initially but then bad once power cycled. @nccwarp9 - my suggestion would be one or more of the following (a) change SD cards, (b) save to SD card, remove, re-insert, use a text editor to load the gcode and check for the big comment in the footer (assuming your cure/UM firmware does the same as mine) - or load into a gcode viewer and check the "last" layer, (c) (may not help) save to local disk, then use a file copy utility (i.e. Windows Explorer) to copy the file to SD (and then remove-reinsert and check the file). - Obviously none of these are ideal, but my money's on an issue with the SD card. Cheers, Steve.
  2. Hi. I'm seeing the same issue. It's happened on a number of prints now, I assumed it was due to a bad SD card to begin with but I don't think that now. Here's what I know... I only ever see it from Fusion 360 generated STL's. Never OpenSCAD ones, I've also never seen it on a Thingiverse file (but I don't generally know the application used to generate the files in that case). I've seen it happen a number of times from Fusion 360 generated STLs. Appears to be the last layer (difficult to tell if it's perhaps one or two from the last layer, but never midway through the print). Usually it retracts the filament out or nearly out of the feeder (fast) and them moves the extruder very slowly. Except today's one (see attached "PhoneBoxEnclosure") when it moved the Y axis very slowly and extruded very slowly, in the wrong X position (I have a video if you really want to see it....) It's difficult to reproduce, I've tried a number of times today to re-slice the file with no luck to reproduce the original failure. I took the bad gcode from my Ultimaker SD Card and did a diff compared to a re-sliced version and theirs a significant difference for the end of the file (see "MissingGCode" screenshot, all the red is missing GCode that was in the bad file and not in the good). Some different GCode commands (e.g G0 F75 E1808.5661 in the bad which I don't see in the good gcode) The terminating block of comments for 2.6 firmware doesn't appear in the bad file. The bad file does appear to be terminates early. The final 2 lines are: G1 X110.556 Y174.657 E1996.60882 G1 X111.11 Y174.701 E199 I'd expect that last E199 to be E1996...... hence it looks like the file ended prematurely as well as having bad GCode. Given the bad gcode file has gcode that's missing from the good file I don't think it's a corrupt SD card or file, I've also used the SD card numerous times with other files and only seen the problem repeat with F360 based ones. My setup: Cura: 3.5.0 (I think I've seen it with previous versions though) Ultimaker 2+ Extended. 0.6mm nozzle Windows OS Phonebox stl model sliced using: 0.2mm Layer Height 80% infil; Rotate counter-clockwise 90 degrees (opening at front) from the model. Otherwise standard Cura settings (however my profiles appear to have got a bit broken during Cura upgrades, I think it's the fast profile base) Attached are two designed. PhoneBoxEnclosure-1-1 BinMonitoredEnclosure-5-Narrow These include good and bad gcode files. If you send the bad gcode to GCode Analyzer (http://gcode.ws/) you can see the final layer issues. I've also added the Fusion 360 file for the PhoneBoxEnclosure if that's any help (I don't think it's changed since the bad slice but it may have). Not sure what the forum is actually going to include so I've added a zip as well that should have everything in it. Also... Don't ask I'm calling it PhoneBoxEnclosure when it's more barn or dog house like! (Naming's hard! :-) ) Hope this helps. Steve. BinMonitoredEnclosure-5-Narrow-Good.gcode PhoneBoxEnclosure-1-1.stl PhoneBoxEnclosure-1-1-Bad.gcode PhoneBoxEnclosure-1-1-Good.gcode BinMonitoredEnclosure-5-Narrow.stl BinMonitoredEnclosure-5-Narrow-Bad.gcode LastLayerGCodeSlicingIssue.zip
  3. Same issue here. Windows 8.1, Cura 2.4.0 It's only the D drive for me. I have many other removable disks (and actually the SD card is normally the J drive), but only the D (DVD) drive is getting flagged. Cura has become unusable. Change layer height, accidentally move model, drop new model on workspace, do almost anything and I get 50+ no disk messages. I'm going to roll back to 2.3.1, hopefully a fixed build of 2.4 will be out soon?
  4. Need a lid for your Ultimaker 2? Look no further, you can find the designs here: github.com/Tinamous/UltimakerLid V1.1 is the most basic: V1.2 includes draft excluder brushes to fit around the Boden tube and cables as well as an opening to embed a Raspberry Pi & 7" touch screen. We use OctoPrint to stream the webcam so it's handy to have the Pi directly in the lid. We've found the lids work well for: Keeping the dust off the build platform (a big problem in Makespace) Improving temperature stability when printing Camera mounting for remote monitoring using OctoPrint The svg files for the 1.2 designs can be edited to remove the cut-outs for the Pi Display if you don't want it embedded in the lid, you can instead stick a USB camera as we did for V1.1. Both versions include a .json file which can be used at MakerCase.com to modify the designs as you like. Sadly the USB comms of the UM2 is proving problematic so at this time we've not been able to make better use of OctoPrint, hopefully with time the lid mounted display and OctoPrint will become more useful. Hope you find the designs useful as well. Steve.
  5. Really want to but having problems getting it working properly. Managed to get it connected and inserted the pre/post gcode for printing but it's not working properly for me yet (sorry was a month or two ago that I tried so forget the finer details of what was wrong). FYI - Printer is a shared one in our local MakeSpace so having the camera, usage stats, access control and all that OctoPrint brings would really benefit us. Any tips on getting UM2 and OctoPrint would be very welcome! Cheers, Steve.
×
×
  • Create New...