Development in HeeksCAD/HeeksCNC
David Nicholls
I've only just read the notes you made at the top of the 'Home' page
for HeeksCAD. i.e. where you want to revert some of the code to make
it more simple. I suspect I have felt the same as you. I became
frustrated with other people's changes breaking something I was
using. To relieve my frustration, I have been modifying a local copy
of HeeksCAD and HeeksCNC so that I can 'just use it'. I have been
interested in merging some of my changes back into the main branch but
I'm unsure what the 'main branch' is now.
The other reason I haven't been too quick to merge my changes back
to the main branch is that there are three issues that I would need to
resolve.
- I have added the Python runtime to HeeksCAD so that all
PropertyDouble values are interpreted by Python. I have expanded this
so that all 'double' values can include keywords such as 'inch' and
'mm' with the value being interpreted correctly. eg: '1/8 inch / 2'
is a valid value to enter even if we're in metric mode. The last time
I spoke to you about this, you were not eager to include a Python
runtime within HeeksCAD itself.
- I have used 'flex' and 'byacc' utilities to write a GCode
parser. I use the cygwin versions of these utilities to generate the
source code and have made the Windows build and the codeblocks build
(for Linux) work but I have never been able to make the cmake system
work. The benefit to this GCode parser is that it handles recursive
grammar declarations such as square brackets and variable names
correctly. I also added a mechanism so the GCode interpreter would
keep track of the current fixture number and added it to the NCCode
object. This allows me to render the NCCode graphics (red/green
lines) correctly with respect to a Coordinate System object that forms
part of the fixture definition.
- I have used and expanded Fixture objects significantly and I have
no interest in the myriad of #ifdef macros that enable/disable them.
I didn't want to work through all the permutations and combinations
that are formed when Fixtures are considered 'STABLE_OPERATIONS' or
not.
I'm quite happy to keep my own copy of the code and make it work as
I want it to but I do need to offer my changes back to you. Would you
like to see other people's changes or are you eager to just have your
own copy of the code so that you are not forced to keep a functioning
system out of a constantly changing source tree?
Your notes in the Home page mentioned FreeCad. If you would prefer
to avoid the need to continually merge other people's changes into
some master source tree, how would you feel if I used much of the
HeeksCNC code to develop a CNC feature in FreeCAD? I'm not offering
to do this yet as I don't understand the FreeCAD source well enough
yet. I'm just wondering what direction you want the HeeksCAD and
HeeksCNC projects to follow.
Ta
David Nicholls
dan falck
I hope I don't come off as a heretic here, but here goes:
I have gotten very interested in FreeCAD (
https://sourceforge.net/apps/mediawiki/free-cad/index.php?title=Main_Page
) lately and think it's a good platform for future development. If you
asked me about FreeCAD about a year ago, I wouldn't have been
impressed. It has improved -a lot- in just the last 4 months.
I have been studying the FreeCAD code a lot over the last month and
have ended up fixing some bugs in the DXF import/export libs. In the
process, I have discovered that there is a ton of functionality under
the hood. They use the same opencascade libs that HeeksCAD uses.
Python scripting is built into FreeCAD, by default. I really like
python, so I'm into that. The constraints engine in FreeCAD is very
sophisticated and user friendly. That's a good one to not have to
support :). I have noticed that they have a much more lively forum
than our mailing list. I have been seeing a lot of activity every day
from the devs. Every day there seem to be updates from four different
coders, who seem to be working together to improve the base part
system and the constraints/sketcher.
I also put up a brief explanation of why I like it on my blog:
http://opensourcedesigntools.blogspot.com/
The way I see it the HeeksCNC/libarea and Opencamlib toolpath libs and
the HeeksCNC post processing scripts can be adapted to anything. Dan
has set up a very flexible system. I really like HeeksCAD/HeeksCNC a
lot, but:
I think it would be good to lean on the FreeCAD devs to do the heavy
lifting (ie keeping platform/os and the build system in order). I
think trying to keep up with platform issues saps our energy. It
would be good to just work on CAM for our own shop needs.
I would like to leave the work in maintaining the design/constraints
part to the people who have a real stake and understanding of it. I
have been using the constraints engine in FreeCAD and those guys are
nailing it. It works well. That is an issue that has caused more than
a few headaches in keeping things running in HeeksCAD. Dan has stated
that he wants to remove constraints from HeeksCAD- I agree.
The FreeCAD devs don't know anything about CAM programming, but I
think they have left the door open to us to use their system.
We could collaborate on a new CAM 'workbench' for FreeCAD. The FreeCAD
guys have set up another very flexible application that could be the
'mothership' for us.
With this said, I would say that simplifying HeeksCNC is a very good
thing. Leaning towards pyQt dialogs would be great too. We should
continue working on the path libs and post processor scripts. They can
all be used by FreeCAD or any application, for that matter.
So far, I have been able to backplot gcode into FreeCAD and get
libarea geometry out of it for post processing with the HeeksCNC
python scripts. I am just getting into picking points for start/ends
of profiles and will go down the pyQt dialogs creation path very soon.
I don't really have a clue how to deal with the tree that has all the
tool table and operation objects in them yet.
If anyone is interested in my experiments playing with the python
console to manipulate things in FreeCAD here is a link to an unedited
scratchpad that I use now to keep track of how to do things:
http://pastebin.com/LvVfLsts
Thanks,
Dan Falck
On Nov 16, 3:28 pm, David Nicholls
Dan Heeks
I agree with everything Dan Falck says.
I need to make HeeksCNC simpler and more robust, so I will be removing
stuff that I don't yet understand and unfortunately this will include
your work on fixtures. However, I will be keeping various of your other
work which I use.
This doesn't mean your work will have been wasted.
You should work with Dan Falck to make a FreeCAD/CAM system.
Also, as you have a working HeeksCNC system, maybe you could make it
available for me look at, open source somewhere. Have you learnt to use
git with the github repository? On github the idea is that everyone has
their own fork.
If you are happier with SVN, how about making a new Google Code project.
Dan Heeks.
Dan Heeks
You have added a lot of value to HeeksCNC. Thank you; I am using the
drilling operation almost every day, for example. But I think it would
be good for me to freeze HeeksCNC and spend some time trying to make it
work reliably.
Dan Heeks.
On 17/11/2011 03:38, dan falck wrote:
David Nicholls
thanks for that. I will move my code to my git copy and let you
know when it's ready. It might take me a few days to get it all
together. How would you feel about seeing some of the HeeksCNC
source in FreeCAD? It won't move across verbatim but there should be
sections of code that could plugin. I'm quite pleased with the copy I
have at the moment. I agree with the idea of removing the undo-
engine. I suspect that would stablise the system nicely. I have
added quite a few 'click on midpoing', 'offset from midpoint' types of
right mouse menu items that make drawing quite a lot easier. I have
also done some work with the probing and toolchanging that makes
changing tools much easier. I probe a tool length switch, then probe
the work surface. Each time I change tools I probe the tool length
and I put the three together to use tool length compensation. It
makes tool changing and continuing much easier. The other change that
I'm quite proud of is the rewrite of the Contour operation code so
that the ramping tool entry function is quite reliable now (famous
last words, I know).
I suspect that I will continue with my local copy for a little while
but, once I understand the FreeCAD source better, will start to
contribute to that. I appreciate the opportunity you have given me.
I believe we have come a long way and I am still committed to helping
to create an open source CNC system.
Ta
David Nicholls
On Nov 17, 8:01 pm, Dan Heeks <danhe...@gmail.com> wrote:
> David,
>
> You have added a lot of value to HeeksCNC. Thank you; I am using the
> drilling operation almost every day, for example. But I think it would
> be good for me to freeze HeeksCNC and spend some time trying to make it
> work reliably.
>
> Dan Heeks.
>
> On 17/11/2011 03:38, dan falck wrote:
>
>
>
>
>
>
>
> > Hi David,
> > I hope I don't come off as a heretic here, but here goes:
>
> > I have gotten very interested in FreeCAD (
Dan Heeks
I am happy for any of HeeksCNC code to be used for absolutely anything,
that is the spirit of a permissive license like BSD.
It would be great to have it in FreeCAD.
If you guys have some good success with FreeCAD, I will probably use it too.
I am interested in 'click on midpoint', 'offset from midpoint' kind of
functions.
Let me know when it's all in your git copy and I'll see what I can take
from it.
Dan.
Dan Heeks.
'click on midpoing', 'offset from midpoint'
Sliptonic
excited with both the culture and the technology. The idea of having
HeeksCNC be the basis of a CAM workbench in FreeCAD is just awesome.
I've gotten very comfortable with the HeeksCNC way of thinking to the
point that it's the standard that I compare everything else to. The
post-processor flexibility is seldom appreciated but way ahead of
anything else in the open source world.
I don't think FreeCAD is there yet, but I get the impression it's
moving toward a model like Eclipse (or Gimp, Inkscape, Wordpress,
Joomla, Blender, etc etc) where the core application can be customized
with extensions. Hopefully the extensions could be installed directly
from within the application. I think this would let the core
developers focus on interfaces and let the community get very creative
with extensions. Users end up with exactly what they need and no
more.
There's a lot of work between here and there and I'm committed to help
keep HeeksCAD and HeeksCNC functional in the interim.
David, Have you done any more work on your inlay operations?
David Nicholls
I have done some more work. The chamfering bit is used to 'sharpen'
concave corners and and endmill is used to clear away most of the
material but there is a space between these two areas that is note
cleared. I've called these 'crevices' for want of a better word.
i.e. they are small concave areas. I have added code to detect these
crevices in the female half of the operation by using the offset code
twice. I offset the sketch inwards by the endmill's radius and then
back by the same amount. This sounds silly but the offset back does
not create exactly the same result. Where there was a sharp corner in
the inner offset, it adds an arc around it when offsetting back out.
I then subtract this shape from the sketch (I extrude them into solids
to do this subtraction) The difference between them describes these
'crevice' areas that I now clear with a pocket operation using the
chamfering bit. I hardcoded the bit diameter as something small (0.1mm
or similar).
The only scenario that I have not yet covered is where the male half
of the shape also has these crevice areas. I can't use exactly the
same scenario as the male half is made up of multiple sketches while
each female half is made up of a single sketch. I need to figure out
a way of aggregating multiple sketches into a solid I can subtract
from the total. I think I know how to do it but I haven't had time to
get there.
All this means that the Inlay operation should work but it depends
on the geometry of the shape. If there are not too many small
crevices then it should be alright. If it's a fine detail picture
then there will be more trouble.
Ta
David Nicholls
David Nicholls
Dan,
I think I have the code in order now. Fetch it from github.com/
DavidNicholls/heekscad and github.com/DavidNicholls/heekscnc. I use
the 'HeeksCAD VC2008.sln' and HeeksCNC VC2008.sln files.
The change history is;
- Fixed problem with Ramping in a Contour operation for short open
sketches.
- Rewrite the Contour operation tool paths so that the ramping
functionality would be more simple.
- Added the ability to use Python-interperated values in the
'offset from ...' dialogs. eg: '2 inches, 0,0' is a valid offset now.
- Added 'offset from' options to the right mouse buttons for all
of the objects that previously had 'click on...' options. i.e.
Vertex, Line, Arc, Sketch, Coordinate System, Circle and Edge (point
already had it). These work both for drawing and object manipulation
(scale, translate or mirror)
- Modified the design rules checking routines so that they include
the object title as well as the ID so that the erroneous objects are
easier to find.
- Rearranged the design rules checking routines so that all the
checks at the various class levels always work.
- Added design rules checks for various operations. eg: is the
type of tool valid for this operation? This would have saved us when
we had a touch-probe selected for a Contour operation.
- Fixed problem where the original selection filter was not being
reinstated correctly with the 'P', 'L', 'A', 'C' or 'S' keys were
being used to filter selections. I believe this is all working
correctly now.
- Added property to the Program object that determines whether or
not the design rules checks are automatically made just before
generating GCode. If design rules issues are found, a 'do you want to
continue' type of dialog is presented so the user can either continue
generating GCode or abort it.
- Removed logging line from the tool length probing routines in
emc2.py
- Added 'skip switch and fixture probing cycles' property to the
Program object. This option is included if the tool change movement
includes a tool length measurement. If it's turned on then the tool
length switch and the fixture heights are NOT probed at the beginning
of the GCode program. In this situation, an extra question is added
to the GCode program asking the operator to confirm that the tool
length switch and the fixtures have both been probed during this EMC2
session. NOTE: I have NOT implemented this such that these values are
remembered between EMC2 sessions. You MUST probe these at least once
each time EMC2 is started.
- added 'pause after tool change' property to the Program object.
If this is true, the tool is changed, its length is probed, the
machine moves back up to the machine's safety height and then a pause
is added so the operator has the opportunity to re-start the spindle
and put the tool length switch away.
- Changed all the probing classes so that their properties are
stored away in configuration and reinstated when needed again. They
used to always use default values. They will now use the most
recently set value.
- Fixed problem when importing probed points into a Fixture.
- Fixed problem where the Fixture's touch-off Z value was not
being used correctly when a fixture's surface was probed.
- Added work-around in the Contour operation when it lowers back
down from the clearance height. It now looks at the coordinates
visited in earlier machining and lowers back down to one of those
levels if the X,Y coordinates match correctly. i.e. it won't have to
slowly ramp down above an area it has already cut.
- Added an 'OnSetTool()' system that allows operation objects to
be notified when the user selects a new tool in its properties. The
first implementation of this is where the Drilling operation changes
the depth of cut to match the cutting tool's cutting edge length,
turns off dwell and turns off peck drilling when a centre-drill tool
is selected.
- Added a feature whereby the operator may use the 'S' (sketch),
'P' (point), 'A' (arc), 'L' (line) or 'C' (circle) key while selecting
graphics in the graphics window. This works either for a fence
operation or an individual left mouse button click. When these keys
are pressed, the selection filter is changed to ONLY include the
selected object type. When the key is released, the previous
selection filter is re-instated.
- Fixed the 'Set all operations active' and 'Set all operations
inactive' menu options beneath the 'Operations' object.
- Changed CounterBore operation rendering to allow for Fixture
coordinate system objects (both translation and rotation).
- Changed Drilling operation rendering to allow for Fixture
coordinate system objects (both translation and rotation).
- Added a 'click on midpoint' and 'offset from midpoint' menu
option for Edge objects.
- Fixed problem where the centre-points of arcs (or circles) was
incorrect. This was a problem if they were being used as drilling or
counterbore locations.
- Added feature whereby the GCode lines (red/green from NCCode
objects) are rendered in the correct location and orientation based on
a fixture's coordinate system.
- Fixed problem in the EMC2 tool table generation routine for the
Linux build.
- addition of the 'startup files directory' option in the
'machining options' list.
- added 'dimension color' to the 'Options' window.
- added 'Generate EMC2 Tool Table' option to the right mouse menu
of the Tools (plural) object.
- fixed spelling error in standard TAP size descriptions
- added facility to select multiple point objects before placing
cylinders at their locations
- started to add 'Bolt' menu to the Solids menu for adding
standard bolt objects but this is not very well progressed yet.
- added warning if a zero feed rate value is detected during a
feed movement in the parsed GCode.
- fixed problem where the drilling operations were not being
rendered properly for the tool's size.
- added ability to click on a coordinate system object's origin
via the right mouse menu (for both drawing and transformation
operations)
- added option to the Tool (singular) object's right mouse menu to
'add the solid representation of the tool to the model'.
- added 'Project Sketch onto Solid' option to the right mouse menu
when at least one sketch as well as at least one solid has been
selected.
- added radio buttons to the extrusion dialog so the user can
select which axis they want to extrude along rather than only allowing
the Z axis to be used.
- changed dimension object's SCALE property so that its value is
retained between sessions.
- added default diameter value to the CounterBore object's
startup. If the child elements are sketches of circles and all their
diameters are the same then this diameter is used for the CounterBore
operation's property.
- made the 'tool change movement' options work (at least for 'Use
G28 and then probe tool length') This probes tool length switch as
well as each fixture height at the beginning of the program. It then
probes the tool length for each tool change. The 'touch off point' in
the fixture object MUST be defined. The X,Y values are used to decide
what position to use when probing down to find the fixture's top
surface level. The Z value of the 'touch off point' is then assigned
to the probed surface location. i.e. use X,Y and then set Z.
- fixed problem where the movement between multiple fixtures was
not occuring at the machine's "safety height".
- added 'Click on Location' menu option beneath the right mouse
button menu for a vertex (of a solid). This works both for drawing
and transformation (translate, scale, mirror or rotate) operations.
- some merging from the standard HeeksCAD and HeeksCNC source
base.
- added 'Undefined' option to the 'emc2_machine_units' property
(of the Program object) so that we could be sure the value has been
set. This value is used when the local tool table properties are
written to an EMC2 tool table file. i.e. the conversion from metric
to imperial is done if this option indicates that it should.
- added option for the centre-drill to either have its properties
defined manually (as it was earlier) or chosen from a set of standard
sizes. This change includes the change of the solid model that
represents a centre-drill's geometry.
- added fractional (inch) description of centre-drill description
if the size falls exactly on a common fractional inch representation.
- added checks to ensure the drilling operation's "depth" property
is a positive number.
This version has infinite line intersections available for the
drilling operations. It also has the ability to accept a Python
script in any of the 'floating point number' property fields. i.e.
instead of only being able to accept '3.4' or some other floating
point number, it can accept '3.4 * sin(45)' or maybe 'diameter /
2' (assuming that there is another property for the updated object
that's called "diameter".
One of the changes I did was based on an idea that Dan Falck had.
i.e. to add a coordinate system object to a fixture object so the
origin of the GCode could be shifted from the origin of the drawing.
I did this and have produced an example where I can machine three
different faces of a solid object using three different fixtures along
with their corresponding coordinate system. I will attach that as a
text file here to give you an idea of what it's like.
Ta
David Nicholls