"rapid retract" - accel/decel interpolation issue?

hello!

this may seem simple to advanced users, but... i just can't seem to figure it out myself

i run code usually at approx. 80 ipm, using emc2 for bot control. at first glance, everything seems to work quite ok. BUT: depending on safe z height (or so it seems), my machine seems to mess up every time it reaches the END of any given toolpath. emc2 shows both g-code and the actual -as is- toolpath, representing actual machine travel. now these two differ!

while ramping in works fine, interpolation seems to mess up the end of my toolpaths. where a straight move to the end of the toolpath should have been executed, in fact some sort of interpolation between last target xyz on the toolpath and the next target that includes rapids seems to occur. what this does is: start of the toolpath is precise and fine, end of the toolpath is not. z-moves at the end of the toolpath are visible where there should be none. it seems to relate to the settings for safe z. i did try a few different settings, but have not been able the elimate the actual cause for this. i can get it down to "quite unnoticeable" but now that i'm aware of it i found traces of this phenomenon in all my workpieces.

does this sound familiar to anyone? am i missing sth.? my guess would be that this behaviour must be related to acceleration and deceleration and that there must be a setting that controls this? any help will be appreciated.

...and this is how it looks like

Thanks! Then it seems that preventing this behaviour would need a G64 P0.10 to ensure a path accuracy that is always at least 1/10 of a millimeter?

Great. Thanks a lot for your help on this one.

I might add: a G64 P0.01 works well most of the time. Although emc 2.3.0 will ignore this at times, stating in MDI that G64 is active. But instead, it seems like it is working in -unprecise- default mode. The toolpaths differ significantly from original design e.g. holes will not be round and the likes. Rather annoying. When this happens you just need to trash your workpiece and enter a G61. This seems fully functional all of the time. But is really slow to work with. Maybe it is time to install 2.4.4?

Thanks a lot John. Fully understood. What I was referring to, though, was a specific behaviour of the g64 command: Surely a change from g61 to g64 is reflected in the display of active g-code. What is not displayed is the precision level of the g64 px.xx. So while I enter a g64 p0.02 I would expect that precison. The issue is: There is no way of knowing what precison level is active (until you see the first erratic move, that is). Now sometimes a p0.02 works (workpieces fitting together nicely) and sometimes it don't. Same g-code, same machine. Usually, running g-code at a precison of 0.02 works fine for my workpieces. What I was trying to point out was that while a g61 and a g64 p00.2 should produce almost the same result, in reality the g64 p0.02 does not work every time. sometimes it does, sometimes it don't. Hope this issue is resolved in 2.4x - I'll be updating soon...

Regards