wait_complete()
- RKtech
- Offline
- New Member
-
Less
More
- Posts: 4
- Thank you received: 2
30 Aug 2021 12:27 - 30 Aug 2021 12:38 #219162
by RKtech
wait_complete() was created by RKtech
Hi,
I had some issue with the command.wait_complete() command when using with command.mdi().
My system:
- Linuxcnc 2.8.2
- Linux 4.19.0-17-rt-amd64 #1 SMP PREEMPT RT Debian 4.19.194-3 (2021-07-18) x86_64 GNU/Linux
- MESA 7i95
When I installed PSNG (github.com/linuxcnc-probe-screen/probe-screen-ng) first it seems to work, but when using larger clearence values, the sensor didn't do the correct movements (at the end the sensor will not move to the end position but stops some way before)
After some experiments I figured out, that the G commands are calculated correctly, but the move wasn't finished. So I observed the wait_complete() command and found, that it allways returns with the return Value "1" after longest 150ms even if the move will take much longer. Also giving a higher timeout will not help, because it didn't timeout anyway..
Currently I have implemented a workaround where the MDI cammands are handled:
which give me this result:
what I'm using here is, that if I put something (even a comment like ";workaround") into the MDI the wait_complete() will return within 10ms if it is idle or >100ms if there is some movement.
When wait_complete() need more then 50ms to return I repeat sending this "MDI" command otherwise it is finished.
With this workaround everything works fine (for PSNG) now, but I see a lot of other places (not only in PSNG) where this wait_complete() is used.
Could someone advice me to figure out why this command it is working so odd on my mashine? (I couldn't belive that nobody else had this issue without notyfiing it)
THX
I had some issue with the command.wait_complete() command when using with command.mdi().
My system:
- Linuxcnc 2.8.2
- Linux 4.19.0-17-rt-amd64 #1 SMP PREEMPT RT Debian 4.19.194-3 (2021-07-18) x86_64 GNU/Linux
- MESA 7i95
When I installed PSNG (github.com/linuxcnc-probe-screen/probe-screen-ng) first it seems to work, but when using larger clearence values, the sensor didn't do the correct movements (at the end the sensor will not move to the end position but stops some way before)
After some experiments I figured out, that the G commands are calculated correctly, but the move wasn't finished. So I observed the wait_complete() command and found, that it allways returns with the return Value "1" after longest 150ms even if the move will take much longer. Also giving a higher timeout will not help, because it didn't timeout anyway..
Currently I have implemented a workaround where the MDI cammands are handled:
def gcode(self, s, data=None):
time_start_RK = time.time() #RK debug
self.command.mode(linuxcnc.MODE_MDI)
self.command.wait_complete()
max_idle_time_RK = time.time()-time_start_RK
print('RK - 0, Workaround in ".../psng/python/base.py"') #RK debug
print("RK - 1: %f ; switch to MDI time" %(max_idle_time_RK)) #RK debug
for l in s.split("\n"):
# Search for G1 followed by a space, otherwise we'll catch G10 too.
if "G1 " in l:
l += " F#<_ini[TOOLSENSOR]RAPID_SPEED>"
self.command.mdi(l)
time_start_RK = time.time() #RK debug
a_RK = self.command.wait_complete()
time_duration_RK = time.time()-time_start_RK
print("RK - 2: %f ; %i ; %s" %(time_duration_RK, a_RK, l)) #RK debug
if self.error_poll() == -1:
return -1
#RK debug
while True:
self.command.mdi(';workaround')
time_start_RK = time.time()
a_RK = self.command.wait_complete(5.0)
time_duration_RK = time.time()-time_start_RK
print("RK - 3: %f ; %i ; loop workaround" %(time_duration_RK, a_RK)) #RK debug
if self.error_poll() == -1:
return -1
if time_duration_RK < max_idle_time_RK:
break
return 0which give me this result:
...
RK - 0, Workaround in ".../psng/python/base.py"
RK - 1: 0.041228 ; switch to MDI time
RK - 2: 0.010244 ; 1 ; G91
RK - 2: 0.142202 ; 1 ; G1 X15.000000 F#<_ini[TOOLSENSOR]RAPID_SPEED>
RK - 2: 0.132048 ; 1 ; G90
RK - 3: 0.142770 ; 1 ; loop workaround
RK - 3: 0.112120 ; 1 ; loop workaround
RK - 3: 0.142459 ; 1 ; loop workaround
RK - 3: 0.010268 ; 1 ; loop workaround
...what I'm using here is, that if I put something (even a comment like ";workaround") into the MDI the wait_complete() will return within 10ms if it is idle or >100ms if there is some movement.
When wait_complete() need more then 50ms to return I repeat sending this "MDI" command otherwise it is finished.
With this workaround everything works fine (for PSNG) now, but I see a lot of other places (not only in PSNG) where this wait_complete() is used.
Could someone advice me to figure out why this command it is working so odd on my mashine? (I couldn't belive that nobody else had this issue without notyfiing it)
THX
Last edit: 30 Aug 2021 12:38 by RKtech.
Please Log in or Create an account to join the conversation.
- RKtech
- Offline
- New Member
-
Less
More
- Posts: 4
- Thank you received: 2
31 Aug 2021 15:52 #219262
by RKtech
Replied by RKtech on topic wait_complete()
Update:
It is (for sure) no linuxcnc issue. I wrote a short python script by myself and here the wait_complete() is working exactly as expected. So I have to dive more deeply into the PSNG code ...
It is (for sure) no linuxcnc issue. I wrote a short python script by myself and here the wait_complete() is working exactly as expected. So I have to dive more deeply into the PSNG code ...
Please Log in or Create an account to join the conversation.
- natester
- Offline
- New Member
-
Less
More
- Posts: 8
- Thank you received: 4
20 Oct 2024 01:37 #312645
by natester
Replied by natester on topic wait_complete()
Did you ever figure this out? I also found this bug in probe screen v2.8: github.com/verser-git/probe_screen_v2.8/...probe_screen.py#L341
Increasing the timeout makes no difference as wait_complete always returns immediately. I'm also on linuxcnc 2.8.4
Increasing the timeout makes no difference as wait_complete always returns immediately. I'm also on linuxcnc 2.8.4
Please Log in or Create an account to join the conversation.
- natester
- Offline
- New Member
-
Less
More
- Posts: 8
- Thank you received: 4
20 Oct 2024 13:22 #312672
by natester
Replied by natester on topic wait_complete()
The fix you posted didn't work for me as my wait_complete returns within .1s every time.
Instead, I just polled the interpreter state like so:
Instead, I just polled the interpreter state like so:
@restore_task_mode
def gcode(self, s, distance=None, data=None):
self.command.mode(linuxcnc.MODE_MDI)
self.timed_wait_complete()
for l in s.split("\n"):
# Search for G1 followed by a space, otherwise we'll catch G10 too.
if "G1 " in l:
l += " F#<_ini[TOOLSENSOR]RAPID_SPEED>"
time_in = 5
if distance is not None:
# set a non-default wait limit for wait_complete()
time_in = 1 + (distance / self.ps_rapid_speed ) * 60
#print("probe_screen time_in=", time_in)
#print("probe_screen:\n", l)
self.command.mdi(l)
self.timed_wait_complete()
if self.error_poll() == -1:
return -1
self.stat.poll()
# wait for the interpreter to return to idle state
while self.stat.interp_state != linuxcnc.INTERP_IDLE:
#print("probe_screen: interp_state=", self.stat.interp_state)
if self.error_poll() == -1:
return -1
self.command.wait_complete()
self.stat.poll()
self.command.wait_complete()
if self.error_poll() == -1:
return -1
return 0Please Log in or Create an account to join the conversation.
- zz912
-
- Away
- Platinum Member
-
Less
More
- Posts: 582
- Thank you received: 94
07 Dec 2025 20:50 - 07 Dec 2025 20:51 #339832
by zz912
This line:
time_in = 1 + (distance / self.ps_rapid_speed ) * 60
github.com/verser-git/probe_screen_v2.8/...probe_screen.py#L338
It doesnt calculate with ramps, so time cant be enough.
I preffer use long time:forum.linuxcnc.org/38-general-linuxcnc-q...ete-timed-out#296683
Replied by zz912 on topic wait_complete()
Did you ever figure this out? I also found this bug in probe screen v2.8: github.com/verser-git/probe_screen_v2.8/...probe_screen.py#L341
Increasing the timeout makes no difference as wait_complete always returns immediately. I'm also on linuxcnc 2.8.4
This line:
time_in = 1 + (distance / self.ps_rapid_speed ) * 60
github.com/verser-git/probe_screen_v2.8/...probe_screen.py#L338
It doesnt calculate with ramps, so time cant be enough.
I preffer use long time:
timeout = 600
result = self.command.wait_complete(timeout)
if result == -1:
print( 'Command timed out: ({} second)'.format(timeout))
Last edit: 07 Dec 2025 20:51 by zz912.
Please Log in or Create an account to join the conversation.
- jcdammeyer
-
- Offline
- Senior Member
-
Less
More
- Posts: 73
- Thank you received: 8
07 Dec 2025 23:32 #339842
by jcdammeyer
Replied by jcdammeyer on topic wait_complete()
I'm using a slightly older version of the probe screen so the gcode() method is in base.py. I haven't upgraded. I suppose I should.
I'm running axis 2.8.1.
I like the idea of the INI file value [TOOLSENSOR]RAPID_SPEED being used for the movement to/from the start search position. I could then even use F50 for example after tool is up above the work piece. Then when it reaches the other end it goes back to self.ps_rapid_speed from the probe screen parameter which I have set at 10.
However somehow although it works on Thonny the
if "G1 " in l:
l += " F#<_ini[TOOLSENSOR]RAPID_SPEED>"
is not working. And setting the box on the probe screen to 50 for rapid has the risk of breaking the probe. Actually anything above about 20 has that risk.
I'm running axis 2.8.1.
I like the idea of the INI file value [TOOLSENSOR]RAPID_SPEED being used for the movement to/from the start search position. I could then even use F50 for example after tool is up above the work piece. Then when it reaches the other end it goes back to self.ps_rapid_speed from the probe screen parameter which I have set at 10.
However somehow although it works on Thonny the
if "G1 " in l:
l += " F#<_ini[TOOLSENSOR]RAPID_SPEED>"
is not working. And setting the box on the probe screen to 50 for rapid has the risk of breaking the probe. Actually anything above about 20 has that risk.
Please Log in or Create an account to join the conversation.
Time to create page: 0.132 seconds