Jump to content

Bracer

Dormant
  • Posts

    4
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Bracer's Achievements

0

Reputation

  1. So after running a few tests, it does appear that octoprint is the culprit. The same files on the sd card vs uploaded remotely have massive differences how the printer actually prints the model. Thanks for you replies Smithy, appreciate the quick responses - figured I'd update this incase anyone else has a similar issue in the future. Right, off to the octoprint forums!
  2. I *think* I may have found a possible reason.. I decided to limit the toolchain as much as possible so put the gcode directly onto the sd card rather than upload via octoprint - my printer seems to be happily vasing the mode 🙂 I'm guessing it's possible that there is either a conversion or corruption of some kind happening when it uploads remotely if it's over a certain size. I'm using a file that I've not used before so will go back to one that didn't work previously in a couple of hours when this is done and confirm or deny.. Layer view always looked clean when I had checked it in the past, this was one of the head scratchers that was confusing me..
  3. Hi Smithy - thanks for your reply. The printer is a CR10S-Mini running the stock firmware. I think it's unlikely to be a hardware problem as other prints all come out fine (as do many of the vase mode models I've done). There is a huge discrepancy between file sizes on prints that come out as expected and those that don't - the second picture model is very rough to the touch, almost like it is trying to fill a space rather than create a single shell. Typically those that print properly will be a few hundred kb in size but those that don't will be eg. 20mb which is why I suspect slicer issues over hardware (I did do some maintenance on the printer last night to be as sure as I could be about it). It's difficult to explain, but the print head sounds like its making a lot of micro-movements in a print like in the second picture, but will move smoothly in a successful print like the first picture.
  4. Hi all, scratching my head on this one and was hoping others might have seen the same (and have an easy solution!) Using the same settings in cura 4.0 when printing in vase mode (spiralize..) I get different results on different models but don't understand why. The attached pics show the difference in smoothness - the first is a low polly skull and the second was a start of a vase. The only thing I've noticed is that the ones that don't work come out as much larger file sizes and (even though cura says e.g 2 hour print time), octoprint will start and say something like 12 hours. When printing it sounds like the printer is making loads of little steps that ultimately create the unwanted texture you can see in the second pic. Slicer settings are not changed between the two prints (other than on this occasion I tried the 'surface mode only' setting to see if it fixed the problem but clearly didn't. I've tried rotating the models and reslicing and turning on and off other options but I still can't figure out why one prints fine and the other doesn't. It happens randomly with models (not just this one) so I've had to start looking at the file size before I upload otherwise I know I'll get a poor print. Any ideas? Spiralvase2SurfaceModeandSpiral.gcode
×
×
  • Create New...