Brad - I would whole-heartedly welcome this, and be look forward to
contribute, especially in the CAM and "non-standard machine development"
(such as for CMM, arms, forming etc).
I've been a user/fan of FreeCad for quite a while (Rhino3d is my daily
drive, but I really like some of the workbenches available in FC
especially in optics and sheetmetal), and worked through as much of the
"pre1.0-post1.0" fun without too much difficulty. I did however hit a
challenge that I think could use some focus; the nice thing about
LinuxCNC (and back to its EMC2 days) is that it is wonderfully flexible
- almost to a point that one could believe that no two machines on the
planet might be identical. This leads to a challenge of trying to
maintain standards and consistency.
I realize that CAM output with FC is still evolving, particularly
between the legacy API and refactored posts (one thing that really
caught me up during my development) and what I wished existed was a
framework for "here are rules we can violate, and here are rules that we
will not violate and why, for the sake of the roadmap". (Rather than a
"don't do that" response.) A good example of this would be the
definition of "safe" and "clearance" heights. I was tersely pointed to a
non-existent wiki page as the "definition", but no further. To my joy,
another developer stepped up.
I'm as comfortable with software development as I am with machining
professionally and machine building (although I admit my C and C++ is
better than my python), however I do love to tinker deeply under the
hood (pretty much an accepted requirement for LCNC). Back in February, I
attempted to write a FC post processor for my unmodified Mazak VCN
vertical mill. Keeping in mind that "changing the function on the
control to match FreeCad's output" wasn't an option. (Of which that was
a recommendation). Very specifically I had a concern (and a desire to
modify) the details of a tool change; the order that Path spit out the
TC details was retract, spindle off, TC, rapid to safe plane, spindle
on, engage (example). The clear Z-height from TC to table is 20 inches.
Rapiding down to 1/8" above the part at 1000ipm before the spindle
starts is a scary experience. Setting the safe plane 20" high is a waste
of cutting (air). A number of comparative CAM programs all had me
trained for the spindle to have accel'd to speed before that move to
safe height. Additionally, the Mazak Matrix control required some
additional move data on the same block as a G43 TLO, not something once
can disable in the control, so really needed to be addressed in the
post-processor. Again, this was earlier in the year and a lot more
development has occurred I'm sure, but the forum conversations somewhat
directed to "it would be serious surgery to be able to make that change"
and "a post-post-processor would be the appropriate choice". I did
actually succeed in writing that post-processor, including 1 block
"look-behind-ahead" which was the only way I could override the tool
change sequence to my liking, despite it not being my cleanest work.
Being able to query the Path classes for and after machining operations
would be helpful, even if that type of access is "serious surgery".
That above situation doesn't leave me with bad feelings; with a larger
developer group it is difficult to have one opinion that solves all
wishes. Ed, Larry and Julian certainly contribute so much to the
community and I'm thankful for it. I would also like to participate
however what pushed me back was that the source for this information
really seemed to need to come from other developers via forum questions
thus being "drip-fed", rather than being well documented online (and
thus memorialized).
I think a collaboration between the two groups would help each other
immensely - figuring out how to limit some development can be just as
beneficial as unlimited flexibility,and those paths are joined by
cooperative efforts.
Just my 0.02, but due to tariffs, not actually valued at 0.02.....
Regards,
Ted.
On 8/12/2025 6:19 PM, Brad Collette wrote:
Greetings from FreeCAD land!
Last weekend the FreeCAD community had a very small gathering in
Springfield, Il. While we only had a handful of folks attending in person,
this was our third North American meetup and our seventh or eighth real
world gathering. (Our big meeting is every February in Brussels and timed
to correspond with Fosdem). For the last couple years, we've been meeting
in conjunction with the KiCAD community.
Anyway, the meetup in Springfield was dominated by interest in CAM. Almost
every attendee is either working on CAM or connected to a makerspace that
wants to use it. One of the highlights was a zoom meeting with Neil
Gershenfeld from MIT Center for Bits and Atoms and founder of the FAB
Academy. They are very anxious to incorporate more FOSS software in their
curriculum and are pushing FreeCAD hard to develop multi-axis CAM
capability. They are also willing to provide equipment or other resources
to accelerate development.
A few of us had also attended LinuxCNC meetups in the past and one
sentiment that was expressed repeatedly was; "We need a closer
relationship with the LinuxCNC guys!" so here I am to get that rolling.
I guess to start things off; Are you guys interested in a closer
relationship and exploring some joint development? Is this the best place
to communicate?
Cheers
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
