Initial commit of probing support#4
Draft
hagmonk wants to merge 3 commits intoCarvera-Community:mainfrom
Draft
Conversation
Contains: * Basic probes with stock firmware * Probe away from WCS origin * Override driving WCS * Integration with manual tool changes * NC and NO probes * Power on for Carvera Air probe * Protected probe moves * The start of some documentation * Probe playground model for Fusion with stock/community toolpaths
Author
|
There's a bunch of TODOs in here, and I have some questions I need to ask about the M4xx macros, but I've tested the probes for the stock firmware pretty extensively. I figured it would be worth just getting this up for review and can iterate on feedback or issues at the same time. |
* Add more setup documentation, links, and screenshots * Tweak Carvera Air probe laser: make sure it's turned on for duration of onCyclePoint
* Fix logic bug in WCS offset calculation. Fusion allows us to shift the WCS relative to the probing point by proving an expected clearance value from the WCS. It turns out this clearance value is already compensating for the tool diameter. We were incorrectly also applying this compensation which is now fixed. * Adds logic for first probe operation: During an initial probe-z, Fusion will move to a clearance height relative to the current WCS coordinates in the machine. This was an unprotected rapid move, which could expose the probe to a crash if a workpiece of sufficiently different size were loaded. To mitigate this we introduce the following logic: - if this is the first operation, and it is a probe-z operation - onSection: do not move to the operation Z height - onRapid: do not move to the operation Z height - onCyclePoint: do not move to the operation Z height - onCyclePoint probe-z handler: probe Z-120 Since new programs can be assured to start at the G28 clerance Z height, this means the probe will be able to make a G38.3/5 safe move to the clearance height, stopping if it detects a collision. This code is complicated by the fact tat G38.x moves are purely relative. Therefore we can't simply change the rapid moves to a G38.3/5 because the post-processor is unaware of the starting coordinates. * Introduce handler.absoluteRapidMove to speed up retractions at the end of probing cycles. This was handled by onSection before but not as a rapid. * Set double-tap retraction to tool.diameter instead of 2x diameter, since the extra distance was not necessary * Tweak gFormat to support decimal places for G38 etc. Remove gCycleModal to keep changes at a minimum * Rename handler.relativeMove to relativeSafeMove for clarity * Add documentation references for Fusion's probing docs
Collaborator
|
How is this coming along @hagmonk ? |
Author
|
I have sketched out taking a look this weekend, will update ya'll shortly! |
|
converting to draft until ready for merging |
faecorrigan
added a commit
that referenced
this pull request
Jan 13, 2026
Adding Community Work on Post Processors to Official Makera Github. Fixes: Fusion: 4th axis simultaneous machining bugfix. Going below 0 in Z no longer breaks arc moves Fusion tool library expanded for the entirety of the makera toolbit library When exporting split files include tool number in the header of each file allow ext control of air Fixes bug with high feedrate moves Improves toolpath dump information Added machine simulation capable machine files and updated their kinematics to match the machine properly Added HSMlib and cvs tool files for the entire tool library added passthrough and other manual NC commands. See the cps file for more information or https://www.youtube.com/watch?v=1xPcono_qTk&t=250s added the ability to select several manual tool change types from a dropdown that defaults to stock behavior. The manual tool changes include a manual tool change that works with the stock C1 and a manual tool change that requires the community firmware. Feel free to contact me for more information about this feature Freecad: Tool libraries added Vectric (Vcarve and Aspire) added manual tool changes for the stock firmware with the C1 machine. If you plan to never mix tool shank sizes in a job, then you can set the flag colletChange to false (see the current post processor). If you set colletChange to 'false' then the post processor does not check for shank size and does generate a functionally correct gcode file presuming all the bits you are using have the same shank size. WARNING!!! If you do not pass shank size (or do so incorrectly) and colletChange is set to 'true' then the post processor will issue a warning and generate a functionally incomplete gcode file. Other machines: files added to github repo for future pull requests Contributors: @faecorrigan @SergeBakharev @mcowger EDSWall on Discord
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Contains: