Path and openvoronoi

Mods CAM/Path
1

Hi,
I have followed FreeCAD for a while, and the Path workbench is interesting to me to generate tool paths which are kind to the cutters and machine., i.e. no plunges and no full width cutter paths. Mainly for small, (less than 3mm) cutters which can be a bit fragile and have a wont to break very easily.

Four firsts here for me, programming python in anger, open casade, voronoi library along with the diagrams and their pitfalls(mainly regular polygons and edge combinations which would form part of a regular polygon, and of course the FreeCAD object model.

Here is a screen shot of the medial axis path I have currently working(sort of, it still has bugs :slight_smile:, along with a generated gcode file, and the two source files which make this. The component is called a FacePocket, as a face is currently the only selection item to generate the path. It only generates one Z level at the moment as I am more interested in getting the path correct before moving on and I have not implemented Climb v Conventional as yet. It still requires 1/2 toolwidth + material allowance offsetting of course, but that has not been done so I can test for intrusions of the toolpath into the model.


In InitGui.py Initialize add

from PathScripts import PathFacePocket

You will need to compile and install the open voronoi source from https://github.com/aewallin/openvoronoi

ToDo

1: Accept any wire primitve, are splines and Beziers etc part of wires?
2: Climb v Conventional.
3: Tool offset
4: Spiral plunge to initial spiral pocket of first largest circle.
5: Possibly an algo to cut only metal where previous arcs have already cut away the stock.


Problem 1
The regular polygon problem was solved with a simple hack, wiggle the points by around 100th of a micron, this makes them non regular and the solvers will reach a solution. If this is not done open voronoi generates assertions which blows up FreeCAD. I have not worked out how to protect FreeCAD from open voronois assertions, but since introducing the wiggle have not had many crashes and am able to code and test.

Problem 2
The Path visualisation of some gcode arcs breaks down, the path you see in the screen shot has weird artifacts in the top left and bottom right. The gcode is correct, I can view it in OpenSCAM and in Mach3. I know there are CNC controllers out there which do not handle large arcs but I would favour keeping the large arcs in the model and the post processor handling breaking down arcs into smaller arc as required, otherwise if the model was to be rotated in a nesting scenario 4 arc segments would then have to become 8. Also there would have to be more python processing om every refresh.

Question 1
The path is generated from the chamfered wire points not the filleted wire of the model. I see in open voronoi there are ArcSites and am wondering if they will be more efficient than breaking down the arcs into segments. However there were no examples of using them that I could find in the many excellent examples.


EDIT Due to comment 6 I have removed the source files from the zip as that would seem to violate GPL3, the gcode file is still in there as an example of valid gcode which Path cannot interpret properly.
FacePocket.zip (5.02 KB)
Screenshot_2015-10-17_19-30-25.png

2

openvoronoi - what an interesting piece of software! Thanks for the link.

3

What a magnificent first post and entry into the forum. :open_mouth:

Welcome to the FreeCAD forum :smiley:

I will surly test. this sounds nice.

4

This is exactly the stuff Path needs. Thank you!

Mark

5

Having som problem getting started.

OS: “Arch Linux”
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.16.5749 (Git)
Build type: Unknown
Branch: makepkg
Hash: 9abedaf0d20563028ee4b8344862dc5a97e955a1
Python version: 2.7.10
Qt version: 4.8.7
Coin version: 3.1.3
OCC version: 6.9.0

Copyed all 3 files in zip file to ../Mod/Path/PathScripts and made changes to Path InitGui.py

When choosing Path workbench i get popup:

unbound method GetResources() must be called with CommandPathFacePocket instance as first argument (got nothing instead)

And Message in python output:

Traceback (most recent call last):
  File "<string>", line 85, in Initialize
  File "/usr/share/freecad/Mod/Path/PathScripts/PathFacePocket.py", line 130, in <module>
    FreeCADGui.addCommand('Path_FacePocket',CommandPathFacePocket)

What could I be doing wrong?

6

Hope that green circles aren’t flipped arcs. :wink:

Nice to see all this progress in this area!

7

Openvoronoi is GPL3.

8

Source files removed, seems a shame I cannot share this work. Only alternative seems to be Boost which would be a lot more work to get working and require more understanding of the guts of FreeCAD than I have at the moment.

9

I had mentioned this in another post, but this might be something to look at - libactp , Adaptive Clearing Tool Path Library and it looks like it has a more agreeable license. The code is here - https://github.com/Heeks/libactp. I have no idea if it would be usable or not. :confused:

Mark

10

Strange as the calling codes reads:

if FreeCAD.GuiUp: 
    # register the FreeCAD command
    FreeCADGui.addCommand('Path_FacePocket',CommandPathFacePocket())

Seems to be missing ()?

11

True, now the Path workbench loads. :smiley:

However when selecting a bottom face of a pocket and aplying the pocket operation i get :

Path workbench activated
Sel : Clear selection
Sel : Add Selection "Unnamed.Pocket.Face13(-12.806054,-12.229201,5.000000)"
<PySide.QtGui.QLineEdit object at 0x7f77893e0518>
Active view is pocket : 1[*] (at 0x633dce0)
Sel : Clear selection
Sel : Add Selection "Unnamed.Pocket.Face13(-8.421999,-11.306244,5.000000)"
Running the Python command 'Path_FacePocket' failed:
Traceback (most recent call last):
  File "/usr/share/freecad/Mod/Path/PathScripts/PathFacePocket.py", line 126, in Activated
    FreeCADGui.doCommand(snippet)
  File "<string>", line 9, in <module>

'module' object has no attribute '_ViewProviderFacePocket'Active view is pocket : 1[*] (at 0x633dce0)

I am not sure that I aply the pocket operation correctly as my operation is placed outside the Path project and not as a leaf under the project as in you screencapture.

Is there any trick to this?

12

Would this code be a violation of the GPL3 if distributed separately from FreeCAD ?

13

I don’t think it would, though it would have to be GPL3 as well, the code I posted WAS in violation as it had LGPL in the headers.

Maybe if there were a plugin style interface to FreeCAD then plugins could have whatever license they wanted without ‘contaminating’ the FreeCAD
base.

14

Reading the GPL3 licence I do not think your code was in violation of the GPL3 even if your headers was LGPL, as long as you wrote or had copyright to the code. When linking to GPL3 code you automatically pr. GPL3 imply(relicence) that all code is GPL3.(Am no layer, so just my understanding).

So I guess FreeCAD’s problem with incorporating GPL3 is that FreeCAD’s copyright holders do not have the right to such automatic re-licensing.

Anders Walin’ CAD website is referencing a problem regarding Opencascade’s licensing, witch according to FreeCAD’s wiki has ben overcome by some licence changes.

http://www.anderswallin.net/cam/

FreeCAD looks promising (but there are GPL-problems with OpenCascade).

http://www.freecadweb.org/wiki/?title=Licence

OpenCasCade License side effects (for FreeCAD version 0.13 and older)

The following is no more applicable since version 0.14, since both FreeCAD and OpenCasCade are now fully LGPL.

Could this fact change the licensing difficulty. I guess (if it is the case that GPL2 code is now acceptable in FreeCAD) that Anders might be willing to re-licence or dual licence his code as GPL2/GPL2+

http://www.freecadweb.org/wiki/?title=Licence

Open Source developers

Can use FreeCAD as the groundwork for own extension modules for special purposes. They can choose either the GPL or the LGPL to allow the use of their work in proprietary software or not.

15

Acording to a old post http://forum.freecadweb.org/viewtopic.php?f=15&t=3051&p=23716#p23716 Anders opens up for a licence exception for FreeCAD :smiley:.

16

If the code is GPLv3 licensed it probably won’t be merged to FreeCAD master anytime soon as that is current FreeCAD policy regarding licences. Beyond that there are no issues with the current FreeCAD licence that would prevent anybody to create 3rd Party GPLv3 modules for FreeCAD.

17

To add to triplus’s reply:

  • (L)GPL3 is technically not compatible with (L)GPL2. The only exception is when you use (L)GPL2+, which allows higher versions than version 2 too. FreeCAD uses LGPL2+ so is compatible with (L)GPL3.
  • You can mix LGPL and GPL. But the whole result will be regarded as GPL, because GPL is more strict than LGPL.
  • We want to keep only LGPL code (or 100% compatible such as BSD or MIT) inside FreeCAD’s master code. Although there is no more problem today to have GPL code too, it gave us so much headache in the past that we prefer to not take any risk again and stay away from it.
  • Nothing, therefore, prevents you from creating a LGPL3 or GPL3 module for FreeCAD. But it won’t be merged in the FreeCAD source code, you’ll need to keep it as an independent project. This is not a bad thing, and it’s even better for many reason (you have full control over it and don’t need to ask for merge requests, etc). Many excellent workbenches are kept today as independent projects (Drawing dimensioning, Workfeature, etc), and you’ll get all the same support from the FreeCAD community, and in the future these will certainly be integrated better and better within FreeCAD.
18

So I guess there are at least 2 options:

  1. Ask Anders for a licence exception so that an inclusion into FreeCAD source is possible.
    In such a case what exception would be acceptable for the FreeCAD project?

  2. Include openvoroni in a GPL3 external module.
    Is it possible today with a module to integrate into the Path workbench in a seamless way to add functionality like this?
    What would the preferred way to do this?

19

Hard to answer as there are a few factors to determine what makes sense not only the licence. For example FreeCAD might gain superb POV-Ray support but that doesn’t necessary say POV-Ray code should be merged to FreeCAD master. And for example we discussed if libarea library should be merged to master or not…

When there are external libraries involved and the licence is for example GPLv3 i would say first try to code external 3rd Party module and make it easy to install for FreeCAD users.

20

Ok, I’m just a user/programmer who is scratching an itch. I understand the [L]GPL issues, however starting a whole new module is a whole different ballgame.

I would prefer it if there were some mechanism to extend the path workbench rather that replace with another module. A simple way to begin with, would be a way (on a per user basis, to keep to the GPL3, which basically says end users can do what they want with any GPL code as long as they conform to copying on rules ) to register an extension to the Path workbench by specifying a directory. This directory would HAVE to contain an Init???.py which would be called from workbench init.

This is a very simplified view of someone who does not know the guts/ inner workings of FreeCAD, it may be easy it may not be.

Creating a repo on GitHub or similar is no problem for me.

In the meantime I will continue scratching my itch for my own pleasure.