Hi all, Sorry for butting in but given the subject of this thread I thought this would be the right place to do so. I've also just upgraded to the new 1.09 RepRap firmware and copied all relevant files from the SD-image folder to the SD card (including everything in www). I see and can connect (eventually) to the printer via the new web interface. The printer controls work but anything to do wiby bartdietrich - Ormerod
(or I should really have said to Dave: "I'll design and print a broomstick as soon as I've printed and installed the spool holder")... :-)by bartdietrich - Ormerod
QuoteAs a temporary measure while you are printing a spool holder, just put the spool on a broomstick resting horizontally between a couple of piles of books, buckets, bricks or similar with something to stop the broomstick from rolling off. Thanks Dave. I have books, I have one bucket, I can probably source some bricks (lots of building work around where I work) but I don't have a broom. I do hby bartdietrich - Ormerod
I just hope the filament getting entangled tightly with the bed and x axis hasn't bent my x arm!by bartdietrich - Ormerod
Thanks for the replies everyone. I copied what settings there were in the supplied G code files into Slic3r and this resulted in immediate improvement of prints (although also in a marked slowing down). You were right Dave, (much) slower printing speeds do make a big difference. Although the massive overhang test is still a disaster (on the two most inclined prongs at least): no issue with the iby bartdietrich - Ormerod
Hi Dave, Thanks for that. I've set my Z=0 position to be 0.2 mm higher than it really is (by way of the G31 command in config.sys), this seems to have improved the situation for the first layers, but then the problem reoccurs around layers 3 or 4 or so. I guess I'm onto something here. As you said, speed might be an issue too, when I slow the external perimeter printing speed down, the overhangsby bartdietrich - Ormerod
Speaking of max resolution, is it possible that the massive overhang test has a resolution far higher than the printer can do or is necessary but because I didn't limit this parameter in Slic3r (it's set to 0), the printer is trying to lay down a thread through a hawse pipe so-to-say, which results in unintentional over-extrusion? (can't check this right now, printer woes drove me to the pub)by bartdietrich - Ormerod
Hi again, So I've been closely observing what the printer is doing. With the Massive Overhang Test the problem starts at the first layer. When the printer is printing the bottom layer infill it's doing those very closely spaced zigzag moves. When laying down an adjacent line, it digs through part of the previous line, pushing its boundary to the side and up a bit. This effect is cumulative and tby bartdietrich - Ormerod
Thanks Darathy. To dc42: Tried what you suggested (G91 then G1 Z0.24 F6000). Did this 200 times and measured distance from bed to tip of nozzle. Exactly 48.00 mm as it should be (maybe max 0.1 mm under, depending on how hard it pressed the caliper against the nozzle)...by bartdietrich - Ormerod
Hi dc42, Ok, I'll try that in a bit (trying another print at the moment). If that's the problem though, why would the G codes that came with the printer (coathook etc) print ok? I printed a little box with lid (see photo, I know, not exactly earth-shattering but you've got to start somewhere) and it fits together quite nicely and the dimensions are nearly exactly as I specified in OpenSCAD (2-4by bartdietrich - Ormerod
Hi Dave, Thanks for your reply, but this is not the problem. I double-checked: the "use relative E distances" tick box is ticked and start code contains M83. The generated G code uses consistently small numbers for the E parameter (for the first couple of pages I flicked through). I changed to absolute E moves just to see: I unchecked the box and changed the M83 to M82 in the start code. The genby bartdietrich - Ormerod
Hi all, I'm new to this so apologies if the resolution of this problem is obvious. My Ormerod 2 prints the G code that came with the firmware (e.g. the whistle or coathook) well enough, only the occasional small blob or wisp of melted PLA. So I thought I'd give a few STL files a go. I use Slic3r to create the G code from the STL files. Downloaded and installed the Ormerod profile for Slic3r asby bartdietrich - Ormerod
Given that the new firmware with this bug fixed (1.09) will be released early next week, should I just wait until then before redoing all calibration steps? Is switching to dc42's firmware considered cheating on RepRap and result in Ian no longer talking to me? :-) In the meantime, if I want to try printing stuff, the printer seems to work well enough without ever running bed.g. Thanks, Bartby bartdietrich - Reprappers
Thanks everyone for your replies! I typed the following reply to Ian before I had seen all the others, so I'll just post it here anyway. Thank you everyone for your time! ==================================================================================================== Hi Ian, Thanks for your reply. I’m copying this into the forum thread too. You were right, when I reset all M556 parameteby bartdietrich - Reprappers
Hi all, I'm having an issue with the bed plane compensation macro (bed.g) on my new Ormerod 2 (v1.04 firmware). After homing the x, y and z axes I run bed.g and the x axis carriage ends up bumping and skipping against the far end of the x axis even though the coordinates specified (x=212) are well within the usual range of movement of the carriage. When I reduced the x coordinates to below 200 tby bartdietrich - Reprappers
I've fallen victim to the M4/M5 nut mix-up as well, it would appear. Mildly annoying as I've taken the day off work tomorrow to (hopefully) finish the build! I'll be emailing for a replacement but in the meantime I'll be going through my box of random bits in search of anything M5 as a temporary fix! Bartby bartdietrich - Ormerod