Probe Screen Really Slow

I'm still in the "setup everything" phase and just added the probe screen (github.com/linuxcnc-probe-screen/probe-screen-ng) to my install.

It all seems to be working, but there are huge delays (5+ seconds) between most move when probing. I *think* the delays may be between subroutine calls in the macros but I'm not 100% sure of that.

When doing a simple Z height probe, after clicking the icon it doesn't do anything for 4 seconds, does the whole probe routine as expected, then sits around for 6 seconds before showing the result. The more complex probes (corners, etc) are worse and pause between each movement.

I had written my own basic probing macros before discovering the probe screen and my macros run quickly as expected.

Is this something inherent with how it works (python?) or is something wrong with my setup?

For what it's worth, I'm using GMOCCAPY 3.0.9.1 and Linuxcnc 2.8.1

Thanks,
Justin

I had the same issue. NG probe worked perfectly with axis and very slow with gmoccapy. I spent many time to trying to force to work probe screen with gmocappy interface. In my case decision was this variation of probe screen - github.com/GuiHue/probe_screen_v2
This screen have issues too, not work manual movement and after any action with probe always moves to mdi section. But rest of it work fine and fast with gmoccapy.

I found the bug. After messing around with GladeVCP and python I realized any delays were definitely from their code and not inherent with LinuxCNC.

On line 135 in base.py, they had time.sleep(ms / 100) which should've been time.sleep(ms / 1000)

This was making every check for errors on GMOCCAPY take 10x as long as they should (3 seconds instead of 0.3)

Hello

Yes but i suspect that kiall is no more active and i don't have the write access...

I have my own fork that use different macro logic but python code is really similar.

I also found through more testing it needs to be 1000.0 not 1000 or it is doing integer math and rounds down to 0.

Edit: Apparently in Python an int/int becomes a float so I'm not sure why it wasn't working with 1000 but is working with 1000.0 for me.