Probe and LinuxCNC

[etfrench]

The probe routines appear to work in Fusion 360, but fail to generate gcode with LinuxCNC post processor.  What needs to be done for this to generate gcodes?

Sample output:

Vendor url: http://www.linuxcnc.org
Legal: Copyright (C) 2012-2015 by Autodesk, Inc.
Generated by: Fusion 360 CAM 2.0.2541
...
Error: Spindle speed out of range.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error: Failed to invoke function 'onSection'.
Error: Failed to invoke 'onSection' in the post configuration.
Error: Failed to execute configuration.
Stop time: Friday, December 9, 2016 8:34:26 PM
Post processing failed.

[LibertyMachine]

The Linux post processor does not contain the necessary code to generate probing cycles. The Linux post available ONLINE is also missing the needed syntax. I've not heard any plans to add probing to any post outside the big ones (Haas, Fanuc, Heidenhein etc)

[etfrench]

What more does it need than G38? http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g38

[LibertyMachine]

The probing routines currently employed in the post processor are formatted to output code recognized by the Renishaw probing system. This is a series of G65 P9xxx calls with specific letter addresses representing the feature and related information. It may be possible to bring something into the Linux post, but that's going to be a custom job involving no small amount of work. You could attempt it yourself or find a reseller to assist you in that endeavor. There is a list of resellers at the top of the CAM forum

[daniel_lyall]

@etfrench have a look on the Linux forum there are some Macro b/macro codes on there you can use to do the probing and it's in the pathpilot manual as well, it uses code base on the fanuc way of doing it.

[etfrench]

Thanks for reminding me of those.  I tried using them a while back, but had trouble with the probe crashing into the workpiece.  I think there have been a few bug fixes since.

[marty · Accepted solution]

Hi everyone, I finished adapting Tomach's probing routines and postprocessor for LinuxCNC today. It does almost everything you might need, finding and setting 3-axis coordinate systems off of stock or part geometry from Fusion360, and then inspecting parts after machining. Here it is in action inspecting a 3d printed test part: https://photos.app.goo.gl/mTiJ3PbBUnsnzHb86

Here's a zip file with everything you need. Put the subroutines in your Macros folder linked from your linuxcnc .ini file. Then use the LinuxCNCWithProbing.cps postprocessor.
https://www.dropbox.com/s/gpe869eolzx2jbw/LinuxCNC%20PathPilot%20Probe%20macros.zip?dl=0

The best part is that instead of using probe-basic, Verser's probe screen or other probe UI's, you can use whatever LinuxCNC UI you want. Because probing isn't dependent on the UI anymore! As you set up probing per job, the settings for probing are saved in Fusion360, so you never have to re-think how to probe, and you can visualize the process as well as specifying the exact probing locations right there in Fusion360.

Credit goes to: 
Tormach for the PathPilot Fusion360 probing routines
XoomSpeed for the postprocessor, test routines and test 3d print 
I adapted the XoomSpeed postprocessor to work with LinuxCNC, mostly just debugging some errors and adding G64 on a per-operation basis

[etfrench]

Well, I finally got my touch probe installed.  These probe routines work really, really well.

One question, do these routines use the probe calibration offset generated in Probe Basic, or does this need to be entered in Fusion 360?

Many thanks for creating these.

[marty]

Awesome! 

Work to be done before it's fully functional IMHO: 

- modify the python inspection output to match the standard format required to ingest the results into Fusion360's inspection functions 

- modify the WCS rotation routines to actually set the rotation. Currently it displays but does not actually set the rotation. 

We could certainly add in the code to use Probe Basic calibration. That code already exists, just need to copy and paste. I haven't been using those functions.

[alexfehr1987]

Has anyone tried this sucessfully? I am having trouble with the nc Code. Probing in z, Boss xy works. But edge xy sets g54 to nirvana. Can someone please post the nc Code from the example part, so I can compare?

[marty]

I'm using LinuxCNC 2.8.4.

Are you working in metric or inches? 

Gcode attached. Note that I use T1000 for my probe, other than that it should work for your setup, too, if all your macros are in the right place and probe HAL connected correctly.

[alexfehr1987]

Hi!

my code looks definetly different:

probing with probebasic works fine. z probing and xy boss with your pp and makros too.

what do you mean with probe and hal?

[alexfehr1987]

found the issue with metric:

o<f360_tip_radius> sub

(we will need to know the accurate - tool table - tip radius)

o100 if [#<_metric> EQ 1]

    #<unit_conv> = 25.4<------ this needs to be 1, because on metric machines we have metric tooltables 😉

o100 else

    #<unit_conv> = 1

o100 endif

o<f360_tip_radius> endsub [[#5410 / 2] * #<unit_conv>]

[marty]

Good catch, thanks!

[alexfehr1987]

Current process for probe calibration is to alter the probe diameter in the tool table. For probe basic users there is a calibration in the gui. Unfortunatly its Just saved in pb. Perhaps one could assign this value to a # variable in linuxcnc to be able to use it directly in the probing Makros.

[marty]

I don't want to make any changes to the basic config that refers to anything from ProbeBasic. A big value of the simplicity of the current version is that it works regardless of the LinuxCNC GUI and doesn't require anything other than access to the subroutines.

What we're heading towards, though, is a version that is tailored to work better with ProbeBasic. And which ideally uses the same subroutines to avoid duplication and reduce troubleshooting and failure modes. 

That is an easy change, though, to have ProbeBasic spit out the probe calibration value as a numbered (and persistent, through linuxcnc.var) variable. Currently it passes that variable as an argument to the subroutines and it's ingested as below by the subroutine:

 #<calibration_offset> = #10  (=0.0000)  

(Probe Diameter)
  #<probe_diameter> = #5410

  (Probe Radius)
  #<probe_radius> = [#<probe_diameter> / 2]

  (Probe Centerline Offset)
  #<probe_center_offset> = [#<probe_radius> - #<calibration_offset>]

  (remove probe tip diam and cal offset from probed width calculations)
  #<probe_diameter_offset> = [#<probe_diameter> - [#<calibration_offset> * 2]]

If you want to submit it as an official part of probebasic, here's the repo: https://github.com/kcjengr/probe_basic

Alternatively, you could go in and modify the f360_tip_radius subroutine to refer back to the probebasic calibration. 

[etfrench]

It's probably best to keep it simple.  I'm still trying to decide if I want to keep Probe Basic as my main screen.

[alexfehr1987]

@marty everything works good for now. i modified the probe tip sub to implement the calibration offset of probe basic.
but now i have a 4th axis and the machine simulation is not working anymore(error: post is overwriting machine config). the 4 axis code posts correctly with the inverse time feed. comparing the post to the latest tormach one, there are many differences. i dont knwo what to change to make it work for 4 axis simulation again. 

[marty]

I don't know, either, but I suppose I would start by transplanting the probe code from the postprocessor I provided into the existing known good Tormach w/ 4th-axis post. 

[alexfehr1987]

Another topic: edge angle probing and wcs rotation set is currently not supported with the subroutines. Has anyone implemented this ?