fabianonline
Notifications for layer height sent twice w/ Z-hop
Hey,
I have enabled Z-hop on retract (0.1mm). My plugin has the default config of notifying me every 5mm in Z oder every 15 minutes.
I wondered why I get 2 messages sent shortly after each other each time a message is sent.
Then I saw that the first message has a greater Z height than the second, mostly something like:
- msg - Z: 6.05mm
- msg - Z: 6.15mm
Since I have used a layer height of 0.15mm and a Z-hop on retract of 0.1mm and have enabled the "force retract on layer change" it would totally make sense that the plugin is triggered twice with a very short time difference.
Anything I can do to help?
OctoPint 1.2.9 OctoPrint-Telegram 1.0.0
The GCODE I printed is attached. serenity_no_panels_sliced_top.gcode.txt
On a first, very short, look it seems the "problem" lies within octoprint_telegram/init.py line 294
It returns True if the Z change to the last Z notification is greater than the configured threshold or if the new Z position is smaller than the Z position of the last notification. Since the notification is first sent when doing a Z hop the next Z change will be negative thus triggering this check. Since I do not know the reason for triggering also upon a negative Z change, I do not know if it would be feasible to just remove the "or new_z < self.last_z" part.
The negative Z change becomes interesting if you do something like "move to X0 Y0 Z5 and extrude some material" at the beginning of the print. Although I ignore large Z changes (anything of at least 2.0mm for now) anyway...
I think removing the or new_z < self.last_z part might be just the right thing to do. I'll try to think about why this could be a bad idea. If I don't come up with something, I'll remove that bit.
This is also a problem when using Octolapse - this line causes notifications every time octolapse performs a z-hop after a snapshot.
Octolapse is using relative positioning, so I think it's also messing with the storage of the last z value - but that might be from octoprint passing the relative z change as new_z in the ZChange event?
Either way, all Z positions were being reported as "-0.2" in notifications.
This is also a problem when using Octolapse - this line causes notifications every time octolapse performs a z-hop after a snapshot.
Octolapse is using relative positioning, so I think it's also messing with the storage of the last z value - but that might be from octoprint passing the relative z change as new_z in the ZChange event?
Either way, all Z positions were being reported as "-0.2" in notifications.
After a while I again enabled Octolapse and again received many telegram notifications. This Z position with „-0.2“ in notification is exactly what I observe again. Is there any progress in solving this issue ?
This is still very annoying, and I see there are some proposed fixes, including the pending PR #423. It would be convenient if they were merged, because currently I am forced to apply the patch locally and lose the change every plugin update. I see this project hasn't been updated since 2022, but @derpicknicker1 recently merged a couple of PRs. Maybe they could take a look at this?
