For about two years now I've reasonably babysat every print job sent to my printer. Assume that a rectangular raft is being laid down. Note that I slice with relative extrusion. Also note that I have an unheated bed. 
- Hovering in front of the printer and waiting for the first line to be laid down (and always extruding from the front/left corner horizontally in front of me)...
- Manually jiggling the print bed platform up/down so that the first line adheres in places (rather than the extruded line hovering above the print bed and not adhering)
- Watching it go away from me down the right side, left, back toward me then...
- It's trying to now run toward-me-and-back side-by-side loops for the first layer (but this is problematic since that first horizontal line from above got a slow start). So for each of these as it's changing direction near me I'm lifting the print bed platform slightly to force more adhesion.
- Assuming that it did that happily for the first layer...
- Then it's the magic moment where it needs to set up for the next layer. Only this often results in the nozzle dragging across all those laid-down lines and removing them from the print bed.
- So if it did, I usually abort, pull that attempt off the bed and restart.
I've been doing a number of new upgrades to my printer in anticipation of adding a 2nd extruder and printing with PVA so I'm trying to fix these annoyances.
Sure, I'll add a heated bed soon enough but I just did something interesting by just manually editing the gcode.
- I added two extruded lines across the front of the rectangle (one right and one returning to the left). This seems to fix the slow start from earlier.
- I edited the gcode at the end of the first layer to raise the hotend a full 1mm before moving. (Note that I've set this already in Cura but it doesn't seem to be honoring this request.)
Given that my filament tends to dry out (since I'm close to the heater), I also added a filament conditioner (canola oil, wine cork with a hole in it and a mount for that). It seems to want a little over-extrusion to compensate but it's looking beautiful so far. And I just left it alone without all that fussing.
This is excellent as compared to the many failed attempts from earlier today.
2 Likes
Have you ever tried printing without raft? I can't remember the last time I printed with a raft and it's been at least 10 years of printing for me. Is your machine so inconsistent that you can't level your bed and have it nail the first layer every time?
Honestly, I'll say that it depends upon too many factors (again noting that my print bed isn't heated):
- dry filament
- brand of filament (I'm using the Shaxon natural today)
- weight of the filament spool as loaded on the roll (1KG is sluggish compared to a partially-loaded half KG roll, for instance) which changes extrusion effectiveness
- temperature of the hotend
- extrusion rate
In the past I've had success without rafts using a brand new roll of, say, Robo 3D white PLA filament @ 190 and default extrusion rate... having added a foam enclosure around everything and pre-heating the inside to about 90 degrees Fahrenheit (using a 2nd Pi which reports the temperature). This was after I added manual leveling adjustments to all four corners. I still normally run the G29 autolevel though. The plastic bed isn't very consistent, to be honest.
But now of course the Pi in the bottom of the printer has been recently complaining about overheating. I guess I'll need to add a second fan to the Pi down there right on top of the CPU. This is a new development since the room heater's been on this winter.
Robo 3D doesn't sell a heated bed for this printer so I'll end up rolling my own on this one.
Or break down and buy a better printer...lol...JK.
Or break down and build a better printer from scratch, more like...
Went in and modified last night. Replaced the Pi with another Raspberry Pi 3B with a C4 Labs Zebra case with fan. Given the way the Robo 3D has a 40-pin connector on there for their own needs, I had to power the fan from their control board (5V, always-on).
Lo and behold, it's still reporting overheating in the OctoPrint interface and throwing a 0x50000 from vcgencmd get_throttled and all the while the CPU temperature seems quite manageable. It might be this though. Grr...
I've been thinking of this myself. I probably have enough spare v-slot and old stepper motors laying around that I probably could build 2.
I just wish there were a brick-and-mortar store I could walk into and fill a shopping carts with parts. I don't love the Internet shopping metaphor for things like this, to be honest. There was a time when you could drive down to Santa Clara and buy any odd part to build your own PC. Now that Fry's Electronics is going out of business, it's a hassle these days.
If you look some places like Arrow Electronics do overnight free shipping for some stuff. I've ordered Raspberry PI's from them and had them show up next morning. Couple other parts places are doing that as well as some of the nuts, bolts and screw places. We have three Frys in Houston and they are all clearing out inventory while saying nothing is wrong. Fortunately, I still have Microcenter.
https://www.arrow.com/
1 Like
I turned off autolevel in my Gcode startup script and did some manual leveling with raw gcode commands and a piece of paper. I now have started a huge part with a raft which reasonably fills up the print bed and I tweaked the four corner adjustments manually and often until I've gotten a level playing field now.
It feels like the autolevel on this really isn't my friend. I guess I'll just leave that off for a bit and see how this goes.
In case you're interested, I'm printing the redesigned bottom part for the spool movement detection upgrade. I'm just now getting back to it. I was worried that since I didn't know how to manipulate Raspbian to ignore the mouse input (and yet leave it available) that this would cause problems. I've just decided to dedicate a Pi 3A+ to the task since it has a single USB connector and would do nicely. I'll just run a service on this and "Bob's your uncle" as they say.
How do you realized the communicate between this raspi ("spool-raspi") and the octoprint raspi, mqtt or direct?
As a minimum you need to inform the spool-raspi about "print started, please activate spool-monitoring" and from the other side: spool-raspi send to octo-rapis: "hey dude, I think there is something wrong with the spool, please stop the print" (please...always be polite)
1 Like
At the moment I'm just going to exercise the REST API of the receiving plugin's API over standard http/POST. I just ran a job yesterday to gather some statistics about how frequently the spool moves. The highwater-mark was 201 seconds under normal conditions; I wouldn't have guessed that far between the events but that is what the standard appears to be.
I thought I could work in either two modes:
- throw events to the plugin for anything above a certain lower threshold (greater than 1 second) and let the plugin detect idleness since it knows when printing is occurring
- have the sender detect idleness and send it once per the upper threshold (greater than 240 seconds, say) and let the plugin make the determination
Later, I'll likely run this locally on the printer's Pi itself but my particular OctoPrint Pi has four USB connectors already in use, to be honest.
I like the idea of pushing this to a Pi Zero W but the serial connection is a bit problematic on those size-wise.
I managed to write some code in C which detects the mouse movement. The Python mouse module was throwing a segmentation fault for some unknown reason on Raspbian (Lite). I didn't see any related issues on this. I suspect that the non-x-windows version of it isn't tested as much.
