RE: Ignored gcode lines. Circle segment reduction?
If you guys enjoy elephants foot from mushing your first layer go ahead, it is not a first layer issue... Just watch the youtube video I posted from 1:25 it shows the second part being printed...
Ignoring the advice you're being given because you don't like it doesn't magically make the problem go away. Multiple people have told you the exact same thing, and those comments are from several well-respected and very active forum members that know their stuff.
Clearly we're not giving you the answer/advice you *want* to hear, so I'd say you are unlikely to find much further assistance here.
RE: Ignored gcode lines. Circle segment reduction?
This seems like some random firmware/EEPROM corruption that happened on my einsy board. After flashing the same firmware(the same file that I uploaded 1 month ago when I upgraded my MK3 to MK3S with MMU2S) that had the problem it now prints these files without problem...
RE: Ignored gcode lines. Circle segment reduction?
As an aside, your layer one is really off. Way too thick.
The first layer is 0.2mm and tuned almost perfectly
If that mess is 0.2 mm x 0.45 mm (a good first layer) I'll quit printing ...
Some people prefer printing PETG a bit thicker so it sticks less like super glue ... but you've never mentioned it as a reason. And the resulting surface quality from printing with loose strings must not matter.
One other thing you probably don't know: EEPROM in the uP on the Einsy has only so many write cycles before it begins to fail. Changing firmware daily will haunt you.
RE: Ignored gcode lines. Circle segment reduction?
If you guys enjoy elephants foot from mushing your first layer go ahead, it is not a first layer issue... Just watch the youtube video I posted from 1:25 it shows the second part being printed...
Ignoring the advice you're being given because you don't like it doesn't magically make the problem go away. Multiple people have told you the exact same thing, and those comments are from several well-respected and very active forum members that know their stuff.
Clearly we're not giving you the answer/advice you *want* to hear, so I'd say you are unlikely to find much further assistance here.
If you ask if anyone has had the same issue and a couple get hung up on the first layer and you then go trough the process of proving with a video that the printer is moving the exact way that I said it was from the start. And even then still say the same thing. What do I do?
How can I prove the earth is round if flat earthers disregard the evidence? What more can I do? Sure I'll lower the first layer height for this crappy filament that is some bad "nGen" marked garbage. Ruining the perfectly good layer height for every other filament because some guy on the internet tells me my layer height is of even though I say it is fine. I have years of experience and study to become an 3D printing tech. I don't need to change the layer height it is irrelevant to the question.
But no thank you for solving the problem WHERE THE PRINTER DISREGARDS SOME LINES IN THE GCODE. Obviously it is just a bad first layer. Thanks.
RE: Ignored gcode lines. Circle segment reduction?
As an aside, your layer one is really off. Way too thick.
The first layer is 0.2mm and tuned almost perfectly
If that mess is 0.2 mm x 0.45 mm (a good first layer) I'll quit printing ...
Some people prefer printing PETG a bit thicker so it sticks less like super glue ... but you've never mentioned it as a reason. And the resulting surface quality from printing with loose strings must not matter.
One other thing you probably don't know: EEPROM in the uP on the Einsy has only so many write cycles before it begins to fail. Changing firmware daily will haunt you.
The atmega2560 EEPROM is rated to 100,000 rewrites if I remember correctly. I've changed firmware only when I got the printer, when I tried a PT100, when I got my MK3S upgrade, and two times yesterday, so 5 times. I don't find that excessive after 9 months of owning the printer. I can't reproduce the problem after uploading the newest firmware on any of the gcodes. So it will have to be chalked up to random bugg or corrupted firmware...
RE: Ignored gcode lines. Circle segment reduction?
FYI - I tried printing the gcode you posted - it came out fine. No strange artifacts, pathing errors, etc., (see earlier post).
A few of us who are forum irregulars see a lot of people posting bad prints and the issue is layer one or filth on the bed. About 99 out of 100.
Printer hiccups are so rare, well, short of filament sensor issues and print resume issues, can't say I've every seen a print that's failed because a series of gcode commands were ignored. But then you've said you've been messing with your own firmware builds, and even later said you changed firmware to an official build after posting the images and that seems to have made the issue go away. Seems you answered your own question. And why I offered the fact writing to eeprom (aka flash) has a limited cycle life. It isn't uncommon for these flashing errors to manifest as random read failures after a flash.
But yeah - your bed is fine and your aren't having print issues... wait, why did you post this thread?
RE: Ignored gcode lines. Circle segment reduction?
FYI - I tried printing the gcode you posted - it came out fine. No strange artifacts, pathing errors, etc., (see earlier post).
A few of us who are forum irregulars see a lot of people posting bad prints and the issue is layer one or filth on the bed. About 99 out of 100.
Printer hiccups are so rare, well, short of filament sensor issues and print resume issues, can't say I've every seen a print that's failed because a series of gcode commands were ignored. But then you've said you've been messing with your own firmware builds, and even later said you changed firmware to an official build after posting the images and that seems to have made the issue go away. Seems you answered your own question. And why I offered the fact writing to eeprom (aka flash) has a limited cycle life. It isn't uncommon for these flashing errors to manifest as random read failures after a flash.
But yeah - your bed is fine and your aren't having print issues... wait, why did you post this thread?
I can see how someone would comment about this first layer, but I have posted nicely several times that it was not the issue so we could move on. If you read my original post I was asking if anyone had seen this happened.
The first answer someone mentioned that it just might be a first layer issue. I assured that I was looking at the printer and that it actually moved like it suggests from the print. They then say that they are not convinced... WHY WOULD I LIE ABOUT IT? I then post a video SHOWING that it actually moves like I said. THIS IS IRREFUTABLE PROOF!
Then it gets mentioned again and again... How would you react? I referred them to said video. The bed looked dirt, I explain that the bed was sanded and look grayish because of it.
Then you tested the gcode and assured that the gcode was not to blame. Finally something that is about the original post that is helpful. And you also support the suspicion I had about firmware being the blame.
Then two people get hung up on the post where I mention the layer being almost perfect. Okay it might not be perfect but it is not the issue so I just didn't want more posts about it, and post my comment that you can mush it into elephants foot print if you want and refer to the video. Suddenly I am the asshole and just want to confirm my own flat earth theory. When all this time they have just been talking about the first layer that is proven to not be the problem.
I've had no problem with you tim. And has just answered your questions.
During this I solved the issue by flashing a new firmware that I compiled, and wanting to check if the official firmware would produce the same issue so I could possibly help remove a bug. But I can't reproduce the problem and therefore can't pinpoint what the problem is and just have to assume the firmware or EEPROM got corrupted.
No one has been able to reproduce the problem either. And if they have this issue they might find this post on google and they will read 10 posts arguing about the first layer. When instead it could have been dropped earlier.
RE: Ignored gcode lines. Circle segment reduction?
I have the same issue. Mk3 and mmu2 upgraded to mk3s and mmu2s. Those are threaded holes. Gcode looks good in gcode viewers. I'll try reflash and/or lowering triangle count. Thanks for posting your findings
RE: Ignored gcode lines. Circle segment reduction?
Turns out in my case it was an adhesion issue. The angle of the thread was too sharp and the print had no floor to stick to. Changed the thread to not have such sharpe angles and now it's all good
RE: Ignored gcode lines. Circle segment reduction?
I have the same issue. Mk3 and mmu2 upgraded to mk3s and mmu2s. Those are threaded holes. Gcode looks good in gcode viewers. I'll try reflash and/or lowering triangle count.
I think your issue is something else. You'll see that effect when using layer heights that are a bit too high, resulting in poor inter-layer adhesion. Extrusions are being pulled taut across the circle when they pop loose. Inner threads are particularly susceptible to this with the severe overhangs involved. Try reducing your layer height. Increasing temps or reducing cooling can also help, though at the risk of other visual issues.
and miscellaneous other tech projects
He is intelligent, but not experienced. His pattern indicates two dimensional thinking. -- Spock in Star Trek: The Wrath of Khan