linuxcnc-probe-screen / probe-screen-ng Goto Github PK

Hi

change proposition for some fixed lenght

And also

https://github.com/alkabal/probe-screen-ng/blob/cdefdd972b8190ea32e79fa26d33cb983c739ba9/psng/macros/psng_block_down.ngc#L41

Hi

For launching panel it seem to be enough to use : (the actual info in install_add_to_your.ini are not updated)

EMBED_TAB_COMMAND=gladevcp -x {XID} -u python/psng.py -H probe_icons/psng.hal probe_icons/psng.glade

psng.py is not in the python folder

br

Well

studying the axis code try finding a method for intercept the stop button like you do with notification i have see something strange for my undertsanding :

In gmoccapy you can found
notification.add
notification.del_message

in axis
notifications.add
notifications.clear

And you use in axisrc
Notification.add
Notification.remove

uppercase "N"
without "s"
.remove vs .clear

Can you check that please?

Hi.

All in the title

Br

Hi

I'm sorry to ask here, if you are not agree you can close this issue, but maybe this is interesting to add this feature for all

Can i have your opinion :
https://forum.linuxcnc.org/10-advanced-configuration/40817-3d-touch-probe-tool-setter-z-touch#191458

Br

Hi again

Please change inside this file line 49 because G38.4 can cause some trouble.

G38.2 Z #<_ini[TOOLSENSOR]MAXPROBE>
G38.4 Z2
G0 Z0.5
; This is commented out only for sim.
F #<_hal[probe.ps_probevel]>
G38.2 Z-3

to

G38.2 Z#<_ini[TOOLSENSOR]MAXPROBE>
G1 F#<_ini[TOOLSENSOR]RAPID_SPEED> Z2
; This is commented out only for sim.
F #<_hal[probe.ps_probevel]>
G38.2 Z-3

I want to eliminate preview-fails.
In current code, we use only the tool-offset (TLO-Z) to set the height of the tool to the height of the workpiece. I think that is a kind of hack.

Better would be to use correctly the workpiece-offset (G54 etc.) AND the tool-offset
(btw: this is the normal way)

If we do this way, probe-screen can be enhanced with

• persistent-tool-offsets for a defined range of tools (e.g. T50-T99 is persistent, T1-T49 is measured every time)
• persistent-tool-measurement-button

I think many users have only a range of tools which must be measured every time and a set of tools which has the same length for a longer time.

I have understand about error management but this cause some trouble with my hook, maybee you can undertsand

https://github.com/alkabal/probe-screen-ng/blob/cdefdd972b8190ea32e79fa26d33cb983c739ba9/psng/psng.py#L640

https://github.com/alkabal/probe-screen-ng/blob/cdefdd972b8190ea32e79fa26d33cb983c739ba9/psng/my_hook/psng_hook.ngc#L39

Well

I think about the best option so we can use special ohookcode routine without error checking that allow user to do all wanted with less possible issue
M2 inside hook allow user to stop t

and preserve the actual code for probing macro

Imo this is the safest way, I need to do new test with actual code but I have noticed regarding the probing sequence this is a good idea for call hook only at start off each routine

For my use I have also add a hook end function.

what did you think ?

Hi

I have some trouble understanding why we cand found some self.stat.poll() at "random location"in the code

https://github.com/alkabal/probe-screen-ng/blob/cdefdd972b8190ea32e79fa26d33cb983c739ba9/psng/psng.py#L249
https://github.com/alkabal/probe-screen-ng/blob/cdefdd972b8190ea32e79fa26d33cb983c739ba9/psng/psng.py#L288
https://github.com/alkabal/probe-screen-ng/blob/cdefdd972b8190ea32e79fa26d33cb983c739ba9/psng/psng.py#L318
https://github.com/alkabal/probe-screen-ng/blob/cdefdd972b8190ea32e79fa26d33cb983c739ba9/psng/psng.py#L1770
https://github.com/alkabal/probe-screen-ng/blob/cdefdd972b8190ea32e79fa26d33cb983c739ba9/psng/psng.py#L1847
https://github.com/alkabal/probe-screen-ng/blob/cdefdd972b8190ea32e79fa26d33cb983c739ba9/psng/psng.py#L1923
https://github.com/alkabal/probe-screen-ng/blob/cdefdd972b8190ea32e79fa26d33cb983c739ba9/psng/psng.py#L1999

br

Hi

I have many problem using M0 in hook macro

the logic for ocode routine did not manage this correctly and i big trouble understanding what i need to do for deal with that.

