[FR] Take_Frame_By_LayerChange

[ckvsoft]

Hello Is it possible to implement a Take_Frame_By_LayerChange without creating the gcode in the slicer every time. RepetierServer also recognizes a layer change. The GCode layer is also displayed in Mainsail, so it should be possible. lg Chris

[FrYakaTKoP]

@ckvsoft i got it on the todo list, problem is that zhop needs to be compensated and it's not that easy to get 100% reliable. That's the reason i started with the slicer macro method. The layer in mainsail is calculated, it's good when printing same layerheight during the print and not using zhop, but with variable layerheight or zhop the layer display is way off.

As said i will implement this, but i need to get other stuff done first.

But why would you need to add it to the slicer everytime? normally you can add it once to the slicer and you are fine. If you don't like to have a timelapse just deactivate the plugin, which can be done when starting a print in mainsail v2.1+ (in open beta atm)

[ckvsoft]

thanks. In mainsail I can see the calculated value, but if you move the mouse over it, the current value from the gcode is displayed. I have saved a number of gcodes that are repeatedly printed. These would have to be thrown out and sliced ​​again. That's why that would be for me a nice solution, but I can probably expect it

[dapostol73]

OctoPrint Timelapse has this feature and so does the OctoLapse plugin, maybe their solution could help provide insight one how to solve the ZHop issues.

https://github.com/FormerLurker/Octolapse/tree/master/octoprint_octolapse

[FrYakaTKoP]

i already have a "working" implementation, but it's not working with zhop (or i'm not happy with the result). As long i can't have same reliability as the slicer macro i will not push this to master. I may release it in a dev-branch if someone likes to test it, but i'm pretty absorbed by other stuff so, don't expect it soon

[dapostol73]

A dev branch would be cool, then we could at least test and maybe help isolate the problem.

[ckvsoft]

Is there anything new about this? I can't find the dev branch either.

[FrYakaTKoP]

sorry, no news so far. I'm busy with other stuff right now, but will look into it in next couple weeks.

[Sonicboom247]

I would gladly test this, it works perfectly in Repetier, not sure how they are doing it but my guess is it is at every layer change when it passes the same exact location.

[ckvsoft]

I know I was using RepetierServer in the pro version, which is why I was surprised that it was so difficult to determine the layer change. I now use another slicer because I can set it without an extra plugin. Furthermore, I provide the file name with TL so that I know later that TL is active and I don't have to slice again. Something was written above about a dev branch, but I can't find it. I've already given up hope.

[ckvsoft]

Is it so difficult to tell the difference between a layer change and a ZHop? A layer change raises the nozzle, a ZHop raises the nozzle and then goes down again.

[zellneralex]

@ckvsoft yes as klipper does not look in the future in the movement queue. So what you see is a up movement in z. That it might move down sometimes later is not known at that moment. The reason why Repetier or Octoprint can detect it is that both a gcode streamer, there the whole gcode execution is done by them and klipper acts like in the same way as Marlin. In the use as we do it klipper/moonraker/UI the whole print is executed insight klipper so to get a feature like take_frame without a gcode macro you would need to develop and then merge the feature direct in klipper

Its a equal problem like https://github.com/Klipper3d/klipper/pull/5726 where we ended adding a macro that the user needs to add to there slicer.