I have added it to my checklist. But from tests with repetier binary protocol which has even higher compression I know the difference is not that great. Using Repetier-Server parallel commands instead of ping pong has a much higher impact. Reason is that with serial-usb converter the packet latency has a quite big influence. And for boards with native usb connection the baud rate is not used, but usb speed so here effect is marginal.
The positive effect in non ping-pong mode is that we can then buffer more commands and it is also possible to send more emergency commands. Hope to find the thread where they explain the format in detail. Or I check it's conversion in octoprint.
I am running printers that only use "Marlin" as the firmware so I am not sure they can understand the "Repetier Binary" protocol.
I am hoping to help with the "smoothness" of the command stream as sometimes when printing large objects I can see/hear where specific commands are issues as I see/hear a tiny pause in the printing, almost just a "stutter".
It is more evident on long, but not straight, runs as it SHOULD just be a long smooth run, but it ru ns almo st smoo thly but has hic cups that are ba rely perce viable but has to be pla ying hav oc with print times.
Marlin does not understand repetier binary protocol.
In communication settings you can test communication speed for your board. Speed varies between 150 and 1000 lines per second. Also depends on how much time firmware needs to parse of course. You can test there also non ping pong modes and see the speed difference for long and short commands.
I had a closer look and no wunderstand how meatpack works. It compresses 15 important chars (0-9, ., G, X, \n) and count on them being more then 50% of chars in line to get compression of max. 50%. For move commands this is true and since they are the majority of commands it works good. Will try to implement it, should be possible the way we work. But I also expect it to have the best effect with non ping pong mode as it is the only way to send more commands per package delay. Also you should active line numbers for ok to allow Repetier-Server to detect lost "ok" so it never losses the benefit of parallel commands and also activate "wait" if you are already at config_adv.h.
Ok, yesterday I added meatpack support to Repetier-Server. In nightly linux build you can already use it.
At least on my test machine (anycubic mega i3 with knutwurst marlin firmware) it worked well and improved throughput by a few percent. Could reach up to 800 lines/s of moves compared to 600 without for longer G commands like moves with 255 byte buffer in parallel mode. How much it improves depends on the latency of usb channel in OS and on printer side. Best will be with direct native serial communication bypassing usb completely which has no latency. On the other side you can normally print well with 200lines/s.
Best improvement is that it reduces by around 40% buffer usage so in parallel mode it can buffer more commands which is also why we get that improvement in speed. But it also allows more emergency commands to be send before buffer is full.
You need to activate "Enable compression if supported" in Printer Config->General->General to activate it. See compression results with @meatpackStatus
Windows needs to wait for release as it gets no nightly versions. But latest test prints now worked. It's a bit more sensitive to errors since the compression causes completely different content, but especially without ping pong it works quite well and fast.
Comments
The positive effect in non ping-pong mode is that we can then buffer more commands and it is also possible to send more emergency commands. Hope to find the thread where they explain the format in detail. Or I check it's conversion in octoprint.
I am hoping to help with the "smoothness" of the command stream as sometimes when printing large objects I can see/hear where specific commands are issues as I see/hear a tiny pause in the printing, almost just a "stutter".
It is more evident on long, but not straight, runs as it SHOULD just be a long smooth run, but it ru ns almo st smoo thly but has hic cups that are ba rely perce viable but has to be pla ying hav oc with print times.
In communication settings you can test communication speed for your board. Speed varies between 150 and 1000 lines per second. Also depends on how much time firmware needs to parse of course. You can test there also non ping pong modes and see the speed difference for long and short commands.
I had a closer look and no wunderstand how meatpack works. It compresses 15 important chars (0-9, ., G, X, \n) and count on them being more then 50% of chars in line to get compression of max. 50%. For move commands this is true and since they are the majority of commands it works good. Will try to implement it, should be possible the way we work. But I also expect it to have the best effect with non ping pong mode as it is the only way to send more commands per package delay. Also you should active line numbers for ok to allow Repetier-Server to detect lost "ok" so it never losses the benefit of parallel commands and also activate "wait" if you are already at config_adv.h.
At least on my test machine (anycubic mega i3 with knutwurst marlin firmware) it worked well and improved throughput by a few percent. Could reach up to 800 lines/s of moves compared to 600 without for longer G commands like moves with 255 byte buffer in parallel mode. How much it improves depends on the latency of usb channel in OS and on printer side. Best will be with direct native serial communication bypassing usb completely which has no latency. On the other side you can normally print well with 200lines/s.
Best improvement is that it reduces by around 40% buffer usage so in parallel mode it can buffer more commands which is also why we get that improvement in speed. But it also allows more emergency commands to be send before buffer is full.
You need to activate "Enable compression if supported" in Printer Config->General->General to activate it. See compression results with
@meatpackStatus
and reset usage counter with
@meatpackResetUsage
Will look for it in the Windows version sometime in the future....