2024-01-21

Last modified: 2024-01-21 17:33:01

G-code sender

Plan today was to tidy up the DRO a bit, and make a plot of the toolpath. That turned out to be much easier than expected, however I am confused about one thing. The image of the toolpath I draw with Gio UI seems to be laggy, even though I'm plotting coordinates extrapolated based on the velocity, same as for the DRO. I screen-recorded it with OBS to make sure I wasn't just confused, and indeed the plot only updates every 5th frame, even though it should be redrawn just as often as the DRO, and shows the same coordinates as the DRO.

It's not caused by truncating coordinates to integers, because I can draw lines to non-integer coordinates and they work just fine.

Is the Gio image-drawing widget deliberately making sure it only draws every 5th frame, on the basis that it assumes it is drawing a static image?

It does say:

NewImageOp assumes the backing image is immutable, and may cache a copy of its contents in a GPU-friendly way. Create new ImageOps to ensure that changes to an image is reflected in the display of it.

However I think I am creating a new ImageOp every frame.

I tried printing out the address of the image data and it changes every frame, as you'd expect.

The ImageOp creation code has:

    return ImageOp{
        src:    src,
        handle: new(int),
    }

Could the new(int) be getting the same address for 5 frames straight before changing?

I tried printing the handle out and it seems to change every frame too.

I made it draw the path in a different colour every time, and I can see that it actually is redrawing every frame! The colour changes every frame, but the endpoint of the line only changes every 5 frames.

Oh, OK, I can see the problem. My movement extrapolation thinks it is moving quite a lot slower than it really is.

?<Run|WPos:2.256,0.000,0.000|Bf:14,128|FS:432,0>
endpoint = 2.256556
endpoint = 2.258194
...
endpoint = 2.272778
endpoint = 2.274398
?<Run|WPos:3.800,0.000,0.000|Bf:14,128|FS:500,0>

In the time it took to go from X=2.256 to X=3.800 (+1.544mm), my code thought it had only moved about 0.019mm.

If I multiply the velocity by the number of elapsed seconds then it looks to work better.

Ah, d'oh! It's because when I compute the velocity I divided by seconds instead of by minutes. But minutes makes more sense because feed rates are given in mm/min. All sorted now, great success.

Current state: