emc-users — Messages about installing and using EMC

Re: [Emc-users] Emc-users Digest, Vol 236, Issue 9

[John O'B. <joh...@gm...>]

I’d like to try to fix the certificate issue. Who do I talk to?

________________________________
From: emc...@li... <emc...@li...>
Sent: Tuesday, December 9, 2025 7:17:48 AM
To: emc...@li... <emc...@li...>
Subject: Emc-users Digest, Vol 236, Issue 9

Send Emc-users mailing list submissions to
        emc...@li...

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/emc-users
or, via email, send a message with subject or body 'help' to
        emc...@li...

You can reach the person managing the list at
        emc...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Emc-users digest..."


Today's Topics:

   1. wiki (fxk...@pr...)
   2. Re: wiki (andy pugh)
   3. Re: wiki (John Dammeyer)
   4. Re: wiki (Scott Harwell)


----------------------------------------------------------------------

Message: 1
Date: Mon, 08 Dec 2025 22:47:45 +0000
From: fxk...@pr...
To: emc...@li...
Subject: [Emc-users] wiki
Message-ID: <7ns...@ce...>
Content-Type: text/plain; charset=utf-8

is the wiki dead or is it me
wiki.linuxcnc.org return site not found





------------------------------

Message: 2
Date: Mon, 8 Dec 2025 23:00:21 +0000
From: andy pugh <bod...@gm...>
To: "Enhanced Machine Controller (EMC)"
        <emc...@li...>
Subject: Re: [Emc-users] wiki
Message-ID:
        <CAN...@ma...>
Content-Type: text/plain; charset="UTF-8"

On Mon, 8 Dec 2025 at 22:52, fxkl47BF--- via Emc-users
<emc...@li...> wrote:
>
> is the wiki dead or is it me
> wiki.linuxcnc.org return site not found

There is a problem with the certificate that we have been unable to fathom.

The http version of the URL works:

http://wiki.linuxcnc.org/


--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
? George Fitch, Atlanta Constitution Newspaper, 1912



------------------------------

Message: 3
Date: Mon, 8 Dec 2025 15:02:08 -0800
From: "John Dammeyer" <jo...@au...>
To: "'Enhanced Machine Controller \(EMC\)'"
        <emc...@li...>
Subject: Re: [Emc-users] wiki
Message-ID: <00e301dc6896$ae772820$0b657860$@autoartisans.com>
Content-Type: text/plain;       charset="us-ascii"

Works for me

> -----Original Message-----
> From: fxkl47BF--- via Emc-users [mailto:emc...@li...]
> Sent: December 8, 2025 2:48 PM
> To: emc...@li...
> Cc: fxk...@pr...
> Subject: [Emc-users] wiki
>
> is the wiki dead or is it me
> wiki.linuxcnc.org return site not found
>
>
>
>
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users




------------------------------

Message: 4
Date: Tue, 9 Dec 2025 02:21:55 +0000 (UTC)
From: Scott Harwell <sha...@ya...>
To: fxkl47BF--- via Emc-users <emc...@li...>
Subject: Re: [Emc-users] wiki
Message-ID: <177...@ma...>
Content-Type: text/plain; charset=UTF-8

 The forum was down for a few minutes here. Everything is workin now.


    On Monday, December 8, 2025 at 04:50:26 PM CST, fxkl47BF--- via Emc-users <emc...@li...> wrote:

 is the wiki dead or is it me
wiki.linuxcnc.org return site not found




_______________________________________________
Emc-users mailing list
Emc...@li...
https://lists.sourceforge.net/lists/listinfo/emc-users


------------------------------



------------------------------

Subject: Digest Footer

_______________________________________________
Emc-users mailing list
Emc...@li...
https://lists.sourceforge.net/lists/listinfo/emc-users


------------------------------

End of Emc-users Digest, Vol 236, Issue 9
*****************************************

Re: [Emc-users] wiki

[Scott H. <sha...@ya...>]

 The forum was down for a few minutes here. Everything is workin now.


    On Monday, December 8, 2025 at 04:50:26 PM CST, fxkl47BF--- via Emc-users <emc...@li...> wrote:  
 
 is the wiki dead or is it me
wiki.linuxcnc.org return site not found




_______________________________________________
Emc-users mailing list
Emc...@li...
https://lists.sourceforge.net/lists/listinfo/emc-users
  

Re: [Emc-users] wiki

[John D. <jo...@au...>]

Works for me

> -----Original Message-----
> From: fxkl47BF--- via Emc-users [mailto:emc...@li...]
> Sent: December 8, 2025 2:48 PM
> To: emc...@li...
> Cc: fxk...@pr...
> Subject: [Emc-users] wiki
> 
> is the wiki dead or is it me
> wiki.linuxcnc.org return site not found
> 
> 
> 
> 
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] wiki

[andy p. <bod...@gm...>]

On Mon, 8 Dec 2025 at 22:52, fxkl47BF--- via Emc-users
<emc...@li...> wrote:
>
> is the wiki dead or is it me
> wiki.linuxcnc.org return site not found

There is a problem with the certificate that we have been unable to fathom.

The http version of the URL works:

http://wiki.linuxcnc.org/


-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

[Emc-users] wiki

[<fxk...@pr...>]

is the wiki dead or is it me
wiki.linuxcnc.org return site not found

Re: [Emc-users] Accessing python hal valriables.

[John D. <jo...@au...>]

> -----Original Message-----
> From: zz...@se... [mailto:zz...@se...]
> self.command.wait_complete()
> 
> This command is waiting only 5s. You should use:
> self.command.wait_complete(600)
> 
> > -----Original Message-----
> > From: John Dammeyer [mailto:jo...@au...]
> 
> > Now if a different probing operation has used that F20 rapid speed then
> the
> > probe travels at that speed across the cylinder. Not only that it makes
> it all
> > the way across and successfully completes the entire probing operation.
> So
> > there was a timeout involved.
> >
> > def error_poll(self):
> > if "axis" in self.display:
> > # AXIS polls for errors every 0.2 seconds, so we wait slightly
> longer to
> > make sure it's happened.
> > time.sleep(0.25)
> > error_pin = Popen(
> > "halcmd getp probe.user.error ", shell=True, stdout=PIPE
> > ).stdout.read()
> >
> > But even before that we have this call:
> > self.command.wait_complete()
> >
> > So why does this return when in fact at F10 the command wasn't
> complete.
> > I can't find the code for wait_complete().
>>
> Here we go:
> https://www.forum.linuxcnc.org/38-general-linuxcnc-questions/43474-wait-
> comp
> 

I did some more digging.  Yes indeed there is the typical crap python default value so you don't know it's there or what the default is without research into whatever library is included.

It allows for sloppy programming.  The correct statement (and a way to not fail a comp. sci. assignment) is:

  self.command.wait_complete()     # using default value of 5 for hidden parameter for max wait time.  

One of the solutions changed the code adding extra parameters to this:
    def gcode(self, s, distance=None, data=None):

and then further down in the method:
            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
            self.command.mdi(l)
            self.timed_wait_complete()

Using 2.4" and 10ipm that works out to 15.4 which I'm going to guess is seconds?  The problem again is documentation.  How does the timed_wait_complete() method know that we now want 15.4?  Global variable?  Again crap documentation.  Another Comp. Sci assignment fail if I was marking the work.

I'm going to guess the author of that fix created an encapsulation method timed_wait_complete() and a global time_in variable.

Inside the method the time_in is an argument to wait_complete(time_in)

Why not just use wait_complete() with time_in as an argument?  Or maybe because the long timeout greater than 5 seconds is really only needed in a few places.  As described:
https://linuxcnc.org/docs/html/config/python-interface.html

So it's working but what a painful process.
John

Re: [Emc-users] Accessing python hal valriables.

[John D. <jo...@au...>]

> -----Original Message-----
> From: gene heskett [mailto:ghe...@sh...]
> > Hi Gene,
> > The code already waits for it to be done.  But the issue is more
> complicated.  The call to execute the move across the piece is where the
> problem is.
> You dug into it much deeper than I, John.� And it looks like a bug, OTOH
> you are moving 20x faster than I would, not wanting the machine to
> explore its resonances that might be jerk triggered.� That and I only
> use a probe very rarely although I have one, but prefer electrical
> contact where it can be done. Its probably 3 or 4 years since I last
> chucked my probe.� As a CET I think differently.
> 

Hi Gene,
You are making it too complicated.  It's a combination of a documentation fault and non-robust programming.  And based on forum posts and google searches I'm not the first with this issue.  Not a hardware one.  Software and poor documentation.

John

Re: [Emc-users] Accessing python hal valriables.

[gene h. <ghe...@sh...>]

On 12/7/25 14:22, John Dammeyer wrote:
>> -----Original Message-----
>> From: gene heskett [mailto:ghe...@sh...]
>> G4p.1 # que buster stop to make sure the X2.4 was totally completed
>> before any probing G38 moves can begin.
> Hi Gene,
> The code already waits for it to be done.  But the issue is more complicated.  The call to execute the move across the piece is where the problem is.
You dug into it much deeper than I, John.  And it looks like a bug, OTOH 
you are moving 20x faster than I would, not wanting the machine to 
explore its resonances that might be jerk triggered.  That and I only 
use a probe very rarely although I have one, but prefer electrical 
contact where it can be done. Its probably 3 or 4 years since I last 
chucked my probe.  As a CET I think differently.

The odd possibility is that at 20"sec, the inertia of the probe finger 
may have caused a momentary break in the probes contacts as it started 
the end of move stop deceleration.  halscope should be able to see that 
I would think. test by adding the F command to slow it way down for the 
X 2.4 move. Try G1 F1 just for grins.  I have a couple modules in my hal 
files that disable the probe signal if motion isn't type 5.  And its 
only type 5 for g38 moves.

 From that file:
#******************************************************
# hook up probe signal but disable if motion type not 5
#******************************************************

# disable out5 if not probe move
net     probe-ctl       <=      motion.motion-type      => select8.0.sel

# move this to p2 input-5 gpio.030, p2-10  is INPUT-1
net     probe-sense <=  hm2_5i25.0.gpio.030.in_not => and-prb.in0 # s/b 
correct action
net     probe-hit1      <=      select8.0.out5 =>  and-prb.in1
net     probe-hit2      <=      and-prb.out => motion.probe-input # 
signal source is NOT p3-15 anymore

Which blocks the probe signal from getting to motion.probe-input for non 
G38 moves.  Might be helpful.
> Recall this part:
>> python program
>>
>>          # move X + 2 edge_length + 2 xy_clearance
>>          tmpx = 2 * (self.halcomp["ps_edge_length"] +
>> self.halcomp["ps_xy_clearance"])
>>          s = """G91
>>          G1 X%f
>>          G90""" % (
>>              tmpx
>>          )
>>          print s
>>
>> Oddly it showed up on the console like this:
>>
>> G91
>>          G1 X2.400000
>>          G90
>>
> What follows that is:
>
>          if self.gcode(s) == -1:
>              return
>
> I thought the self.gcode(s) was a system call.  Turns out not.
> Here's the python gcode execution function called:
>
>      @restore_task_mode
>      def gcode(self, s, data=None):
>          self.command.mode(linuxcnc.MODE_MDI)
>          self.command.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>"
>              self.command.mdi(l)
>              self.command.wait_complete()
>              if self.error_poll() == -1:
>                  return -1
>          return 0
>
> Here you see the string  "G91\nG1 X2.400000\nG90" being split apart and a space after the "G1 " should insert a different RAPID_SPEED from the INI file.  This is what should be sent to the mdi command parser which would change the G1 speed to F20 as that's what is in the INI file.  The output below is from running the same piece of python code on Thonny.
>
> G91
> G1 X2.400000 F#<_ini[TOOLSENSOR]RAPID_SPEED>
> G90
>
> However the output to the LinuxCNC command console doesn't show the F command string.   It's missing even though there is a space after the G1
>
> Now if a different probing operation has used that F20 rapid speed then the probe travels at that speed across the cylinder.  Not only that it makes it all the way across and successfully completes the entire probing operation.   So there was a timeout involved.
>
>      def error_poll(self):
>          if "axis" in self.display:
>              # AXIS polls for errors every 0.2 seconds, so we wait slightly longer to make sure it's happened.
>              time.sleep(0.25)
>              error_pin = Popen(
>                  "halcmd getp probe.user.error ", shell=True, stdout=PIPE
>              ).stdout.read()
>
> But even before that we have this call:
>              self.command.wait_complete()
>
> So why does this return when in fact at F10 the command wasn't complete.  I can't find the code for wait_complete().
>
> John
>
>
>
>
>
>
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users
> .

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.

Re: [Emc-users] Accessing python hal valriables.

[<zz...@se...>]

self.command.wait_complete()

This command is waiting only 5s. You should use:
self.command.wait_complete(600)

"---------- Původní zpráva ----------
Od: John Dammeyer <jo...@au...>
Datum: 07.12.2025 20:37:58
Předmět: Re: [Emc-users] Accessing python hal valriables.



> -----Original Message----- 
> From: John Dammeyer [mailto:jo...@au...] 

> Now if a different probing operation has used that F20 rapid speed then 
the 
> probe travels at that speed across the cylinder. Not only that it makes 
it all 
> the way across and successfully completes the entire probing operation. 
So 
> there was a timeout involved. 
> 
> def error_poll(self): 
> if "axis" in self.display: 
> # AXIS polls for errors every 0.2 seconds, so we wait slightly 
longer to 
> make sure it's happened. 
> time.sleep(0.25) 
> error_pin = Popen( 
> "halcmd getp probe.user.error ", shell=True, stdout=PIPE 
> ).stdout.read() 
> 
> But even before that we have this call: 
> self.command.wait_complete() 
> 
> So why does this return when in fact at F10 the command wasn't complete. 
> I can't find the code for wait_complete(). 
> 
> John 
> 


Here we go: 
https://www.forum.linuxcnc.org/38-general-linuxcnc-questions/43474-wait-comp

lete 

I'm not the only one who has had this problem. I'll try the 'fix' posted by 
'natester' on 20Oct2024 and report back. 

This still doesn't explain why the F20 doesn't show up on the console output

from the python code 

if "G1 " in l: 
l += " F#<_ini[TOOLSENSOR]RAPID_SPEED>" 

doesn't work. 

because entering F#<_ini[TOOLSENSOR]RAPID_SPEED> into the mdi command line 
does change the F setting to F20. 



_______________________________________________ 
Emc-users mailing list 
Emc...@li... 
https://lists.sourceforge.net/lists/listinfo/emc-users 
"

Re: [Emc-users] Accessing python hal valriables.

[John D. <jo...@au...>]

> -----Original Message-----
> From: John Dammeyer [mailto:jo...@au...]
 
> Now if a different probing operation has used that F20 rapid speed then
the
> probe travels at that speed across the cylinder.  Not only that it makes
it all
> the way across and successfully completes the entire probing operation.
So
> there was a timeout involved.
> 
>     def error_poll(self):
>         if "axis" in self.display:
>             # AXIS polls for errors every 0.2 seconds, so we wait slightly
longer to
> make sure it's happened.
>             time.sleep(0.25)
>             error_pin = Popen(
>                 "halcmd getp probe.user.error ", shell=True, stdout=PIPE
>             ).stdout.read()
> 
> But even before that we have this call:
>             self.command.wait_complete()
> 
> So why does this return when in fact at F10 the command wasn't complete.
> I can't find the code for wait_complete().
> 
> John
> 


Here we go:
https://www.forum.linuxcnc.org/38-general-linuxcnc-questions/43474-wait-comp
lete

I'm not the only one who has had this problem.  I'll try the 'fix' posted by
'natester' on 20Oct2024 and report back.

This still doesn't explain why the F20 doesn't show up on the console output
from the python code

    if "G1 " in l:
        l += " F#<_ini[TOOLSENSOR]RAPID_SPEED>"

doesn't work.

because entering F#<_ini[TOOLSENSOR]RAPID_SPEED> into the mdi command line
does change the F setting to F20.

Re: [Emc-users] Accessing python hal valriables.

[John D. <jo...@au...>]

> -----Original Message-----
> From: gene heskett [mailto:ghe...@sh...]
> G4p.1 # que buster stop to make sure the X2.4 was totally completed
> before any probing G38 moves can begin.

Hi Gene,
The code already waits for it to be done.  But the issue is more complicated.  The call to execute the move across the piece is where the problem is.

Recall this part:
> python program
> 
>         # move X + 2 edge_length + 2 xy_clearance
>         tmpx = 2 * (self.halcomp["ps_edge_length"] +
> self.halcomp["ps_xy_clearance"])
>         s = """G91
>         G1 X%f
>         G90""" % (
>             tmpx
>         )
>         print s
> 
> Oddly it showed up on the console like this:
> 
> G91
>         G1 X2.400000
>         G90
>

What follows that is:

        if self.gcode(s) == -1:
            return

I thought the self.gcode(s) was a system call.  Turns out not.  
Here's the python gcode execution function called:

    @restore_task_mode
    def gcode(self, s, data=None):
        self.command.mode(linuxcnc.MODE_MDI)
        self.command.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>"
            self.command.mdi(l)
            self.command.wait_complete()
            if self.error_poll() == -1:
                return -1
        return 0

Here you see the string  "G91\nG1 X2.400000\nG90" being split apart and a space after the "G1 " should insert a different RAPID_SPEED from the INI file.  This is what should be sent to the mdi command parser which would change the G1 speed to F20 as that's what is in the INI file.  The output below is from running the same piece of python code on Thonny.

G91
G1 X2.400000 F#<_ini[TOOLSENSOR]RAPID_SPEED>
G90

However the output to the LinuxCNC command console doesn't show the F command string.   It's missing even though there is a space after the G1

Now if a different probing operation has used that F20 rapid speed then the probe travels at that speed across the cylinder.  Not only that it makes it all the way across and successfully completes the entire probing operation.   So there was a timeout involved.  

    def error_poll(self):
        if "axis" in self.display:
            # AXIS polls for errors every 0.2 seconds, so we wait slightly longer to make sure it's happened.
            time.sleep(0.25)
            error_pin = Popen(
                "halcmd getp probe.user.error ", shell=True, stdout=PIPE
            ).stdout.read()

But even before that we have this call:
            self.command.wait_complete()

So why does this return when in fact at F10 the command wasn't complete.  I can't find the code for wait_complete().

John

Re: [Emc-users] Accessing python hal valriables.

[gene h. <ghe...@sh...>]

On 12/7/25 02:21, Zdeněk Z wrote:
> Maybe your problem is somewhere else entirely.
>
> Possible theory:
>
> I had similar problems where the probe generated false probe signals.
>
> If you are measuring a smaller part, the vibration will be less noticeable
> because the machine is moving over shorter distances.
>
> Try monitoring the probe signal on the HALscope while measuring or running
> the machine.
Halscope can be too slow for effective noise display. I use a real scope 
because I have several of them.
>
>
> Zdeněk
>
> ---------- Původní e-mail ----------
> Od: John Dammeyer <jo...@au...>
> Komu: 'Enhanced Machine Controller (EMC)' <emc...@li...>
> Datum: 7. 12. 2025 8:04:03
> Předmět: Re: [Emc-users] Accessing python hal valriables.
> "Thank you for your reply.
>
> Imagine a piece of 1" round stock sitting upright in the vise. I use the
> VERS.BY probe to find the center of it. Positioned approximately at centre
> and about 0.18" above it. Then click on the find center icon. The Edge
> Length is set to 0.400". After if checks the four edges it moves to the
> precise center. No problem.
>
> Now the same operation but with 2" diameter round stock. Edge Length is set
> to 1.0". Position approximately at centre and about 0.18" above it. Click on
> find center icon. Like before, it moves over 0.2" past the left edge then
> down and then toward the piece.
>
> As before it touches, backs off, moves in really slowly and touches again.
> Moves away, moves up and now it should move, 2x(0.2+1.0)=2.4" in order to go
> past the right edge before going down.
>
> Instead it moves to about 0.59" past the approximate centre point and then
> stops and goes down. It runs into the piece because the code is expecting it
> to be clear of the workpiece.
>
> So the question is why does it move correctly for 1" diameter pieces and not
> for 2" diameter pieces. Especially when the G-Code command as reported by
> the print statement is which should take it to 0.2 past the other side of
> the piece:
> G91
> G1 X2.4
> G90
>
> Something really strange is going on. How can a print statement of the data
> to the gcode command be incorrect?
> print s
> if self.gcode(s) == -1:
> return
>
> If this failed it should never go down and touch the piece.
>
>> -----Original Message-----
>> From: Zdenek Z [mailto:zz...@se...]
>> Sent: December 6, 2025 10:04 PM
>> To: Enhanced Machine Controller (EMC)
>> Subject: Re: [Emc-users] Accessing python hal valriables.
>>
>> Describe the fault of move more.
>>
>>
>>
>> Do you use debouncing for probe signal?
>> https://github.com/LinuxCNC/linuxcnc/blob/master/lib/python/gladevcp/b
>> uiltin-panels/gtk_little_probe/README.md
>>
>>
>>
>> -- 
>> Best Regards
>> Zdenek Zdra il
>>
>> ---------- Puvodn e-mail ----------
>> Od: John Dammeyer <jo...@au...>
>> Komu: 'Enhanced Machine Controller (EMC)' <emc-
>> us...@li...>
>> Datum: 7. 12. 2025 1:22:39
>> Predmet: Re: [Emc-users] Accessing python hal valriables.
>> "To add to this I can set the distance to 0.4" and then use the inner hole
> to
>> find center. That works but again the distance is smaller.
>> I've attached two small photos. Hopefully they come through.
>> John
>>
>>
>>> -----Original Message-----
>>> From: John Dammeyer [mailto:jo...@au...]
>>> Sent: December 6, 2025 4:07 PM
>>> To: 'Enhanced Machine Controller (EMC)'
>>> Subject: Re: [Emc-users] Accessing python hal valriables.
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Andy Pugh [mailto:bod...@gm...]
>>>> Sent: December 6, 2025 1:35 PM
>>>> To: Enhanced Machine Controller
>>>> Cc: Enhanced Machine Controller
>>>> Subject: Re: [Emc-users] Accessing python hal valriables.
>>>>
>>>>
>>>>
>>>>> On 6 Dec 2025, at 19:31, John Dammeyer <jo...@au...>
>>>> wrote:
>>>>> How do I access from workpiece_measurement.py the
>>>>> variable:
>>>> One way would be to create a HAL pin and set the value in that part of
>> the
>>>> code.
>>>> But ?print? might be enough if you start LinuxCNC from the command
>> line.
>>
>>>> _______________________________________________
>>> Thanks Andy,
>>> I always have it starting from the command line so I can look at the
>> output
>>> for other issues. Here's the print statement I added to the python
> program
>>> # move X + 2 edge_length + 2 xy_clearance
>>> tmpx = 2 * (self.halcomp["ps_edge_length"] +
>>> self.halcomp["ps_xy_clearance"])
>>> s = """G91
>>> G1 X%f
>>> G90""" % (
>>> tmpx
>>> )
>>> print s
>>>
>>> Oddly it showed up on the console like this:
>>>
>>> G91
>>> G1 X2.400000
>>> G90
>>>
>>> And the probe only moved 3/4 of the way across the part then went down
>>> and faulted due to touching the work before the move completed. It has
> to
>>> have taken the G91 correctly or the X2.4 would be 2.4" across from the
>>> rough center of the part.
>>>
>>> Yet if I jog back to that starting position and enter this into the MDI
>>> command line
>>>
>>> G91
>>> G1 X2.4
>>> G90
>>>
>>> It moves all the way across the part to the position where it should go
>> down.
>>> So the distance is correct and the machine is left in G91 mode when the
>>> probe faults the move.
>>>
>>> Any ideas?
>>> Thanks
>>> John
>>>
>>>
>>>
>>> _______________________________________________
>>> Emc-users mailing list
>>> Emc...@li...
>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>> _______________________________________________
>> Emc-users mailing list
>> Emc...@li...
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>> "
>>
>> _______________________________________________
>> Emc-users mailing list
>> Emc...@li...
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users
> "
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.

Re: [Emc-users] Accessing python hal valriables.

[gene h. <ghe...@sh...>]

On 12/7/25 02:01, John Dammeyer wrote:
> Thank you for your reply.
>
> Imagine a piece of 1"  round stock sitting upright in the vise.  I use the VERS.BY probe to find the center of it.  Positioned approximately at centre and about 0.18"  above it.  Then click on the find center icon.  The Edge Length is set to 0.400".  After if checks the four edges it moves to the precise center.  No problem.
>
> Now the same operation but with 2" diameter round stock.  Edge Length is set to 1.0".  Position approximately at centre and about 0.18"  above it.  Click on find center icon.  Like before, it moves over 0.2" past the left edge then down and then toward the piece.
>
> As before it touches, backs off, moves in really slowly and touches again.  Moves away, moves up and now it should move,  2x(0.2+1.0)=2.4" in order to go past the right edge before going down.
>
> Instead it moves to about 0.59" past the approximate centre point and then stops and goes down.   It runs into the piece because the code is expecting it to be clear of the workpiece.
>
> So the question is why does it move correctly for 1" diameter pieces and not for 2" diameter pieces.   Especially when the G-Code command as reported by the print statement is which should take it to 0.2 past the other side of the piece:
Because of the blending default, I would add a G4P.1
> G91
>    G1 X2.4
>    G90
G4p.1 # que buster stop to make sure the X2.4 was totally completed 
before any probing G38 moves can begin.
Doing my own g-codes I would do this automatically even if this is not 
the correct instant solution. One might
in this case read the docs for (IIRC) G64 to reduce the blending 
globally which should have a similar effect.
I'd need to see more of the gcode to be sure however.

And never debounce a probe signal.  Not even the delays in the cheap 
opto's used in most breakout boards.
I generally cut out & bypass those as you want as instant a response as 
you can get while probing.
I also use electrical contact, not a regular probe assembly since I 
don't have a tool
changer for my R8 spindle. I just use the tool itself, turning backwards 
so it doesn't cut up a piece of pcb used
as the contact for TLO measurements. For center finding I do it twice, 
once to get it into the ball park, then slower using the first find
as the center for the 2nd, which may move the center a hair. I get 
repeatable .003 mm accuracy that way.
Spindles with ceramic bearings will need a grounding brush on the tool.
>
> Something really strange is going on.  How can a print statement of the data to the gcode command be incorrect?
>          print s
>          if self.gcode(s) == -1:
>              return
>
> If this failed it should never go down and touch the piece.
>
>> -----Original Message-----
>> From: Zdenek Z [mailto:zz...@se...]
>> Sent: December 6, 2025 10:04 PM
>> To: Enhanced Machine Controller (EMC)
>> Subject: Re: [Emc-users] Accessing python hal valriables.
>>
>> Describe the fault of move more.
>>
>>
>>
>> Do you use debouncing for probe signal?
>> https://github.com/LinuxCNC/linuxcnc/blob/master/lib/python/gladevcp/b
>> uiltin-panels/gtk_little_probe/README.md
>>
>>
>>
>> --
>> Best Regards
>> Zdenek Zdra il
>>
>> ---------- Puvodn  e-mail ----------
>> Od: John Dammeyer <jo...@au...>
>> Komu: 'Enhanced Machine Controller (EMC)' <emc-
>> us...@li...>
>> Datum: 7. 12. 2025 1:22:39
>> Predmet: Re: [Emc-users] Accessing python hal valriables.
>> "To add to this I can set the distance to 0.4" and then use the inner hole to
>> find center. That works but again the distance is smaller.
>> I've attached two small photos. Hopefully they come through.
>> John
>>
>>
>>> -----Original Message-----
>>> From: John Dammeyer [mailto:jo...@au...]
>>> Sent: December 6, 2025 4:07 PM
>>> To: 'Enhanced Machine Controller (EMC)'
>>> Subject: Re: [Emc-users] Accessing python hal valriables.
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Andy Pugh [mailto:bod...@gm...]
>>>> Sent: December 6, 2025 1:35 PM
>>>> To: Enhanced Machine Controller
>>>> Cc: Enhanced Machine Controller
>>>> Subject: Re: [Emc-users] Accessing python hal valriables.
>>>>
>>>>
>>>>
>>>>> On 6 Dec 2025, at 19:31, John Dammeyer <jo...@au...>
>>>> wrote:
>>>>> How do I access from workpiece_measurement.py the
>>>>> variable:
>>>> One way would be to create a HAL pin and set the value in that part of
>> the
>>>> code.
>>>> But ?print? might be enough if you start LinuxCNC from the command
>> line.
>>
>>>> _______________________________________________
>>> Thanks Andy,
>>> I always have it starting from the command line so I can look at the
>> output
>>> for other issues. Here's the print statement I added to the python program
>>> # move X + 2 edge_length + 2 xy_clearance
>>> tmpx = 2 * (self.halcomp["ps_edge_length"] +
>>> self.halcomp["ps_xy_clearance"])
>>> s = """G91
>>> G1 X%f
>>> G90""" % (
>>> tmpx
>>> )
>>> print s
>>>
>>> Oddly it showed up on the console like this:
>>>
>>> G91
>>> G1 X2.400000
>>> G90
>>>
>>> And the probe only moved 3/4 of the way across the part then went down
>>> and faulted due to touching the work before the move completed. It has to
>>> have taken the G91 correctly or the X2.4 would be 2.4" across from the
>>> rough center of the part.
>>>
>>> Yet if I jog back to that starting position and enter this into the MDI
>>> command line
>>>
>>> G91
>>> G1 X2.4
>>> G90
>>>
>>> It moves all the way across the part to the position where it should go
>> down.
>>> So the distance is correct and the machine is left in G91 mode when the
>>> probe faults the move.
>>>
>>> Any ideas?
>>> Thanks
>>> John
>>>
>>>
>>>
>>> _______________________________________________
>>> Emc-users mailing list
>>> Emc...@li...
>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>> _______________________________________________
>> Emc-users mailing list
>> Emc...@li...
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>> "
>>
>> _______________________________________________
>> Emc-users mailing list
>> Emc...@li...
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users
> .

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.

Re: [Emc-users] Accessing python hal valriables.

[John D. <jo...@au...>]

Thanks Robert.  1:28AM here now.  I'll check tomorrow what G's are set.  I'm wondering if there is some sort of timeout in play.  My rapid moves are 10 ipm and the uneven point where it stops might be due to not reaching the target in time so it stops but not with an error which is why it then goes downwards.
John

> -----Original Message-----
> From: Robert Schöftner [mailto:rm...@un...]
> Sent: December 7, 2025 12:53 AM
> To: emc...@li...
> Subject: Re: [Emc-users] Accessing python hal valriables.
> 
> Am Samstag, dem 06.12.2025 um 16:19 -0800 schrieb John Dammeyer:
> > To add to this I can set the distance to 0.4" and then use the inner
> > hole to find center.� That works but again the distance is smaller.
> > I've attached two small photos.� Hopefully they come through.
> > John
> 
> Does this behaviour change with feed rate? Is it possible G64 is
> active? If so you could try with G61 or G61.1
> 
> --
> Robert Sch�ftner <rm...@un...>
> 
> 
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Accessing python hal valriables.

[Robert S. <rm...@un...>]

Am Samstag, dem 06.12.2025 um 16:19 -0800 schrieb John Dammeyer:
> To add to this I can set the distance to 0.4" and then use the inner
> hole to find center.  That works but again the distance is smaller.
> I've attached two small photos.  Hopefully they come through.
> John

Does this behaviour change with feed rate? Is it possible G64 is
active? If so you could try with G61 or G61.1

-- 
Robert Schöftner <rm...@un...>

Re: [Emc-users] Accessing python hal valriables.

[Zdeněk Z <zz...@se...>]

Maybe your problem is somewhere else entirely.

Possible theory:

I had similar problems where the probe generated false probe signals.

If you are measuring a smaller part, the vibration will be less noticeable 
because the machine is moving over shorter distances.

Try monitoring the probe signal on the HALscope while measuring or running 
the machine.


Zdeněk

---------- Původní e-mail ----------
Od: John Dammeyer <jo...@au...>
Komu: 'Enhanced Machine Controller (EMC)' <emc...@li...>
Datum: 7. 12. 2025 8:04:03
Předmět: Re: [Emc-users] Accessing python hal valriables.
"Thank you for your reply. 

Imagine a piece of 1" round stock sitting upright in the vise. I use the 
VERS.BY probe to find the center of it. Positioned approximately at centre 
and about 0.18" above it. Then click on the find center icon. The Edge 
Length is set to 0.400". After if checks the four edges it moves to the 
precise center. No problem. 

Now the same operation but with 2" diameter round stock. Edge Length is set 
to 1.0". Position approximately at centre and about 0.18" above it. Click on
find center icon. Like before, it moves over 0.2" past the left edge then 
down and then toward the piece. 

As before it touches, backs off, moves in really slowly and touches again. 
Moves away, moves up and now it should move, 2x(0.2+1.0)=2.4" in order to go
past the right edge before going down. 

Instead it moves to about 0.59" past the approximate centre point and then 
stops and goes down. It runs into the piece because the code is expecting it
to be clear of the workpiece. 

So the question is why does it move correctly for 1" diameter pieces and not
for 2" diameter pieces. Especially when the G-Code command as reported by 
the print statement is which should take it to 0.2 past the other side of 
the piece: 
G91 
G1 X2.4 
G90 

Something really strange is going on. How can a print statement of the data 
to the gcode command be incorrect? 
print s 
if self.gcode(s) == -1: 
return 

If this failed it should never go down and touch the piece. 

