Extending existing G38.2/G38.3/G38.4/G38.5 codes

More
26 Nov 2015 13:33 #65821 by DaBit
I have a 3D touch probe which is always mounted at the same fixed location/orientation, not centered with the spindle. (picture) .

To make full use of the advantages this provides, I created an NGC program that probes a ring of known diameter and produces a file with the offsets to the spindle center for X probing directions (where X is not limited to 4), and a HAL-component that uses this file to generate the correction data for a probe trigger.

The normal sequence of things now becomes, for example:

G38.2 X10 Y10 Z10
#<proberesult_x> = [#5061 - #<_hal[probe-compensation.0.correction-x-make]]
#<proberesult_y> = [#5062 - #<_hal[probe-compensation.0.correction-y-make]]
#<proberesult_z> = [#5063 - #<_hal[probe-compensation.0.correction-z-make]]

Not very handy for files littered with G38.x. Slightly easier is:
G38.x axes
o<compensatie_probe_results> call

But still that requires editing of all files using a probe.

A much nicer way to handle this would be to remap/extend the G38.x codes. But when I read the manual , it says:

14.1. Existing codes which can be remapped
The current set of existing codes open to redefinition is:
Tx (Prepare)
M6 (Change tool)
M61 (Set tool number)
M0 (pause a running program temporarily)
M1 (pause a running program temporarily if the optional stop switch is on)
M60 (exchange pallet shuttles and then pause a running program temporarily)
S (set spindle speed)
F (set feed)


Is there a method to extend existing G-codes not in this list? Or am I forced to either do the correction manually after every G38 or define an e.g. G37.x that mimics G38?

Please Log in or Create an account to join the conversation.

More
26 Nov 2015 14:25 #65823 by ArcEye
Hi

Is there a method to extend existing G-codes not in this list? Or am I forced to either do the correction manually after every G38 or define an e.g. G37.x that mimics G38?


The problem with trying to remap G38.2 etc is that they are group 1 modal codes ( same as G0, G1, G2, G3 etc)
There is a lot more going on than just the probe move.
I don't think you can remap them easily, or change them without a lot of code rewriting
see
src/emc/motion/control.cc and command.cc for the hard coding of probing

You seem to have quite a good method for dealing with your offset probe, the difficulty adding calls to gcode to fix the offset is minimal.
Much probing requires some sort of offsetting, even if the probe is held in the spindle, probe head diameter / 2 at the minimum, to get the exact edge position

Even if you made G39.2 an alias for G38.2 plus offset calculation, you would have to alter your post or do some other change to amend the number, which is probably no less hassle.

regards

Please Log in or Create an account to join the conversation.

More
26 Nov 2015 18:16 #65836 by DaBit
I do not want to rewrite the code, only add an extra prolog/epilog to the existing functionality. It should not be too hard to add that possibility to the existing remap/extend infrastructure, although I am not capable of doing that.

Adding the compensation call before probe results are being processed is not that hard, and a viable workaround. The only minor problem I have with it is that when I decide to use external code (such as probe_screen) I have to modify that code every time a new release appears. In my opinion the control should take care of the internal stuff, not the user programs.
Creating a G39.x is slightly cleaner since then we have an 'uncompensated probe move' called G38 and a 'compensated probe move' called G39.

Another minor issue is that my probe is wireless and outputs a 'system OK' and 'trigger' signal. Communications can fail, the internal measurement electronics can fail, batteries drain, etc, so I need that system OK signal. I also have two probes attached; a tool length sensor and the touchprobe. There is no really clean way to handle this situation. Currently I simply combine the probes like this: motion,probe-input = toolsetter | (motion.digital-out-00 & (touchprobe_trigger | !touchprobe_ok)), which forces me to enable/disable with M64/M65. That already went wrong once; extracting the remaining pieces of sheared off M3 bolts out of an aluminium housing is not funny.
Did some effort to combine these probe signals in a HAL component and look at motion.motion-type, which works for 'make' moves but not so easy for 'break' moves since there is a one servocycle delay and motion complains 'probe was not active at the start of G38.4/G38.5'. That route was not succesful, but I have an idea how to deal with those issues (basically a selector switch, the probe that generates an edge is the one being selected).
Luckily we have HAL and comp, so we can solve all this. But the issue is that there is no generic mechanism to tell LinuxCNC that attached devices are actually working. Example: 'Enable mist coolant', OK, great, but is the misting system OK? Do I actually have air pressure and is the coolant reservoir not empty?

Please Log in or Create an account to join the conversation.

More
26 Nov 2015 23:43 #65841 by tommylight

But the issue is that there is no generic mechanism to tell LinuxCNC that attached devices are actually working. Example: 'Enable mist coolant', OK, great, but is the misting system OK? Do I actually have air pressure and is the coolant reservoir not empty?

Well all of this is easy to a certain extent: there are cheap humidity sensors or 2 wires in front of the nozle a Darlington transistor and a resistor will do the job easily to report back that you actually have mist, air pressure switches are easy to find and modify like from a compressor (there is one already there if it has a spare contact or just piggy back a small micro-switch), the reservoir again same as mist but in the actual tank. Do a google search for simple humidity sensor or rain detection sensor, mostly used in cars for turning on wind-shield wipers.
Regards,
Tom

Please Log in or Create an account to join the conversation.

More
27 Nov 2015 08:35 #65855 by cmorley
He means there is no status feedback in linuxcnc for these requests.
Gmoccapy and gscreen do have message systems (popup dialogs) that you can connect to an
'error' hal pin from your custom component. not very clean but doable.

user configurable error handling in linuxcnc and error handling in HAL components is a weakness.

Chris M

Please Log in or Create an account to join the conversation.

More
27 Nov 2015 13:07 #65860 by andypugh

To make full use of the advantages this provides, I created an NGC program that probes a ring of known diameter and produces a file with the offsets to the spindle center for X probing directions (where X is not limited to 4), and a HAL-component that uses this file to generate the correction data for a probe trigger.


I think you are making this too hard.

LinuxCNC supports tool offsets in all 9 axes. Just drill a hole with the spindle, probe the centre (with the hole-probing routine in nc_files/examples then touch-off the tool table for the probe tool to 0,0 to store the X and Y offsets of the probe relative to the spindle.

I use T99 for my probe.

M6 T99 G43 then loads the probe XYZ offsets. G43 with any other tool (without XY offsets) then puts the axis system back on the spindle.

Please Log in or Create an account to join the conversation.

More
27 Nov 2015 16:45 - 27 Nov 2015 16:45 #65870 by DaBit

He means there is no status feedback in linuxcnc for these requests.


Exactly. I once read about a method using rtapi_xx calls to accomplish that, but one would want a simpler interface for that to define errors and corresponding reactions.

How do the guys retrofitting 'real' machines do this? These have sensors on just about everything.

I think you are making this too hard.
LinuxCNC supports tool offsets in all 9 axes.


Well, that is only valid if the sensitivity of the probe is a perfect circle (or half sphere).
Which it is not in case of the regular 6-point-contact Renishaw lookalikes like mine. Although I must admit that the inaccuracies caused by that seem to be far lower than the positioning accuracy.
But I wanted to see the deviations anyway, so I had to write code for that. Normally one needs to compensate for probe tip diameter also and do the probe_point=probe_point - tip_radius anyway. Writing a component that takes in the file with N calibrations points and do the math is not that much harder than considering 4 special X+/X-/Y+/Y- cases.





Probe tip diameter is 4mm, Radius turns out quite accurate.

The same with combining probes. I wrote a component that can combine N probes into one output:
PROBECOMBINE(9)              HAL Component              PROBECOMBINE(9)

NAME
       probecombine - Combine multiple probes into one output

SYNOPSIS
       loadrt  probecombine [count=N|names=name1[,name2...]] [personal‐
              ity=P,P,...]

DESCRIPTION
       Component to combine multiple probe signals into a  single  out‐
       put.  Use  the  'personality'  value  to determine the number of
       probe inputs; range is 1-32.
       The component functions as a selector switch which  is  actuated
       by  an edge on one of the probe inputs. The probe that generates
       an edge is the one being sent to the  output  after  debouncing.
       If  more  than one probe input changes in a cycle, the result is
       the logical OR of the changing probe inputs.  Thus,  if  one  is
       active the output goes to '1'.
       When  a  probe state goes from enabled to disabled, the internal
       probe output is pulled to '1'. This is  a  valid  edge,  and  is
       reflected on the probe-out pin.  This is done to notify LinuxCNC
       when communications fail or another error occurs; LinuxCNC  will
       complain about the unexpected edge.
       To  prevent  the  situation  where a failed probe that pulls the
       output to '1' blocks further motion, an optional auto-deactivate
       timeout  can  be  used. The probe output will be deactivated the
       timeout number of seconds after the last edge.

USAGE EXAMPLE
       Say we have a toolsetter switch that is always  attached  and  a
       touchprobe that is removable. Then, a valid setup could be:
       loadrt probecombine personality=2
       addf probecombine.0 servo-thread
       net toolsetter_sw probecombine.0.probein-00
       net touchprobe_sw probecombine.0.probein-01
       net touchprobe_enabled probecombine.0.probe-ready-01
       net pi probecombine.0.probe-out motion.probe-input
       setp probecombine.0.enable 1

FUNCTIONS
       probecombine.N (requires a floating-point thread)

PINS
       probecombine.N.probein-MM bit in (MM=00..personality & 0x1f)
              Probe input

       probecombine.N.probe-activelevel-MM bit in (MM=00..personality &
       0x1f) (default: 1)
              Probe active level. Usually '1' for high active

       probecombine.N.probe-ready-MM bit in (MM=00..personality & 0x1f)
       (default: 1)
              Probe ready signal. '1' when the probe is ready, '0' when
              not

       probecombine.N.enable bit in (default: 0)
              Enable module. Set to '1' after everything is  configured
              to prevent false edges

       probecombine.N.probe-out bit out
              Combined probe output, connect to motion.probe-input

PARAMETERS
       probecombine.N.debounce-cycles u32 rw (default: 3)
              Number of cycles used for debouncing

       probecombine.N.auto-deactivate float rw (default: 10.0)
              Auto-deactivate probe output this amount of seconds after
              the  last  edge.  This  is  used  to  prevent  a  deacti‐
              vated/removed  probe  from tying the probe output to high
              and generate errors downstream in LinuxCNC. Set to a neg‐
              ative number to deactivate

       probecombine.N.dbg-probestate u32 r
              For debugging: combined probe state

AUTHOR
       DaBit (dabitATicecoldcomputingDOTcom)

LICENSE
       GPL

LinuxCNC Documentation         2015-11-27               PROBECOMBINE(9)

Maybe it is overkill, maybe not. The worst that can happen is that it does not provide any benefits.
Last edit: 27 Nov 2015 16:45 by DaBit.

Please Log in or Create an account to join the conversation.

More
27 Nov 2015 17:19 #65872 by andypugh

Exactly. I once read about a method using rtapi_xx calls to accomplish that, but one would want a simpler interface for that to define errors and corresponding reactions.


How about:
linuxcnc.org/docs/2.7/html/man/man9/message.9.html
The following user(s) said Thank You: DaBit

Please Log in or Create an account to join the conversation.

More
27 Nov 2015 20:20 #65879 by DaBit
Nice, thanks!

BTW: results of probing the ring and producing calibration data. Graph shows the deviation of the measured diameter of 12.0027mm vs angle



This is fairly repeatable, also at different locations on the table. The probe seems far more accurate than the positioning since I cannot detect the lobing so all this is less useful than I initially thought it would be, but compensating still doesn't hurt.

Please Log in or Create an account to join the conversation.

Time to create page: 0.131 seconds
Powered by Kunena Forum