Probing not saving

So after a frustrated day i am asking for help.
I have had my system running 2.9.2 for a good 6 months and doing regular updates with no issues, it seems though in the last update i am no longer able to complete a corner probe sequence. It runs the probe but then resets the screen and then just sits there with a spinning icon just under the cursor and the GUI never comes back to life. i can change tabs but not press any buttons.

Even if i do a e-stop it kills the machine but still i get the circle of death. Figuring it was something to do with my install i re-installed from the iso today and configured everything back up to what is a working system apart from the probing. (It will do a probe of z without getting the death circle) 



Steps taken to reproduce the error.
install from new 2.9.2 ISO
Remove brltty
Run LCNC
Install Probe basic following (kcjengr.github.io/probe_basic/quick_start_apt.html, Did not need to add in the keys as it seems that the 2.9.2 iso sources were able to install probe basic from apt.)
Copy my known good configuration that has been running for months over, home, load probe and go to probe xyz of a feature. 
Probe route completes and GUI sets x0 y0 z - offset as expected but control dosnt return to the GUI icon of the mouse pointer changes to have a spinning circle under it and just says like that.

Then to make sure that it was not any of the existing probing routines that i had i copied all the probe* ones from the subroutines folder under probe basic config to my config and same results.

As the zero's were set before it hangs i can then do a alt F4 for probe basic / lcnc and then re-open and go to where the 0,0,0 is set and it seems spot on just sub optimal cant do it without closing the app.

Any thoughts or things i could check would be greatly taken. 

This won't help you but:

The 2.9.2 ISO has the QTPYVCP repositories set up for you so its just a matter of sudo apt install to install their packages. However QTPYVCP is not in step with the linuxcnc release process, so its possible  a newer version on their repo has broken things.

I am surprised britty was installed becasue we tell the installer to  supress its installation.

daveyr wrote:

So after a frustrated day i am asking for help.
I have had my system running 2.9.2 for a good 6 months and doing regular updates with no issues, it seems though in the last update i am no longer able to complete a corner probe sequence. It runs the probe but then resets the screen and then just sits there with a spinning icon just under the cursor and the GUI never comes back to life. i can change tabs but not press any buttons.

Even if i do a e-stop it kills the machine but still i get the circle of death. Figuring it was something to do with my install i re-installed from the iso today and configured everything back up to what is a working system apart from the probing. (It will do a probe of z without getting the death circle) 

Steps taken to reproduce the error.
install from new 2.9.2 ISO
Remove brltty
Run LCNC
Install Probe basic following (kcjengr.github.io/probe_basic/quick_start_apt.html, Did not need to add in the keys as it seems that the 2.9.2 iso sources were able to install probe basic from apt.)
Copy my known good configuration that has been running for months over, home, load probe and go to probe xyz of a feature. 
Probe route completes and GUI sets x0 y0 z - offset as expected but control dosnt return to the GUI icon of the mouse pointer changes to have a spinning circle under it and just says like that.

Then to make sure that it was not any of the existing probing routines that i had i copied all the probe* ones from the subroutines folder under probe basic config to my config and same results.

As the zero's were set before it hangs i can then do a alt F4 for probe basic / lcnc and then re-open and go to where the 0,0,0 is set and it seems spot on just sub optimal cant do it without closing the app.

Any thoughts or things i could check would be greatly taken. 
 

are you running any major customizations for the configs?  maybe a conflict somewhere?  or a missing var parameter?  try copying over the var file from the sim config and running a probing routine see if that resolves.  I have not yest experienced this issue myself but will try and duplicate.  any additional info is helpful!

Thanks,

Chris
 

Was able to duplicate,  checking into it now. 

a fix has been posted and an apt update should resolve the issue! Sorry for the inconvenience, these things do happen! but should be good to go! please report back and let us know if your issue is resolved after the latest apt update!

Thanks,

Chris

Given it was my change that inadvertantly caused this I feel a little obliged to add some more context.

Changes had been made to prevent inadvertant UI events from causing potentially unexpected machine movements after a long program file load (very very large files could take in excess of 30 seconds).  Part of the aim was to not have the machine state go straight to AUTO on prog load. The desire was to leave machine state unchange so as to allow a more natural work flow (based on some feedback).

So a system of UI locking was introduced to prevent stray widget events that could cause machine movement from happening at the end of program load.  Unfortunately I missed a matching "unlock" inside the VTK (plot) widget under a specific scenario that I had not envisioned.  For some reason an mdi call to sub ngc caused a program load event, even though no prog was actually being loaded.  As a result the vtk load handler exited early as file-name var was empty, thus resulting in the closing UI unlock call not happening.

One line added fixed this omission.

Sorry for the pain, testing didn't envisioned this behaviour in sub calls so didn't cover it.

Regards - J.

Confirmed Chris that it is working.

Thank you very much for the quick response.

Thank you very much for the explanation for the issue Joco.

Glad to have found the issue early on and hope that my statement of frustration was not taken as directed at any of the dev team. It was more that my Linux knowledge was not enough to get me back up and running . On the bright side i now better documented build vs what i was having to do when it was build from script

Thank you all for the work that you do and the progress that is being made.