So for now i experiment to call hook from python code with special routine that work partialy.
without regarding other change can i ask what did you think about that ?

def ohookcode(self, s, data=None):
    self.command.mdi(s)
    self.stat.poll()
    #self.command.wait_complete()
    print("ohook_start = %s" % self.stat.interp_state)
    while self.stat.interp_state != linuxcnc.INTERP_PAUSED:
        print("ohook_loop1 = %s" % self.stat.interp_state)
        self.command.wait_complete()
        self.stat.poll()

    while self.stat.interp_state != linuxcnc.INTERP_IDLE:
        print("ohook_loop2 = %s" % self.stat.interp_state)
        self.command.wait_complete()
        self.stat.poll()      

    self.command.wait_complete()
    print("ohook_end = %s" % self.stat.interp_state)
    return 0`

`

Br

edit at the end this one work enough :

    def ohookcode(self, s, data=None):
        self.command.mdi(s)
        self.stat.poll()
        print("ohook_start = %s" % self.stat.interp_state)
        print("ohook_start_queue = %s" % self.stat.queue)

        while self.stat.interp_state != linuxcnc.INTERP_IDLE:
            print("ohook_loop2 = %s" % self.stat.interp_state)
            print("ohook_loop2_queue = %s" % self.stat.queue)
            self.command.wait_complete()
            self.stat.poll()
            
        self.command.wait_complete()            
        print("ohook_end = %s" % self.stat.interp_state)
        print("ohook_end_queue = %s" % self.stat.queue)
        return 0

But the problem is next call with regular macro using ocode routine ended with some NML error

Hi

I don't found how to implement that but imo this need to be done if possible.
https://www.google.com/search?q=gtk+set_keep_above(True)&rlz=1C1AVFC_enFR800FR800&oq=gtk+set_keep_above(True)&aqs=chrome..69i57j33i10i160.1784j1j4&sourceid=chrome&ie=UTF-8

Br

Looking through the LinuxCNC source, I spotted this from @c-morley https://github.com/LinuxCNC/linuxcnc/tree/master/lib/python/gladevcp/builtin-panels

It looks like they have been reworking some of the vers.by probe screen into LinuxCNC itself (awesome!) - hopefully we can collaborate somehow - are you interested @c-morley ?

So far, we've been cleaning up the code and fixing the most obvious bugs - but there is defiantly lots more to do :)

Hi

First, thanks for this fork and the work for update !

I have one question why do you keep the use of psng.hal and psng_postgui.hal ?

For what i have try put the line that is alone in postgui inside psng.hal fork fine.

Br

Hi

I hope you a good year !

Another time i come back with the idea to move hook call from macro to python (and add hook_end).

I have noticed than try to use some outside/inside measurement do some move before calling the ocode so the hook is done after first move and imo this is not safe.

What is you opinion ?

Br

A probe screen like this one just can't use M72 or M73 to restore modal states, so the various macros and python are sometimes, but not always, restoring modal states correctly when they finish.

At the start of each macro, we should save all modal states. At the end of each macro (including at error points, or early returns) we must restore the modal states which we haven't explicitly intended to change (e.g. TLOs)

To do this, we have a few options.

1. We can add "modal_save" and "modal_restore" macros which use named global parameters to save and restore all modal state. This is the simplest method, and adds the least code to each of the other macros. However, if a macro calls into another macro, we will loose the original saved state.

2. We can add "modal_save" and "modal_restore" macros which use named local parameters to save and restore all modal state. This could add a lot of code to each of the other macros, but would allow for nested macro calls to work correctly.

3. We can manually use named local parameters to store modal states, and manually restore those states when we leave a macro - this will add even more code than option 2 to the other macros, and would easily get out of sync between the different macros.

I'm not sure which option is ideal... I'll look into seeing if there is a way to make option 1 work with nested macro calls.

A list of modal states can be found here: http://linuxcnc.org/docs/html/gcode/m-code.html#mcode:m70

https://github.com/seebaer1976/linuxcnc/blob/4ba291cf23b3a973feef15eb02148dcb5a6c9813/nc_files/remap_lib/python-stdglue/stdglue.py

Hi

I agree with you for the use of G0 but in some macro this is G1 that is used, i do not want to force to use G1 !!

If you want G0 some other macro need to be edited.

br

Create a simple install / update script. This script should:

1. Copy over the necessary content (macros, psng, python folders)
2. Check the users my-mill.ini file for all required settings - warn the user if any are set incorrectly.
3. Scan any HAL files for any mentions of the manual tool changer and warn if any are found

This should work for both install & update, as it would replace the files and scan the settings again etc - so the same logic can be ran over+over for initial install and later updates.

I suggest a new name for this version of probe-screen.

It´s hard to find for users what is the correct/newest version to use.

"Probe-Screen" was the first name of verser-git´s Initial-Release, verser´s newer screen (base of this fork) is called Probe-Screen-V2. So i think its bad when the newest version has a name that suggests, it is older than its own base.

My idea is simply "probe-screen-v3.0"

move all this code from psng.py to base :

        self.command.mode(linuxcnc.MODE_MDI)
        self.command.wait_complete()

https://github.com/alkabal/probe-screen-ng/blob/cdefdd972b8190ea32e79fa26d33cb983c739ba9/psng/macros/psng_hook_end.ngc

https://github.com/alkabal/probe-screen-ng/blob/cdefdd972b8190ea32e79fa26d33cb983c739ba9/psng/macros/psng_yplus.ngc#L28

1. feature request; account for touch plate thickness when setting Z zero to top of material surface
   At the moment there is not a way of using the probe screen to conduct a touch off with a probe plate. For instance, I use a piece of aluminum on top of the work piece to establish the work piece height.

The Z- button triggers the table probe script, but I had to modify the script to issue a G52 offset command to account for the thickness of my probe plate. It would be great if there was a textbox that allows for the thickness of the plate to be compensated for when doing touch plate probing.

2. feature request: apply a similar offset to account for probe plate thickness when doing corner probing (outside X/Y touch off) It would be great if there was also an offset that accounted for the width of the probe plate when doing X/Y probing. For example, if I use my probe plate for corner finding and initiate the X/Y outside touch off, the thickness of the plate (which in my case is 8mm) is not accounted for. This results in the final zero position being 8mm off from the true corner zero of the piece. I thought the 'edge length' value was for this compensation. However, when I put in 8mm, the final 0,0 X/Y position remains off from the true corner edge. Maybe I am missing something?

3. technical question: Why is there long delays between sequence movements? For instance, when I do inside measurements in a hole, each movement sequence has a multi-second delay. The initial Z plunge completes, then 5+ seconds go by before the probe is moved along X to make first touch off. For a complex sequence, this can result in long delays between the start of a sequence and it completing. Is there a setting in one of the scripts to reduce the delay between each movement sequence?

4. technical question: What is the purpose of the auto zero check box and options? There is presently no documentation that explains when that box should be checked. Some of it is self explanatory, but I can't quite puzzle out its intended purpose.

Thank you for the great work!

Before beginnig work and doing code-commits i want to take the chance and doing a big cleanup.

I tried to move anything that is only psng (probe-screen-next-generation) relevant into the psng-subdir.
Anything the user must touch/configure is in the main-config dir.

Anything which can´t be moved out of standard-dirs has prpended "psng_"

freisei@linuxcnc:/usr/local/src/probe-screen-ng$ tree |grep -v png
.
└── probe-screen
    ├── LICENSE.md
    ├── macros
    │   ├── psng_block_down.ngc
    │   ├── psng_down.ngc
    │   ├── psng_gotots.ngc
    │   ├── psng_manual_change.ngc
    │   ├── psng_probe_down.ngc
    │   ├── psng_xminus.ngc
    │   ├── psng_xplus.ngc
    │   ├── psng_yminus.ngc
    │   └── psng_yplus.ngc
    ├── psng
    │   ├── icons
    │   ├── icons_1024x768
    │   │   ├── probe_screen.glade
    │   │   ├── probe_screen.hal
    │   ├── probe_screen.glade
    │   ├── probe_screen.py
    │   └── probe_screen_scroll.glade
    ├── psng.hal
    ├── psng.ini
    ├── psng-postgui.hal
    ├── python
    │   ├── remap.py
    │   ├── stdglue.py
    │   └── toplevel.py
    ├── README.md

6 directories, 148 files

