I have Josh Pieper excellent probe for my machine and the internal and external cylinder probing routines all work as expected.
I am trying to figure out how to use it to set the x, y and z coordinates using TCPC mode through Fusion 360 probing, but I get an error when Post Processing using latest post processor for Kinetic Control. The error is " Error: The probe cycle ‘probing-x’ is machine specific and must always be handled in the post configuration.
Error in operation: ‘Probe WCS2’"
For my example I am using the numbered block in the Penta course.
Am I doing something wrong or is Fusion probing not supported?
I believe Penta’s current post processor for Fusion does not support probing routines.
I’ve played around with using the stock LinuxCNC probing scripts, but haven’t been able to get super consistent results with the values out of the fusion post processor. I have a fork going of jpieper’s repo with a sample post processor, but it is still very prone to crashes
Thanks for the reply, I will check out your sample post processor and give it a try. Unfortunately not sure I will be add much value as coding skills are very limited. Hopefully eventually Penta will add the capability to the official post processor.
Is Penta’s current post processor for Fusion 360 open source? I can’t seem to find it on GitHub but am new to the CNC side of things so might be missing what I’m looking for…
@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.
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.
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.
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?
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.
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.
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.
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” ??