Invalid Buffer Times

[gnrules]

Hi Tom,
I found a strange problem with trajectory planner.
I'm using 4.35f with Trajectory planner patch (we discussed of a smoothing problem and the patch on march 2021) and occasionally the interpreter stops with "ERROR - Invalid Buffer Times in Trajectory Planner".
It is something due to trajectory smoothing because changing the parametres it disappears.
I identified a code segment that reproduces the problem (see attachemnt).
The original TP params were:
Break Angle = 40 deg
Corner Tolerance = 0.01 mm
Collinear Tolerance = 0.0 mm
Facet Angle = 1.0deg
with those params around N50496 in the attached code the TP stops executing and reports the error in the console (also the buffer is corrupted and I have to power cycle kflop to start again).
If I change BA under 26deg or change FA to other values (I tried 1.5, 1.25, 0.75 and 0.25) all is ok.
I plotted Gcode segments and angle change around N50496 is 26.9 deg. So i tried 26 deg -> OK, but 27 deg is not. The supsect is corner smoothing obviously, but it happens only with 1.0 deg Facet Angle.

I tried with both our machine (fully cabled and all bells and whistles running on it) and a simple setup with only PC and Kflop with a stripped down Init.c program configured with step dir axes. The problem is perfectly repeatable.
Please can you give me some hints to sort out this problem?
Thanks

Best regards

Giancarlo

[TomKerekes]

Hi Giancarlo,

Its good you are able to reproduce it. But I haven't been able to reproduce it. Please send your GCodeConfigCNC.txt file so that I have all your exact setttings. Please post your simplified Init.c file as well.

I did a fresh install of V4.35f and installed the patch from here:
https://dynomotion.com/Software/Patch/I ... ng_V4.35f/

[gnrules]

Hi Tom,
thank you for you quick reply, but I think I have to double check my installation. After your reply, I tried to replace GCodeInterpreter.dll with the patched one directly downloaded from your link and the problem disappeared.
It is weird because they have very close timestamp (1 minute difference) of the file I was using, but mine is somehow corrupted.
Maybe it was a local build with some sort of attempt to solve the smoothing issue... I don't know; Anyway the problem is solved.

Sorry for the false alarm!
Thank you very much for your support.

Best regards

Giancarlo