> -----Original Message----- 
> From: Zdenek Z [mailto:zz...@se...] 
> Sent: December 6, 2025 10:04 PM 
> To: Enhanced Machine Controller (EMC) 
> Subject: Re: [Emc-users] Accessing python hal valriables. 
> 
> Describe the fault of move more. 
> 
> 
> 
> Do you use debouncing for probe signal? 
> https://github.com/LinuxCNC/linuxcnc/blob/master/lib/python/gladevcp/b 
> uiltin-panels/gtk_little_probe/README.md 
> 
> 
> 
> -- 
> Best Regards 
> Zdenek Zdra il 
> 
> ---------- Puvodn e-mail ---------- 
> Od: John Dammeyer <jo...@au...> 
> Komu: 'Enhanced Machine Controller (EMC)' <emc- 
> us...@li...> 
> Datum: 7. 12. 2025 1:22:39 
> Predmet: Re: [Emc-users] Accessing python hal valriables. 
> "To add to this I can set the distance to 0.4" and then use the inner hole
to 
> find center. That works but again the distance is smaller. 
> I've attached two small photos. Hopefully they come through. 
> John 
> 
> 
> > -----Original Message----- 
> > From: John Dammeyer [mailto:jo...@au...] 
> > Sent: December 6, 2025 4:07 PM 
> > To: 'Enhanced Machine Controller (EMC)' 
> > Subject: Re: [Emc-users] Accessing python hal valriables. 
> > 
> > 
> > 
> > > -----Original Message----- 
> > > From: Andy Pugh [mailto:bod...@gm...] 
> > > Sent: December 6, 2025 1:35 PM 
> > > To: Enhanced Machine Controller 
> > > Cc: Enhanced Machine Controller 
> > > Subject: Re: [Emc-users] Accessing python hal valriables. 
> > > 
> > > 
> > > 
> > > > On 6 Dec 2025, at 19:31, John Dammeyer <jo...@au...> 
> > > wrote: 
> > > > 
> > > > How do I access from workpiece_measurement.py the 
> > > > variable: 
> > > 
> > > One way would be to create a HAL pin and set the value in that part of

> the 
> > > code. 
> > > But ?print? might be enough if you start LinuxCNC from the command 
> line. 
> 
> > > 
> > > _______________________________________________ 
> > 
> > Thanks Andy, 
> > I always have it starting from the command line so I can look at the 
> output 
> > for other issues. Here's the print statement I added to the python 
program 
> 
> > 
> > # move X + 2 edge_length + 2 xy_clearance 
> > tmpx = 2 * (self.halcomp["ps_edge_length"] + 
> > self.halcomp["ps_xy_clearance"]) 
> > s = """G91 
> > G1 X%f 
> > G90""" % ( 
> > tmpx 
> > ) 
> > print s 
> > 
> > Oddly it showed up on the console like this: 
> > 
> > G91 
> > G1 X2.400000 
> > G90 
> > 
> > And the probe only moved 3/4 of the way across the part then went down 
> > and faulted due to touching the work before the move completed. It has 
to 
> > have taken the G91 correctly or the X2.4 would be 2.4" across from the 
> > rough center of the part. 
> > 
> > Yet if I jog back to that starting position and enter this into the MDI 
> > command line 
> > 
> > G91 
> > G1 X2.4 
> > G90 
> > 
> > It moves all the way across the part to the position where it should go 
> down. 
> > 
> > So the distance is correct and the machine is left in G91 mode when the 
> > probe faults the move. 
> > 
> > Any ideas? 
> > Thanks 
> > John 
> > 
> > 
> > 
> > _______________________________________________ 
> > Emc-users mailing list 
> > Emc...@li... 
> > https://lists.sourceforge.net/lists/listinfo/emc-users 
> _______________________________________________ 
> Emc-users mailing list 
> Emc...@li... 
> https://lists.sourceforge.net/lists/listinfo/emc-users 
> " 
> 
> _______________________________________________ 
> Emc-users mailing list 
> Emc...@li... 
> https://lists.sourceforge.net/lists/listinfo/emc-users 



_______________________________________________ 
Emc-users mailing list 
Emc...@li... 
https://lists.sourceforge.net/lists/listinfo/emc-users 
"

Re: [Emc-users] Accessing python hal valriables.

[John D. <jo...@au...>]

Thank you for your reply.  

Imagine a piece of 1"  round stock sitting upright in the vise.  I use the VERS.BY probe to find the center of it.  Positioned approximately at centre and about 0.18"  above it.  Then click on the find center icon.  The Edge Length is set to 0.400".  After if checks the four edges it moves to the precise center.  No problem.  

Now the same operation but with 2" diameter round stock.  Edge Length is set to 1.0".  Position approximately at centre and about 0.18"  above it.  Click on find center icon.  Like before, it moves over 0.2" past the left edge then down and then toward the piece.  

As before it touches, backs off, moves in really slowly and touches again.  Moves away, moves up and now it should move,  2x(0.2+1.0)=2.4" in order to go past the right edge before going down.  

Instead it moves to about 0.59" past the approximate centre point and then stops and goes down.   It runs into the piece because the code is expecting it to be clear of the workpiece.

So the question is why does it move correctly for 1" diameter pieces and not for 2" diameter pieces.   Especially when the G-Code command as reported by the print statement is which should take it to 0.2 past the other side of the piece:
G91
  G1 X2.4
  G90

Something really strange is going on.  How can a print statement of the data to the gcode command be incorrect?
        print s
        if self.gcode(s) == -1:
            return

If this failed it should never go down and touch the piece.

> -----Original Message-----
> From: Zdenek Z [mailto:zz...@se...]
> Sent: December 6, 2025 10:04 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Accessing python hal valriables.
> 
> Describe the fault of move more.
> 
> 
> 
> Do you use debouncing for probe signal?
> https://github.com/LinuxCNC/linuxcnc/blob/master/lib/python/gladevcp/b
> uiltin-panels/gtk_little_probe/README.md
> 
> 
> 
> --
> Best Regards
> Zdenek Zdra il
> 
> ---------- Puvodn  e-mail ----------
> Od: John Dammeyer <jo...@au...>
> Komu: 'Enhanced Machine Controller (EMC)' <emc-
> us...@li...>
> Datum: 7. 12. 2025 1:22:39
> Predmet: Re: [Emc-users] Accessing python hal valriables.
> "To add to this I can set the distance to 0.4" and then use the inner hole to
> find center. That works but again the distance is smaller.
> I've attached two small photos. Hopefully they come through.
> John
> 
> 
> > -----Original Message-----
> > From: John Dammeyer [mailto:jo...@au...]
> > Sent: December 6, 2025 4:07 PM
> > To: 'Enhanced Machine Controller (EMC)'
> > Subject: Re: [Emc-users] Accessing python hal valriables.
> >
> >
> >
> > > -----Original Message-----
> > > From: Andy Pugh [mailto:bod...@gm...]
> > > Sent: December 6, 2025 1:35 PM
> > > To: Enhanced Machine Controller
> > > Cc: Enhanced Machine Controller
> > > Subject: Re: [Emc-users] Accessing python hal valriables.
> > >
> > >
> > >
> > > > On 6 Dec 2025, at 19:31, John Dammeyer <jo...@au...>
> > > wrote:
> > > >
> > > > How do I access from workpiece_measurement.py the
> > > > variable:
> > >
> > > One way would be to create a HAL pin and set the value in that part of
> the
> > > code.
> > > But ?print? might be enough if you start LinuxCNC from the command
> line.
> 
> > >
> > > _______________________________________________
> >
> > Thanks Andy,
> > I always have it starting from the command line so I can look at the
> output
> > for other issues. Here's the print statement I added to the python program
> 
> >
> > # move X + 2 edge_length + 2 xy_clearance
> > tmpx = 2 * (self.halcomp["ps_edge_length"] +
> > self.halcomp["ps_xy_clearance"])
> > s = """G91
> > G1 X%f
> > G90""" % (
> > tmpx
> > )
> > print s
> >
> > Oddly it showed up on the console like this:
> >
> > G91
> > G1 X2.400000
> > G90
> >
> > And the probe only moved 3/4 of the way across the part then went down
> > and faulted due to touching the work before the move completed. It has to
> > have taken the G91 correctly or the X2.4 would be 2.4" across from the
> > rough center of the part.
> >
> > Yet if I jog back to that starting position and enter this into the MDI
> > command line
> >
> > G91
> > G1 X2.4
> > G90
> >
> > It moves all the way across the part to the position where it should go
> down.
> >
> > So the distance is correct and the machine is left in G91 mode when the
> > probe faults the move.
> >
> > Any ideas?
> > Thanks
> > John
> >
> >
> >
> > _______________________________________________
> > Emc-users mailing list
> > Emc...@li...
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users
> "
> 
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Accessing python hal valriables.

