by Robertspark » Wed Oct 10, 2018 6:49 am
Oh, are you doing this on the fly?
if the machine is moving then you would need to use stream reader to read the current or next gcode line, and also the current work coordinates,
subtract the current work from machine coordinates to give you the current offset, and the subtract that from the gcode coordinates
dont forget uccnc buffers data and shifts it to the motion controller so that the motion controller will do all the timing, and the buffer allows for any windows delays,
windows is not real time, and does not have a real time kernel. Linuxcnc does .... but technically there is still a delay.... just its very small (subject to pc, network connection, processor etc)
in uccnc you only read the data as available which will always be off a bit. I think there is a buffer delay variable somewhere which is used for diagnostics in uccnc that yoy may be able to use to estimate a closer actual prediction using a predictive filter like kalman
- Attachments
-