CAM Development Roadmap: Difference between revisions

From FreeCAD Documentation
(Created page with "This page will discuss strategic objectives for Path Workbench. This is not a list of individual features to implement but broader objectives that will steer the overall dire...")
 
No edit summary
Line 1: Line 1:
<languages/>
{{Page in progress}}
<translate>

== Purpose ==
</translate>
{{TOCright}}
<translate>

This page will discuss strategic objectives for Path Workbench. This is not a list of individual features to implement but broader objectives that will steer the overall
This page will discuss strategic objectives for Path Workbench. This is not a list of individual features to implement but broader objectives that will steer the overall
direction of Path development.
direction of Path development.


For a list of specific features, please check Mantis.
For a list of specific features, please check Mantis.

== Core Objectives ==
These things make Path a reliable, performant, and flexible tool. Work in this area is never-ending and always high priority.

* Broad test coverage
* DRY code base

== Tool Paths ==

work strategies that we currently cannot support but should

== Path Modifications ==
* should be able to use the same boundary extension types for all operations where it makes sense. For example adaptive, surface, waterline,


== Post Processing ==

* Post to git
Gcode for the hobbyist is transient. It's used once and then likely not retained. If the user needs it again, they simply re-post the original file.
For commercial users under certain certification standards, the gcode is a long-term asset and often may require version control protection.
Integrating version control directly into the post-processing workflow might be an interesting feature.

* modular output for older machines with limited memory.
Many old machines have an extremely limited capacity for gcode. While physically able to produce more complex paths, the very large output from surfacing and adaptive
toolpaths make them unusable. It would be useful to post-process the output with an eye on the size of the resulting file. As a file reaches a maximum size, the post-processor could insert a spindle retraction and stop gracefully, then the next file could continue. Output files would be numbered to indicate sequence.



* Robust support for 2D workflows
*

== Path Analysis ==
* Tip up Prediction / avoidance
When 2D cutting (laser/waterjet/plasma) of material supported on a grating, small parts cut out of the main stock can 'tip up' creating a crash hazard for the cutting tool
during subsequent moves. Being able to predict these events or avoid them by ordering paths would be desirable.
([https://shopfloorlasers.com/nesting-software/263-heads-up Further reading])


== Discussion Threads ==

Links to forum thread discussions related to this topic

* Discussion: FreeCAD is not ready for 1.0 ([https://forum.freecadweb.org/viewtopic.php?f=8&t=43461 forum thread])

</translate>
[[Category:Common Questions{{#translation:}}]]

Revision as of 16:07, 27 June 2020

This documentation is a work in progress. Please don't mark it as translatable since it will change in the next hours and days.

Purpose

This page will discuss strategic objectives for Path Workbench. This is not a list of individual features to implement but broader objectives that will steer the overall direction of Path development.

For a list of specific features, please check Mantis.

Core Objectives

These things make Path a reliable, performant, and flexible tool. Work in this area is never-ending and always high priority.

  • Broad test coverage
  • DRY code base

Tool Paths

work strategies that we currently cannot support but should

Path Modifications

  • should be able to use the same boundary extension types for all operations where it makes sense. For example adaptive, surface, waterline,


Post Processing

  • Post to git

Gcode for the hobbyist is transient. It's used once and then likely not retained. If the user needs it again, they simply re-post the original file. For commercial users under certain certification standards, the gcode is a long-term asset and often may require version control protection. Integrating version control directly into the post-processing workflow might be an interesting feature.

  • modular output for older machines with limited memory.

Many old machines have an extremely limited capacity for gcode. While physically able to produce more complex paths, the very large output from surfacing and adaptive toolpaths make them unusable. It would be useful to post-process the output with an eye on the size of the resulting file. As a file reaches a maximum size, the post-processor could insert a spindle retraction and stop gracefully, then the next file could continue. Output files would be numbered to indicate sequence.


  • Robust support for 2D workflows

Path Analysis

  • Tip up Prediction / avoidance

When 2D cutting (laser/waterjet/plasma) of material supported on a grating, small parts cut out of the main stock can 'tip up' creating a crash hazard for the cutting tool during subsequent moves. Being able to predict these events or avoid them by ordering paths would be desirable. (Further reading)


Discussion Threads

Links to forum thread discussions related to this topic