[Zdeněk Z <zz...@se...>]

Describe the fault of move more.



Do you use debouncing for probe signal?
https://github.com/LinuxCNC/linuxcnc/blob/master/lib/python/gladevcp/builtin
-panels/gtk_little_probe/README.md


-- 
Best Regards
Zdeněk Zdražil

---------- Původní e-mail ----------
Od: John Dammeyer <jo...@au...>
Komu: 'Enhanced Machine Controller (EMC)' <emc...@li...>
Datum: 7. 12. 2025 1:22:39
Předmět: Re: [Emc-users] Accessing python hal valriables.
"To add to this I can set the distance to 0.4" and then use the inner hole 
to find center. That works but again the distance is smaller. 
I've attached two small photos. Hopefully they come through. 
John 


> -----Original Message----- 
> From: John Dammeyer [mailto:jo...@au...] 
> Sent: December 6, 2025 4:07 PM 
> To: 'Enhanced Machine Controller (EMC)' 
> Subject: Re: [Emc-users] Accessing python hal valriables. 
> 
> 
> 
> > -----Original Message----- 
> > From: Andy Pugh [mailto:bod...@gm...] 
> > Sent: December 6, 2025 1:35 PM 
> > To: Enhanced Machine Controller 
> > Cc: Enhanced Machine Controller 
> > Subject: Re: [Emc-users] Accessing python hal valriables. 
> > 
> > 
> > 
> > > On 6 Dec 2025, at 19:31, John Dammeyer <jo...@au...> 
> > wrote: 
> > > 
> > > How do I access from workpiece_measurement.py the 
> > > variable: 
> > 
> > One way would be to create a HAL pin and set the value in that part of 
the 
> > code. 
> > But ?print? might be enough if you start LinuxCNC from the command line.

> > 
> > _______________________________________________ 
> 
> Thanks Andy, 
> I always have it starting from the command line so I can look at the 
output 
> for other issues. Here's the print statement I added to the python program

> 
> # move X + 2 edge_length + 2 xy_clearance 
> tmpx = 2 * (self.halcomp["ps_edge_length"] + 
> self.halcomp["ps_xy_clearance"]) 
> s = """G91 
> G1 X%f 
> G90""" % ( 
> tmpx 
> ) 
> print s 
> 
> Oddly it showed up on the console like this: 
> 
> G91 
> G1 X2.400000 
> G90 
> 
> And the probe only moved 3/4 of the way across the part then went down 
> and faulted due to touching the work before the move completed. It has to 
> have taken the G91 correctly or the X2.4 would be 2.4" across from the 
> rough center of the part. 
> 
> Yet if I jog back to that starting position and enter this into the MDI 
> command line 
> 
> G91 
> G1 X2.4 
> G90 
> 
> It moves all the way across the part to the position where it should go 
down. 
> 
> So the distance is correct and the machine is left in G91 mode when the 
> probe faults the move. 
> 
> Any ideas? 
> Thanks 
> John 
> 
> 
> 
> _______________________________________________ 
> Emc-users mailing list 
> Emc...@li... 
> https://lists.sourceforge.net/lists/listinfo/emc-users 
_______________________________________________ 
Emc-users mailing list 
Emc...@li... 
https://lists.sourceforge.net/lists/listinfo/emc-users 
"

Re: [Emc-users] Accessing python hal valriables.

[John D. <jo...@au...>]

To add to this I can set the distance to 0.4" and then use the inner hole to find center.  That works but again the distance is smaller.
I've attached two small photos.  Hopefully they come through.
John


> -----Original Message-----
> From: John Dammeyer [mailto:jo...@au...]
> Sent: December 6, 2025 4:07 PM
> To: 'Enhanced Machine Controller (EMC)'
> Subject: Re: [Emc-users] Accessing python hal valriables.
> 
> 
> 
> > -----Original Message-----
> > From: Andy Pugh [mailto:bod...@gm...]
> > Sent: December 6, 2025 1:35 PM
> > To: Enhanced Machine Controller
> > Cc: Enhanced Machine Controller
> > Subject: Re: [Emc-users] Accessing python hal valriables.
> >
> >
> >
> > > On 6 Dec 2025, at 19:31, John Dammeyer <jo...@au...>
> > wrote:
> > >
> > > How do I access from workpiece_measurement.py the
> > > variable:
> >
> > One way would be to create a HAL pin and set the value in that part of the
> > code.
> > But ?print? might be enough if you start LinuxCNC from the command line.
> >
> > _______________________________________________
> 
> Thanks Andy,
> I always have it starting from the command line so I can look at the output
> for other issues.  Here's the print statement I added to the python program
> 
>         # move X + 2 edge_length + 2 xy_clearance
>         tmpx = 2 * (self.halcomp["ps_edge_length"] +
> self.halcomp["ps_xy_clearance"])
>         s = """G91
>         G1 X%f
>         G90""" % (
>             tmpx
>         )
>         print s
> 
> Oddly it showed up on the console like this:
> 
> G91
>         G1 X2.400000
>         G90
> 
> And the probe only moved 3/4 of the way across the part then went down
> and faulted due to touching the work before the move completed.  It has to
> have taken the G91 correctly or the X2.4 would be 2.4" across from the
> rough center of the part.
> 
> Yet if I jog back to that starting position and enter this into the MDI
> command line
> 
> G91
> G1 X2.4
> G90
> 
> It moves all the way across the part to the position where it should go down.
> 
> So the distance is correct and the machine is left in G91 mode when the
> probe faults the move.
> 
> Any ideas?
> Thanks
> John
> 
> 
> 
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Accessing python hal valriables.

[John D. <jo...@au...>]

> -----Original Message-----
> From: Andy Pugh [mailto:bod...@gm...]
> Sent: December 6, 2025 1:35 PM
> To: Enhanced Machine Controller
> Cc: Enhanced Machine Controller
> Subject: Re: [Emc-users] Accessing python hal valriables.
> 
> 
> 
> > On 6 Dec 2025, at 19:31, John Dammeyer <jo...@au...>
> wrote:
> >
> > How do I access from workpiece_measurement.py the
> > variable:
> 
> One way would be to create a HAL pin and set the value in that part of the
> code.
> But �print� might be enough if you start LinuxCNC from the command line.
> 
> _______________________________________________

Thanks Andy,
I always have it starting from the command line so I can look at the output for other issues.  Here's the print statement I added to the python program

        # move X + 2 edge_length + 2 xy_clearance
        tmpx = 2 * (self.halcomp["ps_edge_length"] + self.halcomp["ps_xy_clearance"])
        s = """G91
        G1 X%f
        G90""" % (
            tmpx
        )
        print s

Oddly it showed up on the console like this:

G91
        G1 X2.400000
        G90

And the probe only moved 3/4 of the way across the part then went down and faulted due to touching the work before the move completed.  It has to have taken the G91 correctly or the X2.4 would be 2.4" across from the rough center of the part.

Yet if I jog back to that starting position and enter this into the MDI command line

G91 
G1 X2.4
G90

It moves all the way across the part to the position where it should go down.  

So the distance is correct and the machine is left in G91 mode when the probe faults the move.

Any ideas?
Thanks
John

Re: [Emc-users] Accessing python hal valriables.

[Andy P. <bod...@gm...>]

> On 6 Dec 2025, at 19:31, John Dammeyer <jo...@au...> wrote:
> 
> How do I access from workpiece_measurement.py the
> variable:

One way would be to create a HAL pin and set the value in that part of the code. 
But “print” might be enough if you start LinuxCNC from the command line. 

[Emc-users] Accessing python hal valriables.

[John D. <jo...@au...>]

Hi,
I'm seeing problems with the original version of psng for probing.  I'm
using the files that were changed to imperial measurements and although
finding the center of a round part when it was less than 1" diameter worked
great it failed for something closer to 2" diameter.
 
After it probes the left edge of the part it properly goes up and then moves
to the right and should go:
        # move Y + 2 edge_length + 2 xy_clearance
        tmpy = 2 * (self.halcomp["ps_edge_length"] +
self.halcomp["ps_xy_clearance"])
 
It appears more to be going to just 2x xy_clearance.  
 
Diving into the code it looks like the screen parameter ps_edge_length may
be improperly modified.  How do I access from workpiece_measurement.py the
variable: 
  self.halcomp["ps_edge_length"] and even the "tmpy" variable
so I can view it in real time.
 
