Probe and LinuxCNC

Probe and LinuxCNC

etfrench
Mentor Mentor
3,261 Views
20 Replies
Message 1 of 21

Probe and LinuxCNC

etfrench
Mentor
Mentor

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.

ETFrench

EESignature

0 Likes
Accepted solutions (1)
3,262 Views
20 Replies
Replies (20)
Message 2 of 21

LibertyMachine
Mentor
Mentor

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)


Seth Madore
Owner, Liberty Machine, Inc.
Good. Fast. Cheap. Pick two.
0 Likes
Message 3 of 21

etfrench
Mentor
Mentor

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

ETFrench

EESignature

0 Likes
Message 4 of 21

LibertyMachine
Mentor
Mentor

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


Seth Madore
Owner, Liberty Machine, Inc.
Good. Fast. Cheap. Pick two.
0 Likes
Message 5 of 21

daniel_lyall
Mentor
Mentor

@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.

 


Win10 pro | 16 GB ram | 4 GB graphics Quadro K2200 | Intel(R) 8Xeon(R) CPU E5-1620 v3 @ 3.50GHz 3.50 GHz

Daniel Lyall
The Big Boss
Mach3 User
My Websight, Daniels Wheelchair Customisations.
Facebook | Twitter | LinkedIn

0 Likes
Message 6 of 21

etfrench
Mentor
Mentor

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.

 

 

ETFrench

EESignature

0 Likes
Message 7 of 21

marty
Contributor
Contributor
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

 
Message 8 of 21

etfrench
Mentor
Mentor

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.

ETFrench

EESignature

Message 9 of 21

marty
Contributor
Contributor

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.

 

 

 

0 Likes
Message 10 of 21

alexfehr1987
Participant
Participant

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?

0 Likes
Message 11 of 21

marty
Contributor
Contributor

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.

0 Likes
Message 12 of 21

alexfehr1987
Participant
Participant

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?

0 Likes
Message 13 of 21

alexfehr1987
Participant
Participant

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>]
Message 14 of 21

marty
Contributor
Contributor

Good catch, thanks!

0 Likes
Message 15 of 21

alexfehr1987
Participant
Participant

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.

0 Likes
Message 16 of 21

marty
Contributor
Contributor

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. 

0 Likes
Message 17 of 21

etfrench
Mentor
Mentor

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.

ETFrench

EESignature

0 Likes
Message 18 of 21

alexfehr1987
Participant
Participant

@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. 

0 Likes
Message 19 of 21

marty
Contributor
Contributor

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. 

0 Likes
Message 20 of 21

alexfehr1987
Participant
Participant

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

0 Likes