Work with probe

I have tried to install alkabal's PSNG Master, because I'm on 2.9...

Linuxcnc ver: 2.9.0-pre1-1066-g8fd469d67
Linux Bookworm, kernel 6.1.0-11-rt-amd64

I have reached the point of having a blank tab where it says PSNG

I have tried to follow all the instructions as closely as possible. I downloaded from the PSNG_V3 / Master branch on August 10, 2023

Any quick ideas?

(Thanks, btw, this is great work)

Initial fiddling at the .ini file stage suggests that if I remove from the
EMBED_TAB_COMMAND
line the "-H nc_subroutines/psng/psng.hal" part, then at least the graphic displays inside the tab.

So that suggests something in the psng.hal is essentially 'crashing' in a way that disables the gladevcp.

I am too tired now but will try to crawl though that tomorrow.

Thanks again.

@ Vector
I think you have the wrong package

Use the one listed here forum.linuxcnc.org/49-basic-configuratio...obe?start=640#276444

- install using the instructions from github.com/verser-git/probe_screen_v2.8
Both folders:
/python
/psng

need to be copied or linked under ~/linuxcnc/configs/machine-name/

You can run it from a terminal and look at the errors - if that doesn't work you might have to turn on debug.
From what you describe, it is something in the ini file? If you have other glade bits, they might interact?

Some of the install instructions are in psng/

I got it to work - could probe and zero -- BUT if I tried to run a program it claimed the tool change point was wrong.. The example section  for [CHANGE_POSITION] had a silly Z = 60 which threw an error - but even when I corrected that it fails.
(See forum.linuxcnc.org/49-basic-configuratio...obe?start=660#277493 )
I'm guessing the out of range is a result of the other error.
,.,.

I've started collecting some messy notes here:
lrak.net/wiki/LinuxCNC.html#mozTocId149313

I have never created a github source - wasn't sure what people here wanted to do - seems it should be yet another version called probe_screen_2.9 .

If you find what makes it work - send me an email

Hey Irak, I tried that package (probe_screen_v2.8) first, on about 8/7/23, and also tried probe-screen-ng on about 8/10/23.

I believe neither could work because both were giving me python 2 errors. I think I was trying to get them to work on gmoccapy.

Unless I've gotten confused. (Definite possibility).

Are you saying you got this one to work: Probe_screen_v2_8 to work?
And you got it to work on LinuxCNC version 2.9?
And you were on which GUI?

(And thank you)

OK, even though Irak thinks I'm on the wrong path, until I hear back, and because I actually think I'm close, I'm going to try and post where I'm at with trying to get this version of the toolprobe gui working under Axis: github.com/alkabal/PSNG_V3/tree/Master

I'm working that one because it's the only one of the bunch that Irak lists back on page 64 of this thread (wherein everyone agrees this has gone crazy) which claims specifically to work for LinuxCNC Version 2.9.

The good news is the screen does work and display, so the python2 vs. python3 issues that I had trying to make other packages work are not a problem (at least under the AXIS GUI. While I'd be frankly happy to switch to gmoccapy or QTDragon, I've made more progress here on axis thatn gmoccapy, and QTD has only just posted the source fixes to support 5 axes, which is what I need, so for now I'm sharing and crunching on axis).

So.... question for the community:

What are the pros and cons of the following in your .ini file, in the [DISPLAY] section:

vs

From what I can see, option 1 has the advantage of not crashing if there's an error in the .hal file being pushed to the glade file by the -H switch, and of finally delivering a very zen-experience fully-grey screen (ie, no functioning glade on the probe tab). Oops, mostly this is a disadvantage.

Option 2 has the dis-advantage of crashing before starting LinuxCNC if there's a problem in the .hal file, and then telling you error screen exactly what the problem is. Ooops, I did it again: seems like mostly an advantage.

But is there a good reason for passing the .hal file in the gladevcp command?

Anyhow, the problem with the (attached) .hal file appears to be: "Pin 'probe.toolchange_change' does not exist." 

So I'm going to post this while I try to figure out what was intended in probe.toolchange_change, and therefore how to fix it.
(my first guess is that the reason one needs to send the .hal file on the gladevcp command is that this pin is possibly defined in there, and the hal is crashing on me because it can't possibly connect to it's glade definition, in which case I still won't know why there's a grey zen-screen on the probe tab)

Cheers!

OK, I think I'm making progress.

Yes, I think my surmise that one must include the hal component in the EMBED_TAB_COMMAND is correct, because after using the terminal logging approach, it turns out the error is:
and the line 22 in the hal file is:

And the comment above that is: "Z_EOFFSET_COMPENSATION component you need sudo apt-get install python-scipy"

And then sceeerch... I'm on Bookworm, and bookworm has, you guessed it, not python-scipy in the repository.

Fork in the road perhaps... does Precious need Z_EOFFSET_COMPENSATION?? And if Precious does, then where is it, Precious?!?

I've attached Preciouses' terminal log output (go straight to the end) and the psng.hal file that's being fed to the psng_mod.glade.

Doh! There's no python-scipy, but there IS python3-scipy.
But No, once that's installed, the error stays the same.
But Yes, if we change the line to:

loadusr -Wn probe.compensation python3 ./nc_subroutines/psng/python/compensation.py

...

The errors change and Lo! (choral music plays)

The screen hath appeared.

Testing will have to wait until tomorrow, I've opened an issue on alkabal's project page for PSNG_V3 to alert him to the documentation and changes for Debian 12. 

Thank you for everyone being there to let me text out loud while I work this through.

And does anyone know what that message is trying to communicate: "Restore modal status using fixed startup value?"
 

Yes, I found that by the next post... and then the line inside the psng.hal (which was passed into the glade display) has to change it's loadusr to use python3 too.