DRO anomoly with g68

Hi TP

Actually, I think i understand almost exactly what is going on here. Fixing it would require a change to a fairly fundamental data structure - the data buffer, and that's why I suggested it would require Mach4 rather than just an update to Mach3.

The data buffer holds 'steps' of movement. Each step has certain data in it: X, Y, Z, A, B, C, time and maybe (don't know) one or two other things as well. The graphics display uses this data to update the on-screen display - usually correctly. It has the time variable to help it, as does the SmoothStepper.

However, to update the DROs requires at least one other bit of information, and that is rotation applicable to each step of data. That information is NOT in the step data buffer. Instead the DRO display routine uses the current rotation angle, and as we now know that can be wrong if the system is calculating many steps ahead. Cut down the look-ahead to somehting like 2 steps and the system usually does have access to the right rotation value.

To fix this problem would require that the data structure for the buffer be expanded to include rotation, and that would have many implications for the whole program. In principle it should be fairly easy to do, IF and ONLY IF, the software has been written in a modular or parametric manner. If it hasn't ... then a complete rewrite of some parts is indicated.

But then, the whole problem with subroutine nesting suggests that a complete rewrite of some parts of the code is required anyhow. Hum-tiddy-um.

Sorry about the techie details, but in another life I designed and wrote that sort of system software, for Real-Time systems and robots etc.. (Yes, they all worked.)

Cheers