Delay pings until the wipe tower

[cyberhuman]

Currently pings can occur at any time. When a ping occurs over the object being printed, it causes a small pause as the command queue is flushed. During the pause, a small amount of plastic leaks out of the extruder and creates a small blob. Is it possible to delay each ping until the wipe tower? Ideally, add some randomization so the blob doesn't occur in the same place in the wipe tower.

[mwheiss]

Sorry for a slight off-topic question here...

@cyberhuman Are you by any chance the same person who commented on the Mosaic webpage that you are working a way to integrate the connected mode of the Palette 3 into Klipper? If so I would really like to get in touch with you about it, perhaps I could be of some help.

[cyberhuman]

@mwheiss yes I am.
I have several successful prints in connected mode with my changes in klipper.
I will submit a PR to klipper. I'm not sure it will be accepted because there are some small issues, but an least people will be able to find and use it.

[cyberhuman]

Klipper3d/klipper#6482

[tomvandeneede]

The ping thing is quite complicated as you need 20mm or so of filament extrusion between the two pings. I am looking for quite some time now with Mosaic to get an addition to their firmware that would allow replacing the pause pings with MQTT messages to the P3 This keeps me from further developing the current solution.

…

On 4 Feb 2024, at 03:15, Raman Varabets ***@***.***> wrote: Klipper3d/klipper#6482 <Klipper3d/klipper#6482> — Reply to this email directly, view it on GitHub <#190 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJMDIELB6KNZJF2QOQ3YR3VLHAVCNFSM6AAAAABCXPSQMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRVGU2TGMRXHA>. You are receiving this because you are subscribed to this thread.

[cyberhuman]

@tomvandeneede how I imagined it is when a ping is delayed by N mm, all subsequent pings happen N mm later, too (and then, delayed even further if needed to end up in the wipe tower, delaying next pings again, and so on). There is never a problem in delaying pings as long as the length matches, right?

I believe the MQTT solution will require changes in the printers' firmware, which doesn't sound good. How will it work exactly?

[tomvandeneede]

yep simple in theory but very hard to implement in a pre-generated code file Both start and end need to be in the tower and you want to have pings at regular intervals so let’s say every 350mm… it’s not really the main logic but more off the exceptions that make it difficult concerning MQTT… should be minor upgrade on their side and a plugin on raspberry pi + small changes inP2PP we discussed it already so should not be that hard

…

On 5 Feb 2024, at 02:59, Raman Varabets ***@***.***> wrote: @tomvandeneede <https://github.com/tomvandeneede> how I imagined it is when a ping is delayed by N mm, all subsequent pings happen N mm later, too (and then, delayed even further if needed to end up in the wipe tower, delaying next pings again, and so on). There is never a problem in delaying pings as long as the length matches, right? I believe the MQTT solution will require changes in the printers' firmware, which doesn't sound good. How will it work exactly? — Reply to this email directly, view it on GitHub <#190 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJNFJGP4YUVDFD4NW3DYSA4HHAVCNFSM6AAAAABCXPSQMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRWGA4TANBUGM>. You are receiving this because you were mentioned.

[cyberhuman]

you want to have pings at regular intervals so let’s say every 350mm

My point is to have pings at least every 350mm. Yes they won't be exactly linear or regular, but it shouldn't be a problem?

[cyberhuman]

Here is a working POC: https://github.com/cyberhuman/p2pp/tree/experimental/ping-in-tower