Rather than ask for pr can you review the change done for saving settings :

    # Spinbox for setter height with autosave value inside machine pref file
    def on_spbtn_setter_height_key_press_event(self, gtkspinbutton, data=None):
        self.on_common_spbtn_key_press_event("setterheight", gtkspinbutton, data)

    def on_spbtn_setter_height_value_changed(self, gtkspinbutton, data=None):
        self.on_common_spbtn_value_changed("setterheight", gtkspinbutton, data)

        self.halcomp["setterheight"] = gtkspinbutton.get_value()
        self.prefs.putpref("setterheight", gtkspinbutton.get_value(), float)
        self.vcp_reload()
        c = "TS Height = " + "%.4f" % gtkspinbutton.get_value()
        i = self.buffer.get_end_iter()                                                                    # TODO update this code like add_history/self.display_result ??
        if i.get_line() > 1000:
            i.backward_line()
            self.buffer.delete(i, self.buffer.get_end_iter())
        i.set_line(0)
        self.buffer.insert(i, "%s \n" % c)

    # Spinbox for block height with autosave value inside machine pref file
    def on_spbtn_block_height_key_press_event(self, gtkspinbutton, data=None):
        self.on_common_spbtn_key_press_event("blockheight", gtkspinbutton, data)

    def on_spbtn_block_height_value_changed(self, gtkspinbutton, data=None):
        self.on_common_spbtn_value_changed("blockheight", gtkspinbutton, data)

        blockheight = gtkspinbutton.get_value()
        self.halcomp["blockheight"] = blockheight
        self.prefs.putpref("blockheight", blockheight, float)
        # set coordinate system to new origin
        s = "G10 L2 P0 Z%s" % blockheight                                                                 # think about using or not using if self.halcomp["set_zero"]: for make it optional
        print ("blockheight %s") % blockheight
        if self.gcode(s) == -1:
            return
        self.vcp_reload()
        c = "Workpiece Height = " + "%.4f" % gtkspinbutton.get_value()
        i = self.buffer.get_end_iter()                                                                    # TODO update this code like add_history/self.display_result ??
        if i.get_line() > 1000:
            i.backward_line()
            self.buffer.delete(i, self.buffer.get_end_iter())
        i.set_line(0)
        self.buffer.insert(i, "%s \n" % c)

Both AXIS UI and the Probe Screen poll for errors. We have no way to guarantee which of the 2 will win the race and receive the error.

There is some hacky code in .axisrc to help ensure the probe screen will always know of an error (though, when AXIS UI wins the race, the error details are gone and all we know is an error has occurred).

The code in PR #29 has some comments explaining this in more detail.

Hi

I have thinsk about doing this but does not work (i don't see hal pin goes true) :

axisrc

def my_task_stop(*event):
    probe_user_comp["abort"] = True
    self.original_task_stop(*event)
    probe_user_comp["abort"] = False #also tested with this line comment out


TclCommands.original_task_stop = TclCommands.task_stop
TclCommands.task_stop = my_task_stop


    probe_user_comp.newpin("abort", hal.HAL_BIT, hal.HAL_OUT)

Hi, hope this is the correct place. Gmoccapy on linuxcnc 2.8, the latest probe-screen-ng. Remap m6: first using ts height, than workpiece height, works perfectly. Then requesting a tool change with m6 tx, spindle goes to change point and after pressing the tool is changed button, i get: "it is not possible to change to auto mode in the moment". No tool length measure, nothing. Any idea, thanks
Michael

    def on_spbtn_block_height_key_press_event(self, gtkspinbutton, data=None):
        keyname = gtk.gdk.keyval_name(data.keyval)
        #        print "Key %s (%d) was pressed" % (keyname, data.keyval)
        if keyname == "Return":
            gtkspinbutton.modify_font(pango.FontDescription("normal"))
        else:
            gtkspinbutton.modify_font(pango.FontDescription("italic"))
            
    def on_spbtn_probe_height_key_press_event(self, gtkspinbutton, data=None):
        keyname = gtk.gdk.keyval_name(data.keyval)
        #        print "Key %s (%d) was pressed" % (keyname, data.keyval)
        if keyname == "Return":
            gtkspinbutton.modify_font(pango.FontDescription("normal"))
        else:
            gtkspinbutton.modify_font(pango.FontDescription("italic"))

add :

<signal name="key-press-event" handler="on_spbtn_probe_height_key_press_event" swapped="no"/>

<signal name="key-press-event" handler="on_spbtn_block_height_key_press_event" swapped="no"/>

Hi all,
I followed instructions for installation to 2.8 linux cnc but after AXIS is started, the probe screen is empty. Please see the screenshot below:

Before this, I installed the version from verser as well, but results were same.
I have seen the screen with all controls appear few times randomly while resizing the window however. I cannot exactly say when it appears as it seems random.
My python version is 2.7.

I have attached the log/std out of linux cnc below.
log.txt