AutoAddPurge w Short Splices may cause Splice Necking

[dondec123]

I'm running into an issue where I can print for hours, then my print aborts with Err 134 (extruder not pulling filament any longer).

• On inspection, my printer pulled the error at Z 19.75., which referring to PS's layer display is layer 158.
• Retracting the filament from the Extruder there was indeed a thin necked splice in the extruder that it couldn't grab.

At first I thought these random necked splices were due to the Palette overheating, but I've got 3 fans blowing on the Palette now so its not heat.

CURIOSULY, the point at which the necked splice occurs is the layer immediately before P2PP declared a Short Splice! It said layer 159 was short, my necked splice occurred on layer 158.

Coincidence?? I think not... because:

• P2PP declared another short splice at layer 161 and checking my filament strand again (as pulled from the Paletted) there's another Necked Splice THERE TOO.

This is hard to photograph with only 2 hands, but I've included a picture of the splice strand and indicated where the NECKs are. Additionally, my PS project in attached as well (you can see my P2PP GOCDE). EXPORT with save unprocessed is also included.

In theory this should not be a problem, since I have AutoAddPurge enabled. But maybe there's a logic problem in the code there? Too much of a coincidence. Something's going on in this region.

Please let me know... Thank you.

https://1drv.ms/f/s!Arf1YeMUEh5Gm7pn61ZNE52-Sw00yg?e=SwXt2A

 Don

[tomvandeneede]

Could it be that the buffer gets completely emptied out and the extruder is pulling on the splices. You are the only person reporting these problems for functions that have been in for several years I am happy to debug but really need the unprocessed codes so i have a 100% certain hit of the error 3mf and other files unfortunately allow to much “own” settings to interfere that could make this problem go away

I developed P2PP as a free community product and at my own cost in terms of tools and software, and given the fact that I hardly do any printing anymore I really insist on getting smoking guns to look after.

Sorry about the lack of thorough search through code support but unfortunately I have no bandwidth to do that at this moment.

I hope you understand

Regards Tom

On 27 Jun 2023, at 06:01, dondec123 @.***> wrote:

I'm running into an issue where I can print for hours, then my print aborts with Err 134 (extruder not pulling filament any longer).

On inspection, my printer pulled the error at Z 19.75., which referring to PS's layer display is layer 158. Retracting the filament from the Extruder there was indeed a thin necked splice in the extruder that it couldn't grab. At first I thought these random necked splices were due to the Palette overheating, but I've got 3 fans blowing on the Palette now so its not heat.

CURIOSULY, the point at which the necked splice occurs is the layer immediately before P2PP declared a Short Splice! It said layer 159 was short, my necked splice occurred on layer 158.

Coincidence?? I think not... because:

P2PP declared another short splice at layer 161 and checking my filament strand again (as pulled from the Paletted) there's another Necked Splice THERE TOO. This is hard to photograph with only 2 hands, but I've included a picture of the splice strand and indicated where the NECKs are. Additionally, my PS project in attached as well (you can see my P2PP GOCDE). EXPORT with save unprocessed is also included.

In theory this should not be a problem, since I have AutoAddPurge enabled. But maybe there's a logic problem in the code there? Too much of a coincidence. Something's going on in this region.

Please let me know... Thank you.

https://1drv.ms/f/s!Arf1YeMUEh5Gm7pn61ZNE52-Sw00yg?e=SwXt2A

Don — Reply to this email directly, view it on GitHub https://github.com/tomvandeneede/p2pp/issues/167, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK6CHJO3X3BXNCVTU5674FDXNJLJPANCNFSM6AAAAAAZU77LLM. You are receiving this because you are subscribed to this thread.

[dondec123]

Hey Tom, 

The buffer was not “tight” i.e. squeezed right.  

Haha, I’m a retired Quality Assurance guy, take  extensive notes about each print and failure observed.  I think you see my careful detail in my report. 

Yes, its different, though there’s no denying the correlation.   And in a very specific place which should be easily verifiable AUTOADDPURGE works or not. I’ve just added the Unprocessed Codes to the OneDrive archive.   

I previously submitted the SAVEUNPROCESSED in the OneDrive folder.   Not sure of the difference but I hope this helps.  I put the processed codes there too. 

And yes, of course… we appreciate your work on P2PP and making it the best possible!!  

Thanks in advance. 

Don 

[tomvandeneede]

Correlation might be, causality is a whole other thing :-)

