Curious DRO behavior

[cncdrive]

As Rob said an issue like that can happen if the VRAM is too low.
The problem with that is that if the graphic images do not fit into the VRAM then OpenGL will have to copy the images from RAM to VRAM as the UCCNC goes through the image drawings.
Normally these things happen in the VRAM and handled directly by the GPU without any CPU and RAM interaction, but if the images do not fit into the VRAM then OpenGL have no other choice than to copy/replace things continously and that can lead to an overload of the CPU and GPU too and can slow the computer and the graphics down, because there is a high screen refresh rate used in the UCCNC for smooth drawing.

[spumco]

Thanks all for the suggestions. Also noticed that the toolpath display is very jerky when the DROs are acting up.

Vram is not adjustable in bios, and only using 45% of system ram while running uccnc. Not sure 4g more ram will make any difference in graphics performance.

Also does it in demo mode and offline mode regardless of which profile is loaded. Tried rolling back gpu driver with no improvement.

The only difference (besides 1.2047 vs 1.2102) between now and a couple months ago when I used the pc on my mill is a different monitor and the uccnc units (mm vs inch) settings are different. Neither of those should make the slightest difference in graphics performance.

Ill try loading a later test version to see if that changes anything. Aftr that, Im just going to live with it.

[cncdrive]

V1.2102 might use more video memory in some cases than 1.2047.
The difference between the 2 versions is that the 1.2047 used simple vector array to draw the toolpath and the 1.2102 using vertex buffer object (VBO).
Usually VBO is faster and is more efficient than vector arrays, because the vectors data is put into the VBO which is in the VRAM and a pointer is used to use the object later.
So, the VBO needs no updates and so it is fast especially on large arrays of vertices (large toolpath). Vector arrays usually have to be updated. (It is a bit complicated to explain so I don't go into more details now...)
But you have to remember that OpenGL is just a standard and how well and efficient the different methods work depends on the video card manufacturer, I mean how well they implemented the different methods.
Usually manufacturers follow the standards closely and implementing things pretty well, but sometimes there are bugs in different methods.
Just an example in many integrated Intel GPUs the line smoothing works pretty rought. When enabling line smoothing on those cards the lines not getting smoothed, but instead they getting even more pixellated.
So, I can think of that VBO handling is not implemented properly on the graphic card you have.

Is it is mini PC or can you fit another graphic card to try?

And RAM usage has not much to do with the issue I described previously. The VRAM needed by the UCCNC is only about 200Mbytes and so you will not see in RAM usage if this data is in the RAM and is copied continously back and forth between the RAM and VRAM. And OpenGL handling these things automatically without any programmer code. The programmer can only advice (give a hints) to OpenGL to possible what to do if something is wrong, but you cannot tell OpenGL exactly what to do in case of issues. OpenGL is who finally will decide.
OpenGL is really complex, so it is a bit hard for me to describe these things, I can say it is about as complicated as coding motion control.

One idea I have is that you could try this little software tool: https://www.techpowerup.com/gpuz/
It shows properties of the graphics card like the GPU and VRAM usage.

[spumco]

Mini pc, so Im stuck with the graphics.

We just repurposed this pc for the plasma build since I upgraded the mill computer to one with better graphics

Ill see if the later version makes a difference, but Andrew from Neuron told me to use 1.2047 for plugin compatibility.

[dezsoe]

The only difference (besides 1.2047 vs 1.2102) between now and a couple months ago when I used the pc on my mill is a different monitor and the uccnc units (mm vs inch) settings are different. Neither of those should make the slightest difference in graphics performance.

If your new display has a higher resolution than the old one then that may be the problem. To check if this is the case, try to set a lower screen resolution. Also, if you have a high enough resolution display, Win8 may set text size other than 100%, which may also slow down graphics.

[spumco]

Dezsoe may be on the right track.

The new monitor (touch screen) has a higher resolution than the previous one. Changing the resolution improved the DRO and tool path behavior a bit. Not back to 'normal' - but a bit better.

Switching to v1.2101 didn't make a difference. I'll try 1.2102 and see if that changes anything, but I suspect the Neuron plugin won't work past 1.2101.

Again, I don't think this has much, if anything, to do with UCCNC, but I certainly appreciate the help from everyone here.

-Ralph