@vectronic, while we regularly work with Autodesk to improve the Pocket NC post processor, they host it and make it available to the public. You can download the post processor from the Autodesk Post Library and then edit it if you would like.
I hope this helps,
Q
Thank you for your response.
Beyond the complexity and effort of implementing, is there anything anyone knows of which would prevent the extension of the post processor to support Fusion 360 probing steps being exported to be exported either to use the “Josh Pieper Probe” scenario or any other probe option which might be integrated into the PocketNC hardware/LinuxCNC implementation?
Again being new to CNC (but not to software/electronics) I don’t want to dive down a blocked off rabbit hole…
We’re in the process of developing routines in Kinetic Control which will make it more feasible to implement probing in Fusion’s post processor. We should have something within the next month or so.
Honestly, as I use my probe right after I manually positioned the part, I prefer using it in a manual manner. Then I can assure the proper position and orientation, before I press the start-button. I usually align my coordinate frames by referencing small drillings with 4 automated movements (executed directly on the machine) - which increases the accuracy in comparison to referencing just faces.
Does the current post processer support probing in fusion?
Thanks!
The current post processor should support probing, as it’s implemented for the Solo. Unfortunately, the V2 does not have the necessary implementation yet to run the probing codes properly.
Oh ok, is that coming soon?
While implementing Solo probing I did my best to also implement the V2 side of things. I ran out of time, though, and the V2 implementation was left unfinished as I had to change gears to other priorities. We don’t currently have a timeline when it will get picked back up. This is something I definitely want to get in there at some point, though, so I’ll keep you posted when that changes.
@john has this moved on at all? I have a probe physically and electronically working but Not with Fusion.
On the penta post I had to change a setting to enable multi axis probing and it appears to respond to the protected move call, but I’m not sure if the settings on that call are related to the Fusion probing settings.
The protected move makes probe contact with the workpiece before its completion and errors out. I’ve tried changing offsets to fault find but not making much headway.
Is there any reference material for how to call probing built in routines?
Any thoughts would be greatly appreciated.
All the best,
Barry M
More info…
%
(AXIS,stop)
(PROBETEST)
(MACHINE)
( VENDOR PENTA MACHINE)
( MODEL POCKET NC V2-10)
( DESCRIPTION PENTA MACHINE POCKET NC V2-10)
(T3 D=2. CR=1. - PROBE)
G21
G90 G94 G40 G17 G91.1
G53 G0 Z0.
(PROBE WCS3)
M5
G53 G0 X63.5 Y63.5
M700 T14
M0
T14 M6
G17 G90 G94
G54 G0
G0 A90. B0.
M254 P9
G59.3 G0
G43 H3
G1 X0. Y0. F10000.
Z55.
o call
o call [0.] [0.] [6.] [1000.]
o call [0.] [0.] [5.] [1000.]
o call [1.] [1.3] [0] [0] [1] [1] [0]
G1 Z55. F10000.
o call
G53 G0 Z0.
(PROBE WCS3)
G56 G0
G0 A90. B0.
M254 P9
G59.3 G0
G1 X0. Y0. F10000.
Z55.
o call
o call [0.] [0.] [6.] [1000.]
o call [0.] [0.] [5.] [1000.]
o call [1.] [1.3] [0] [0] [1] [3] [0]
G1 Z55. F10000.
o call
G53 G0 Z0.
G53 G0 X63.5 Y63.5
G56 G0
G0 A0. B0.
M30
(AXIS,stop)
%
text doesn’t seem to paste properly
Unfortunately, there has not been any progress on this front. I believe there is some basic probing functionality if you’re willing to only probe with the rotary axes at A0 B0 and only want to probe thicknesses or coordinates in Rotated Work Offsets space. I don’t think you can automatically update your work coordinate system as certain functions that are called by the probing routines aren’t implemented on the V2 and will error. In your case, though, it sounds like it’s not even getting to that point. My best guess is that you don’t have your tool length offset for your probe set properly or something about your Fusion setup isn’t right. The protected moves are in there to stop the probing cycle if it hits something. Since its hitting something, you’re not in the right spot. This could be the stock is in the wrong place, the tool length offset of your probe isn’t properly locating the center of the ball on the probe, your work offsets are shifting your location incorrectly or your Fusion setup/tool path are incorrect. All that said, I haven’t touched the probing functionality for V2s in a long time and am not exactly sure how I left them, so there are no guarantees about them working.
As for posting G code, you can use three backticks (```) before and after the code so it formats it with a monospace font:
; example G code
%
G20
G90 G94 G40 G17
G53 G0 Z0
G0 A0 B0
G0 X0
M5
M0
T4 M6
G43
S8500 M3
F20
G0 A90
G0 X1 Y1
G1 Z0
G1 X-1
G1 y-1
G1 X1
G1 Y1
G49
G53 G0 Z0
M5
M30
%
Thanks @john,
Yep you’re correct I managed to figure out getting past the first hurdle, but then it errors out when it tries to write to offsets.
Are there any good resources that I could read so I can have a go at hacking something together? Tried chat gpt but couldn’t get anything useful.
Any other ideas would be appreciated.
Many thanks again
Barry M
I dug up the progress I made on the pocketnc implementation. If you’re lucky these files will “just work”, but I have my doubts. If you upload all these files to your Pocket NC by either ssh’ing them to /home/pocketnc/subroutines or just uploading them via the Kinetic Control interface (but they’ll fill up your programs list if you go that route), then the implementation files will at least exist. As to whether they work or not, that’s more questionable. I ran out of time to test them, so you’ll be going down uncharted waters. When I do get around to finishing the implementation, testing and rolling these out in Kinetic Control, you’ll want to be sure to remove the ones you uploaded to ensure you’re using the official versions.
gcode.zip (8.3 KB)
Thanks @john,
That’s awesome, I will treat it as alpha code and be wary at all times. Initially I only want to be able to probe Z offsets and the XY extents of my stock. I’ll keep this thread up to date with my findings.
Once I’ve got some initial work out of the way I’ll then be moving into much more complicated parts and that’s when the in process probing will be really useful.
Just to say again, much appreciated!
All the best
Barry M
Hi @john,
At least for Z probing it seems to be working, the only issue I’m having is that when I install the probe and set its length offset via the tool length procedure, because the probe registers on touching the button rather than when the button is depressed its length is off by the button travel, approximately 1.05mm. Is there any way to get the tool setting routine to recognise if its probing T14 and add 1.05mm onto its measured length??
Or perhaps add that offset onto the probed location in the probing subroutine? Add it on to newWorkZ below in the subroutine “move-wcs-by-deviation-in-rwo” ??
G10 L2 P#<wcs> X[ #<newWorkX> ] Y[ #<newWorkY> ] Z[ #<newWorkZ> ]
Any thoughts would be much appreciated.
All the best
Barry M
So after some digging, I’ve come up with this:
in the tool-probe.ngc file in the subroutine:
O<tool-probe> SUB
I’ve added a parameter:
#<_ToolProbeButtonTravel> = 1.05/25.4 ( Set Tool probe button travel here, 1.05mm / 25.4 to use Inches as per _UseInches param)
And then created a conditional statement that applies it if T14 is being measured
o10 IF [#<T> NE 14]
G10 L1 P[#<T>] Z[-3+#<_OriginOffset>+#<_ToolZProbe>-#<_ProbeSensor123Offset>]
o10 ENDIF
o20 IF [#<T> EQ 14] (T14 is the probe and triggers on contact with thetool probe rateher than depressing it)
G10 L1 P[#<T>] Z[-3+#<_OriginOffset>+#<_ToolZProbe>-#<_ProbeSensor123Offset>+#<_ToolProbeButtonTravel>]
(debug, T14 selected, assuming Probe, allowing for 1.05mm button travel.)
o20 ENDIF
Not sure if the sign should be + or - will need to try it out tomorrow and see.
I assume if I add this to my local subroutines folder it will override the default routine??
Thoughts?
Cheers
BPM
Yes, copying the tool-probe.ngc to your local subroutines directory and making your modifications there will override the default.
Thanks @john,
After a lot of experimenting and figuring out how fusion expects the probe to be configured and then understanding how the PNC is setup I have modified routines to get the probe working correctly for z probing operations. X/Y tbc, hopefully they will work now the probe is setup appropriately for fusion.
When Fusion calls the probe on and probe off routines are these mapped to a pin on the Beaglebone. If so is there a reference mapping for the BBB pins?
Looking for a signal to aid with preventing fault conditions when the probe is not connected.
Any suggestions would be greatly appreciated.
Many thanks
Barry M
The probe on and probe off routines don’t trigger a pin on the Beaglebone to change. They set software variables that can be used to abort if a probe is not detected on the Solo. The V2 is set up to use the basic_probe feature (see /opt/pocketnc/Settings/features/basic_probe), which simply doesn’t error. There’s not a great way to splice something in there (certainly nothing official).