I've already changed  the following from 1000, 1 and 10:
  <object class="GtkAdjustment" id="adj_edge_length">
    <property name="upper">10000</property>
    <property name="step_increment">0.05</property>
    <property name="page_increment">0.5</property>
  </object>
 
Now the up/down arrow and the page up/down work for more reasonable values
for imperial machines.
 
Thanks
John
 

Re: [Emc-users] Emc-users Digest, Vol 236, Issue 2 : RVDT

[bruno s. <br...@ti...>]

not sure what kind of precision you are looking to attain, but RVDT/LVDT 
are easily made and interfaced with a microcontroller. Check this paper

https://ieeexplore.ieee.org/document/7151256

This paper presents a simple digitizer suitable for differential 
variable inductive/reluctance sensors. The proposed scheme uses two 
digital I/O pins, a counter and a comparator of a microcontroller and 
obtains a digital output directly proportional to the measurand which is 
sensed using a differential variable inductive/reluctance sensor 
possessing either a linear or an inverse transfer characteristic. The 
scheme uses a ratio-metric approach in the computation and hence the 
output is less sensitive to variation in the parameters such as 
excitation voltage, reference voltage, offset of the comparator, etc. A 
prototype of the proposed system has been built and tested using 
standard variable inductors that emulated a differential inductive 
sensor following an inverse characteristic. The output recorded was 
linear across the full range and worst-case error noted was less than 
0.3 %. For the prototype developed, the time taken to complete a 
measurement was 200 μs. The prototype digitizer has been interfaced with 
a commercially available LVDT and tested. The worst-case error observed 
in this test was 0.77%. Also, the same digitizer has been employed to 
get a digital readout from a differential variable reluctance based 
displacement sensor. The worst-case error was less than 0.83%. The test 
results establish the efficacy of, the simple and cost effective, scheme 
developed.

can find the pdf here or ask and I'll email it.

https://annas-archive.org/search?index=journals&q=%22doi:10.1109/I2MTC.2015.7151256%22

On 12/1/2025 13:16, emc...@li... wrote:
> Send Emc-users mailing list submissions to
> 	emc...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/emc-users
> or, via email, send a message with subject or body 'help' to
> 	emc...@li...
>
> You can reach the person managing the list at
> 	emc...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Emc-users digest..."
>
>
> Today's Topics:
>
>     1. Re: Questions about Mesa cards (gene heskett)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 1 Dec 2025 01:02:51 -0500
> From: gene heskett<ghe...@sh...>
> To:emc...@li...
> Subject: Re: [Emc-users] Questions about Mesa cards
> Message-ID:<38d...@sh...>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
>
>
> On 11/30/25 20:58, Leonardo Marsaglia wrote:
>>> I think they may be bending beams and strain gauges.
>> Judging by the range they claim they can reach I think it's not the case.
>> Apparently they use the compressed air as a means to sense the position of
>> the arm. I still think RVDT could be a very good solution. I also thought
>> about using a rotary capacitor but those are more sensitive to harsh
>> environments and have less linearity than RVDTs apparently.
> Less linearity is a gross understatement of the problem, because the
> capacitance is several times more sensitive to the axial placement due
> to the square law. where any axial displacement adds capacitance at a
> much faster rate on the side getting closer, than is lost by the
> increasing spacing on the other side of the plates, so you get the
> calculated capacity only if perfectly centered.? This isn't correctable
> by shaping the plates as eccentric although there have been at least 100
> attempts to do that in order to linearize the dial on the common AM
> receiver with it's 3/1 frequency range here in the USA.
>
> Using a variable leakage hole also suffers even worse from air louver
> sorts of non-linearity because an air louver flows 50% of its air flow
> capability with fixed hp fans when only open 5 degrees.? I would not
> look for a solution involving air leakage, but might consider a piston
> and hall effect, which if the resisting spring is calibrated correctly,
> could result in a hall effect output that might be 5% accurate.? The
> spring, properly formed could result in the square law response of the
> hall effect device being /mostly/ canceled. So the RVDT solution might
> be the best solution out there. Pricy I'd imagine.
>> El mar, 25 nov 2025 a las 11:11, andy pugh (<bod...@gm...>) escribi?:
>>
>>> On Tue, 11 Nov 2025 at 01:07, andy pugh<bod...@gm...>  wrote:
>>>
>>>> I think they may be bending beams and strain gauges.
>>> For once the AI on Google is spot on (and better than the web results)
>>> I made a lot of these when working in the field described. (fatigue
>>> testing of CTS specimens).
>>> Despite being extremely simple, they are very accurate and surprisingly
>>> linear.
>>>
>>> -----------------begin-AI------------------------------
>>> "Clip gauges" generally refers to clip-on extensometers used in
>>> materials testing, specifically for measuring crack mouth opening
>>> displacement (CMOD) or large strains in specimens. Fabricating one
>>> involves installing strain gauges on a simple flexure device, which
>>> requires specific materials and careful procedures.
>>> Materials Needed for a Basic Clip Gauge
>>>
>>> Spring steel strips for the main body of the gauge.
>>> Strain gauges (e.g., EP-series for high elongation measurements).
>>> Terminals for wiring connections.
>>> Connecting block for fixing the strips.
>>> Cyanoacrylate (CN) glue for bonding the strain gauges.
>>> Cleaning agents: sandpaper, cotton, acetone, iso-propyl alcohol (IPA).
>>> Tools: Tweezers, low-tack cellophane tape, light scribing tool or 4H
>>> pencil, soldering iron and wires (for connecting wires).
>>> Calibration tools: A system for applying known displacements and
>>> measuring the output (e.g., a comparator bar).
>>>
>>> Step-by-Step Fabrication Process
>>>
>>> Prepare the spring steel strips: Clean and abrade the areas where the
>>> strain gauges will be installed using sandpaper. The position should
>>> be as close as possible to the region of maximum bending stress.
>>> Clean thoroughly: Remove all abrading debris using cotton and acetone,
>>> then clean again with IPA. Avoid touching the prepared surface with
>>> your fingers afterward.
>>> Mark alignment lines: Use a light scribing tool or 4H pencil to mark
>>> alignment lines for the gauges.
>>> Position gauges and terminals: Use tweezers to place the strain gauges
>>> and terminals against the alignment lines. Secure their relative
>>> position with low-tack cellophane tape, ensuring the metal foil grid
>>> faces up.
>>> Bond the gauges: Roll one end of the tape back to expose the backing
>>> sheet. Apply a small drop of CN glue to the backing sheet and stick
>>> the tape back in place, applying even pressure.
>>> Wire the gauges: Solder the connecting wires to the terminals. The
>>> gauges are typically wired into a half or full Wheatstone bridge
>>> configuration to maximize the signal.
>>> Mount the gauge "feet": Design the device so that it can be mounted to
>>> the test specimen by bonding or spot welding, depending on the
>>> material.
>>> Calibrate the finished gauge: The clip gauge is a nonlinear device and
>>> requires calibration against known displacements before use. Monitor
>>> the "zero" reading during calibration to check for permanent offsets,
>>> which may indicate localized yielding.
>>>
>>> For a detailed guide on the design and calibration, academic resources
>>> like the paper on the "Optimum Design of a Ring-Shaped Clip Gauge"
>>> provide an analytical framework.
>>> ---------------------------------------------
>>>
>>>
>>> https://link.springer.com/article/10.1007/s40799-020-00417-1#:~:text=To%20design%20a%20gauge%20with,available%20in%20commercial%20mathematical%20software
>>> .
>>>
>>> This video shows a completed one, but is otherwise not as good as one
>>> might hope.
>>> https://www.youtube.com/watch?v=5ry-7iqQIEw
>>>
>>> --
>>> atp
>>> "A motorcycle is a bicycle with a pandemonium attachment and is
>>> designed for the especial use of mechanical geniuses, daredevils and
>>> lunatics."
>>> ? George Fitch, Atlanta Constitution Newspaper, 1912
>>>
>>>
>>> _______________________________________________
>>> Emc-users mailing list
>>> Emc...@li...
>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>
>> _______________________________________________
>> Emc-users mailing list
>> Emc...@li...
>> https://lists.sourceforge.net/lists/listinfo/emc-users
> Cheers, Gene Heskett, CET.

Re: [Emc-users] Questions about Mesa cards

[gene h. <ghe...@sh...>]