Will take a look at the files (

On 28 Jun 2023, at 15:42, dondec123 @.***> wrote:

Hey Tom, The buffer was not “tight” i.e. squeezed right. Haha, I’m a retired Quality Assurance guy, take extensive notes about each print and failure observed. I think you see my careful detail in my report. Yes, its different, though there’s no denying the correlation. And in a very specific place which should be easily verifiable AUTOADDPURGE works or not. I’ve just added the Unprocessed Codes to the OneDrive archive. I previously submitted the SAVEUNPROCESSED in the OneDrive folder. Not sure of the difference but I hope this helps. I put the processed codes there too. And yes, of course… we appreciate your work on P2PP and maknig it the best possible!! Thanks in advance. Don From: Tom Van den EedeSent: Wednesday, June 28, 2023 2:30 AMTo: tomvandeneede/p2ppCc: dondec123; AuthorSubject: Re: [tomvandeneede/p2pp] AutoAddPurge w Short Splices may cause Splice Necking (Issue #167) Could it be that the buffer gets completely emptied out and the extruder is pulling on the splices. You are the only person reporting these problems for functions that have been in for several years I am happy to debug but really need the unprocessed codes so i have a 100% certain hit of the error 3mf and other files unfortunately allow to much “own” settings to interfere that could make this problem go away I developed P2PP as a free community product and at my own cost in terms of tools and software, and given the fact that I hardly do any printing anymore I really insist on getting smoking guns to look after. Sorry about the lack of thorough search through code support but unfortunately I have no bandwidth to do that at this moment. I hope you understand Regards Tom > On 27 Jun 2023, at 06:01, dondec123 ***@***.***> wrote: > > > I'm running into an issue where I can print for hours, then my print aborts with Err 134 (extruder not pulling filament any longer). > > On inspection, my printer pulled the error at Z 19.75., which referring to PS's layer display is layer 158. > Retracting the filament from the Extruder there was indeed a thin necked splice in the extruder that it couldn't grab. > At first I thought these random necked splices were due to the Palette overheating, but I've got 3 fans blowing on the Palette now so its not heat. > > CURIOSULY, the point at which the necked splice occurs is the layer immediately before P2PP declared a Short Splice! It said layer 159 was short, my necked splice occurred on layer 158. > > Coincidence?? I think not... because: > > P2PP declared another short splice at layer 161 and checking my filament strand again (as pulled from the Paletted) there's another Necked Splice THERE TOO. > This is hard to photograph with only 2 hands, but I've included a picture of the splice strand and indicated where the NECKs are. Additionally, my PS project in attached as well (you can see my P2PP GOCDE). EXPORT with save unprocessed is also included. > > In theory this should not be a problem, since I have AutoAddPurge enabled. But maybe there's a logic problem in the code there? Too much of a coincidence. Something's going on in this region. > > Please let me know... Thank you. > > https://1drv.ms/f/s!Arf1YeMUEh5Gm7pn61ZNE52-Sw00yg?e=SwXt2A > > Don > — > Reply to this email directly, view it on GitHub , or unsubscribe . > You are receiving this because you are subscribed to this thread. > —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub , or unsubscribe . You are receiving this because you commented.

[dondec123]

I saw you made an a change to the code (though P2PP CHECKVERSION doesn't see it yet). Based on your changes I tried enabling FULLPURGEREDUCTION.

I guess I'm encountering some sort of "internal heat" related issue... on small prints having a lot of small splices (and PETG). You can see what I'm talking about here (my Ticket to Mosaic Support). I appreciate your support on P2PP of course, and perhaps any ideas if you have them, regarding this issue: https://1drv.ms/f/s!Arf1YeMUEh5Gm7pxf04yIiYJr52grw?e=fgXl5s

Thanks again

Don

[tomvandeneede]

`have you tried increasing the cooling parameter (third parameter) in the splice tuning? ould be that there is sufficient cooling for 1 splice but if multiple splices follow quickly there may be some heat buildup in the system making the splices still soft

other option is checking the drive wheels of the filament transport system in the p3, if they are dirty they could slip and allow for stretch by having one wheel pulling while the other is slipping… though this would likely then also happen in the large-splice prints

On 29 Jun 2023, at 03:38, dondec123 @.***> wrote:

I saw you made an a change to the code (though P2PP CHECKVERSION doesn't see it yet). Based on your changes I tried enabling FULLPURGEREDUCTION.

I guess I'm encountering some sort of "internal heat" related issue... on small prints having a lot of small splices (and PETG). You can see what I'm talking about here (my Ticket to Mosaic Support). I appreciate your support on P2PP of course, and perhaps any ideas if you have them, regarding this issue: https://1drv.ms/f/s!Arf1YeMUEh5Gm7pxf04yIiYJr52grw?e=fgXl5s

Thanks again

Don — Reply to this email directly, view it on GitHub https://github.com/tomvandeneede/p2pp/issues/167#issuecomment-1612309662, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK6CHJNB7GKAL5GYMIY4IRLXNTMANANCNFSM6AAAAAAZU77LLM. You are receiving this because you commented.

[dondec123]

Yes, I think you're right. I believe what’s happening is the splice cooling is blowing hot air into and along the filament channel, and because the splices are all short, over time its heating the channel and softening the filament nearest the splice core. When its PULLed by the feed gear, it stretches. Sadly, all that extra fan ventilation I added must not be reaching that post splice-core region.

[bavery79]

Another possibility here, also related to the cooling parameter - I've noticed during my own splice tuning troubles, during normal printing the filament often ends up sitting still out only slowly moving for longer than the normal cooling duration before a full-speed advance to refill the buffer (which I suspect is when the necking happens if the filament hasn't cooled enough at that point). Could be the necking you see only happens when it is rushing things to move on to the next (short) splice, and increasing the cooling value might force it to wait during the edge cases