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 0
which 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 0
Please Log in or Create an account to join the conversation.
Time to create page: 0.056 seconds