On 11/30/25 20:58, Leonardo Marsaglia wrote:
>> I think they may be bending beams and strain gauges.
>
> Judging by the range they claim they can reach I think it's not the case.
> Apparently they use the compressed air as a means to sense the position of
> the arm. I still think RVDT could be a very good solution. I also thought
> about using a rotary capacitor but those are more sensitive to harsh
> environments and have less linearity than RVDTs apparently.
Less linearity is a gross understatement of the problem, because the 
capacitance is several times more sensitive to the axial placement due 
to the square law. where any axial displacement adds capacitance at a 
much faster rate on the side getting closer, than is lost by the 
increasing spacing on the other side of the plates, so you get the 
calculated capacity only if perfectly centered.  This isn't correctable 
by shaping the plates as eccentric although there have been at least 100 
attempts to do that in order to linearize the dial on the common AM 
receiver with it's 3/1 frequency range here in the USA.

Using a variable leakage hole also suffers even worse from air louver 
sorts of non-linearity because an air louver flows 50% of its air flow 
capability with fixed hp fans when only open 5 degrees.  I would not 
look for a solution involving air leakage, but might consider a piston 
and hall effect, which if the resisting spring is calibrated correctly, 
could result in a hall effect output that might be 5% accurate.  The 
spring, properly formed could result in the square law response of the 
hall effect device being /mostly/ canceled. So the RVDT solution might 
be the best solution out there. Pricy I'd imagine.
> El mar, 25 nov 2025 a las 11:11, andy pugh (<bod...@gm...>) escribió:
>
>> On Tue, 11 Nov 2025 at 01:07, andy pugh <bod...@gm...> wrote:
>>
>>> I think they may be bending beams and strain gauges.
>> For once the AI on Google is spot on (and better than the web results)
>> I made a lot of these when working in the field described. (fatigue
>> testing of CTS specimens).
>> Despite being extremely simple, they are very accurate and surprisingly
>> linear.
>>
>> -----------------begin-AI------------------------------
>> "Clip gauges" generally refers to clip-on extensometers used in
>> materials testing, specifically for measuring crack mouth opening
>> displacement (CMOD) or large strains in specimens. Fabricating one
>> involves installing strain gauges on a simple flexure device, which
>> requires specific materials and careful procedures.
>> Materials Needed for a Basic Clip Gauge
>>
>> Spring steel strips for the main body of the gauge.
>> Strain gauges (e.g., EP-series for high elongation measurements).
>> Terminals for wiring connections.
>> Connecting block for fixing the strips.
>> Cyanoacrylate (CN) glue for bonding the strain gauges.
>> Cleaning agents: sandpaper, cotton, acetone, iso-propyl alcohol (IPA).
>> Tools: Tweezers, low-tack cellophane tape, light scribing tool or 4H
>> pencil, soldering iron and wires (for connecting wires).
>> Calibration tools: A system for applying known displacements and
>> measuring the output (e.g., a comparator bar).
>>
>> Step-by-Step Fabrication Process
>>
>> Prepare the spring steel strips: Clean and abrade the areas where the
>> strain gauges will be installed using sandpaper. The position should
>> be as close as possible to the region of maximum bending stress.
>> Clean thoroughly: Remove all abrading debris using cotton and acetone,
>> then clean again with IPA. Avoid touching the prepared surface with
>> your fingers afterward.
>> Mark alignment lines: Use a light scribing tool or 4H pencil to mark
>> alignment lines for the gauges.
>> Position gauges and terminals: Use tweezers to place the strain gauges
>> and terminals against the alignment lines. Secure their relative
>> position with low-tack cellophane tape, ensuring the metal foil grid
>> faces up.
>> Bond the gauges: Roll one end of the tape back to expose the backing
>> sheet. Apply a small drop of CN glue to the backing sheet and stick
>> the tape back in place, applying even pressure.
>> Wire the gauges: Solder the connecting wires to the terminals. The
>> gauges are typically wired into a half or full Wheatstone bridge
>> configuration to maximize the signal.
>> Mount the gauge "feet": Design the device so that it can be mounted to
>> the test specimen by bonding or spot welding, depending on the
>> material.
>> Calibrate the finished gauge: The clip gauge is a nonlinear device and
>> requires calibration against known displacements before use. Monitor
>> the "zero" reading during calibration to check for permanent offsets,
>> which may indicate localized yielding.
>>
>> For a detailed guide on the design and calibration, academic resources
>> like the paper on the "Optimum Design of a Ring-Shaped Clip Gauge"
>> provide an analytical framework.
>> ---------------------------------------------
>>
>>
>> https://link.springer.com/article/10.1007/s40799-020-00417-1#:~:text=To%20design%20a%20gauge%20with,available%20in%20commercial%20mathematical%20software
>> .
>>
>> This video shows a completed one, but is otherwise not as good as one
>> might hope.
>> https://www.youtube.com/watch?v=5ry-7iqQIEw
>>
>> --
>> atp
>> "A motorcycle is a bicycle with a pandemonium attachment and is
>> designed for the especial use of mechanical geniuses, daredevils and
>> lunatics."
>> — George Fitch, Atlanta Constitution Newspaper, 1912
>>
>>
>> _______________________________________________
>> Emc-users mailing list
>> Emc...@li...
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.

Re: [Emc-users] Questions about Mesa cards

[Leonardo M. <ldm...@gm...>]

>
> I think they may be bending beams and strain gauges.


Judging by the range they claim they can reach I think it's not the case.
Apparently they use the compressed air as a means to sense the position of
the arm. I still think RVDT could be a very good solution. I also thought
about using a rotary capacitor but those are more sensitive to harsh
environments and have less linearity than RVDTs apparently.

El mar, 25 nov 2025 a las 11:11, andy pugh (<bod...@gm...>) escribió:

> On Tue, 11 Nov 2025 at 01:07, andy pugh <bod...@gm...> wrote:
>
> > I think they may be bending beams and strain gauges.
>
> For once the AI on Google is spot on (and better than the web results)
> I made a lot of these when working in the field described. (fatigue
> testing of CTS specimens).
> Despite being extremely simple, they are very accurate and surprisingly
> linear.
>
> -----------------begin-AI------------------------------
> "Clip gauges" generally refers to clip-on extensometers used in
> materials testing, specifically for measuring crack mouth opening
> displacement (CMOD) or large strains in specimens. Fabricating one
> involves installing strain gauges on a simple flexure device, which
> requires specific materials and careful procedures.
> Materials Needed for a Basic Clip Gauge
>
> Spring steel strips for the main body of the gauge.
> Strain gauges (e.g., EP-series for high elongation measurements).
> Terminals for wiring connections.
> Connecting block for fixing the strips.
> Cyanoacrylate (CN) glue for bonding the strain gauges.
> Cleaning agents: sandpaper, cotton, acetone, iso-propyl alcohol (IPA).
> Tools: Tweezers, low-tack cellophane tape, light scribing tool or 4H
> pencil, soldering iron and wires (for connecting wires).
> Calibration tools: A system for applying known displacements and
> measuring the output (e.g., a comparator bar).
>
> Step-by-Step Fabrication Process
>
> Prepare the spring steel strips: Clean and abrade the areas where the
> strain gauges will be installed using sandpaper. The position should
> be as close as possible to the region of maximum bending stress.
> Clean thoroughly: Remove all abrading debris using cotton and acetone,
> then clean again with IPA. Avoid touching the prepared surface with
> your fingers afterward.
> Mark alignment lines: Use a light scribing tool or 4H pencil to mark
> alignment lines for the gauges.
> Position gauges and terminals: Use tweezers to place the strain gauges
> and terminals against the alignment lines. Secure their relative
> position with low-tack cellophane tape, ensuring the metal foil grid
> faces up.
> Bond the gauges: Roll one end of the tape back to expose the backing
> sheet. Apply a small drop of CN glue to the backing sheet and stick
> the tape back in place, applying even pressure.
> Wire the gauges: Solder the connecting wires to the terminals. The
> gauges are typically wired into a half or full Wheatstone bridge
> configuration to maximize the signal.
> Mount the gauge "feet": Design the device so that it can be mounted to
> the test specimen by bonding or spot welding, depending on the
> material.
> Calibrate the finished gauge: The clip gauge is a nonlinear device and
> requires calibration against known displacements before use. Monitor
> the "zero" reading during calibration to check for permanent offsets,
> which may indicate localized yielding.
>
> For a detailed guide on the design and calibration, academic resources
> like the paper on the "Optimum Design of a Ring-Shaped Clip Gauge"
> provide an analytical framework.
> ---------------------------------------------
>
>
> https://link.springer.com/article/10.1007/s40799-020-00417-1#:~:text=To%20design%20a%20gauge%20with,available%20in%20commercial%20mathematical%20software
> .
>
> This video shows a completed one, but is otherwise not as good as one
> might hope.
> https://www.youtube.com/watch?v=5ry-7iqQIEw
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users
>