next gen dxf2gcode

[zappa...@gmail.com]

Hello, venerable dxf2gcode developers!

I'm willing to do some developement on dxf2gcode in my free time, and submit the results to upstream repository. But since the ideas I have will substantially change the way dxf2gcode works, I would like to discuss them with the developers, maybe somebody has objections or even better ideas.

What I have in mind is to change the way how shapes are converted to operations. Right now every shape *is* a operation, you can only enable it or disable it, and set various parameters.

My idea is to have operations as completely separate entities. The operation would be identified by its type and parameters, specific to this type. The CNC program preparation process will consist of creating the respective operations from the respective shapes (for simple cases there would be an "Auto" button which would do something similar to what happens now on DXF load).

The operations will be displayed on a separate tab (third -> "Entities", "Layers" and "Operations"). The cluster of widgets under the "Layers" would go away, freeing space to see more layers. 

You create operations by selecting some shapes (one or many) and pressing some button on the toolbar (like "+" or something like that). A dialog box will appear with several tabs, one tab for each supported operation. You switch to the respective tab, change the parameters of the operation (default values will be filled from configuration dialog, like it is done now), and press OK. Ths created operations will appear on the "Operations" tab.

As you can see, this approach makes it possible to create several operations from the same shape. This can be very useful in some circumstances.

Right now I have in mind four types of operations. What operations are available will depend on the selected type of CNC machine, of course.

CONTOUR - go on the contour of the shape, parameters:

• for milling & lathe machines:
  
• tool number
• Z infeed depth
• Z final depth
• for drag knife & laser engraver machines:
  
• Z infeed depth
• Z final depth

INSIDE - go along the inner contour of the shape, off by tool width. This is available only for milling CNC machine type. Parameters same as for CONTOUR.

OUTSIDE - go along the outside contour of the shape, off by tool width. Operation similar to INSIDE.

Both INSIDE and OUTSIDE operations will choose G41 or G42 operation (or software emulation) automatically, depending on shape direction. These operations will be available only for closed shapes, they have no sense for an open contour, as it has no "inside" or "outside".

These operations are targeted at milling machines, but could be supported for laser engravers too, if it makes sense cutting at a distance from the contour). If that makes sense, then we could support "tools" for laser engravers too, they would just have a "diameter" to know how far from the shape to follow.

FILL - this is something I have in mind for later time, the ability to completely carve inside a contour. This is something I severely miss in dxf2gcode now. Parameters:

• for milling machines and laser engravers:
  
• tool number ("tool" for laser engraver as discussed in the above section, would define the distance between lines that would fill shape internals).
• Z infeed depth
• Z final depth

Some of the parameters currently displayed under the "Layers", and which are specific for each shape, should be converted to global parameters as I see no meaning to have them per-shape. These parameters are:

• Z retraction area
  
• Z safety margin
  
• Z workpiece top
  
• Z feed rate
  
• XY feed rate
  

I'm not sure where these parameters should go, perhaps to yet another tab named "Setup" or something like that. Maybe that tab should come first and activate by default after loading a new DXF file, since the first task anyone should do is to set up the workpiece they are going to process.

Having operations separated from shapes will allow to easily extend dxf2gcode later with new operations without having to touch existing code.

I think this development should be done on a separate branch, to not interfere with the normal development/release cycles.

[Christian Kohlöffel]

Hello Andrey,

 

thanks for your time in supporting to develop dxf2gcode.

 

I see the big improvement which such a change could bring to dxf2gcode. In some previous changes I made to dxf2gcode I also faced with the limiting factor how “operations” are handled in shapes. (e.g. cutter compensation, start shapes etc.).

 

The only thing I want to clarify is, that these operations or cutter compensation are also used for lathe machines (This might be the tool radius). Additionally operations might be used on not closed contours. These for sure do not have a detail like inside or outside, but they have left or right.  But this is just a detail ...

 

I fully support your proposed change and your right you should start at a separate branch first until there is a version which might become our new development branch. If you need any support from my side or any hints feel free to ask.

 

Best regards

Christian

--
--
You received this message because you subscribed to the Google
Groups-group "dxf2gcode-dev".
To post a message, send mail to dxf2gc...@googlegroups.com
To unsubscribe, send mail to dxf2gcode-de...@googlegroups.com
See http://groups.google.de/group/dxf2gcode-dev?hl=en for more options
and the dxf2gcode project page at http://code.google.com/p/dxf2gcode/
---
You received this message because you are subscribed to the Google Groups "dxf2gcode-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dxf2gcode-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

 

[zappa...@gmail.com]

To be honest, I still don't "grok" those lathe CNCs. As such, I don't quite imagine what tool parameters apply to them.

As far as I understand, they have only X and Z axis, right? How then you would apply the XY dxf drawing on a lathe? How a DXF drawing for a lathe would look like? Are there any lathe examples in the dxf directory?

A separate branch is good also because I still plan to work in parallel on fixing bugs in the mainline. I just found yesterday yet another one... will try to catch it in a few evenings... ruined my workpiece... again :)

[Rando Sauvage]

Hi,

I was one of the developers of DXF2GCODE. I didn't do anything since years, but I am still using it and still following the list.

I like your idea and I am glad to see that people and Christian are still involved in the development.

Just a few remarks about your idea:

• As for the "global parameters", please don't set "Z feed rate" and "XY feed rate" as global because they are not. I always change the feed rate (even with the same tool), depending on the operation: for a coarse milling requiring the full width of the tool, the XY feed rate will be much slower than for a finishing pass that removes a few 1/10mm.
  
  
• What I love in DXF2GCODE is its efficiency: it is perfect for prototyping because there is no need to spend hours to configure it: just draw your piece, name each layer with the tool parameters and everything is auto-magically configured in DXF2GCODE (I like the possibility to auto-configure the tools through the layers). Just have to select milling order and generate the GCODE. Your "Auto" mode will do the same I guess?
  
  
• I think that your "operation" organisation shouldn't modify anything for that, but please keep the "Custom GCode" functionality, it is quite useful (at least for me :-P), eg to add a pause, probing a tool, ...
  
  
• One nice feature would be to have a "Drill" operation too (using the appropriate GCODEs).
  

Other than that, I really like your idea, and would love to see the "FILL" operation into dxf2gcode too ;-)

Regards,
Xavier

--
--
You received this message because you subscribed to the Google
Groups-group "dxf2gcode-dev".
To post a message, send mail to dxf2gc...@googlegroups.com
To unsubscribe, send mail to dxf2gcode-de...@googlegroups.com
See http://groups.google.de/group/dxf2gcode-dev?hl=en for more options
and the dxf2gcode project page at http://code.google.com/p/dxf2gcode/
---
You received this message because you are subscribed to the Google Groups "dxf2gcode-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dxf2gcode-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

http://rando-sauvage.info

[Rando Sauvage]

P.S. forgot to say that "Z workpiece top" should not be global either: just one example of operation that I often do:

• I have a raw material of let's say 25mm height so workpiece top Z is 25mm (or 0mm, depending how I work).
• Then I do a surfacing operation to remove 5mm. The new workpiece top Z is now 20mm (or -5mm, depending how I work).
• I expect the following operations to start at 20mm height and not at 25mm height.

So it is also important to keep the "Z workpiece top" not global either, but per operation ;-)
(my example was simple, but there are more complex cases where one would want to do a fine milling at the bottom of a pocket for example, and then I don't have one workpiece top Z, but several, depending on the XY position on the piece).

--

http://rando-sauvage.info

[zappa...@gmail.com]

Thank you, that's the type of feedback I was waiting for!

Very useful hints.

• As for the "global parameters", please don't set "Z feed rate" and "XY feed rate" as global because they are not. I always change the feed rate (even with the same tool), depending on the operation: for a coarse milling requiring the full width of the tool, the XY feed rate will be much slower than for a finishing pass that removes a few 1/10mm.
  

Yes, I also had some doubts about that, but tried to push it to the extreme point to see if anybody objects :)

But having "Z feed rate", "Z workpiece top" etc attached to every operation is also not very convenient... there are too much places where these options can be changed, you can easily miss a wrong value somewhere.

So, maybe we can make "SETUP" a operation as well, and it would set the feed rates, workpiece top, axis limits etc.

And every parameter would have a checkbox to leave previous value or to set a new value.

This way, if you're in doubt about some of these parameteres, you can check just the SETUP operations.

• What I love in DXF2GCODE is its efficiency: it is perfect for prototyping because there is no need to spend hours to configure it: just draw your piece, name each layer with the tool parameters and everything is auto-magically configured in DXF2GCODE (I like the possibility to auto-configure the tools through the layers). Just have to select milling order and generate the GCODE. Your "Auto" mode will do the same I guess?
  

Exactly. After loading a DXF file the "Auto" button should be placed somewhere in a easily reachable place so that you can instantly press it and generate a "simple case" set of operations.

And that also could be done automatically after loading a DXF (but not d2g project) file.

• I think that your "operation" organisation shouldn't modify anything for that, but please keep the "Custom GCode" functionality, it is quite useful (at least for me :-P), eg to add a pause, probing a tool, ...
  

Sure, I didn't mentioned "Custom GCode" operation just to keep the amount of text small, but I don't plan on removing any existing functionality, only add :) 

• One nice feature would be to have a "Drill" operation too (using the appropriate GCODEs).
  

Good idea.

 

[Fuyun Ling]

As we are talking about next gen. dxf2gcode, I have also have something in mind.  I am using dxf2gcode for carving of Chinese Calligraphy on wood board.  There are a lot of head movement on wood surface.  Somehow, I always feel it will be much faster if the optimization can be done better.  For my application, it will be best to minimize the amount of non-carving movements.  I don't know what is the criterion of current optimization.  However, what I observe is that even there are paths nearing each other need to be carved, the head always move to another part of the surface then come back.  I don't know if it is possible to make change to be more efficient.

--

[zappa...@gmail.com]

On Friday, May 3, 2019 at 7:36:23 AM UTC+3, Fuyun Ling wrote:

As we are talking about next gen. dxf2gcode, I have also have something in mind.  I am using dxf2gcode for carving of Chinese Calligraphy on wood board.  There are a lot of head movement on wood surface.  Somehow, I always feel it will be much faster if the optimization can be done better.  For my application, it will be best to minimize the amount of non-carving movements.  I don't know what is the criterion of current optimization.  However, what I observe is that even there are paths nearing each other need to be carved, the head always move to another part of the surface then come back.  I don't know if it is possible to make change to be more efficient.

You may want to check the "develop" branch of dxf2gcode.

I have added path optimizations that shorten the off-workpiece moves.

That's done in a second pass after the Traveling Salesman optimization (Export -> Optimize Paths)

[Fuyun Ling]

It got worse.

--

[zappa...@gmail.com]

On Saturday, May 4, 2019 at 6:29:55 AM UTC+3, Fuyun Ling wrote:

It got worse.

Can you send me some simple sample DXF that got worse? And what exactly did got worse, the path is less optimal now?

[Fuyun Ling]

I mean the estimated cutting time by Candle is longer than the standard version (20190103).

Attached is .dxf file that I used for testing.  Note that it is generated by Visio with unit of mm but always interpolated as inch.  You need to make sure the generated .ngc file is in mm.

Thanks

[zappa...@gmail.com]

Oh my... that file really pushes dxf2gcode to the edge :)

I see there's a problem with the dxf file itself: it looks like Visio already did some "optimizations" - some of the lines you use to dig the pocket glued together with the contours of the letters.

Thus dxf2gcode can't do a lot here, because the image consists of almost-random lines in all directions. You can try to click on separate lines to see how they "glued" with part of letter contours.

dxf2gcode will never try to split those.

Here's a sample of the wrong thing Visio did:

As you can see, the shape is very cumbersome here and dxf2gcode can't do anything about it. He will follow this exact (red) path because it is not able to split the paths into sections for optimization. Thus, it can't optimize, for example, the contours apart from the lines and you, for example, can't use left/right cutting compensation for letter contours.

I would do it differently: create a pattern of lines then subtract the contours of the letters from them, but without leaving the contour.

Here's approximatively what I mean:

After that, add the clean contours of the letters on the top, but without connecting to the lines:

With these shapes, first, dxf2gcode will be able to do much better move optimizations and second, you can do better milling (for example, letter contours may use a different milling depth and so on). 

Regaring dxf2gcode new generation, what you're trying to do should be possible with the "POCKET" operation I have in mind. You will not have to fill the pocket with lines manually.

On Saturday, May 4, 2019 at 9:09:27 PM UTC+3, Fuyun Ling wrote:

I mean the estimated cutting time by Candle is longer than the standard version (20190103).

Attached is .dxf file that I used for testing.  Note that it is generated by Visio with unit of mm but always interpolated as inch.  You need to make sure the generated .ngc file is in mm.

Thanks

On Sat, May 4, 2019 at 3:19 AM <zappa...@gmail.com> wrote:

On Saturday, May 4, 2019 at 6:29:55 AM UTC+3, Fuyun Ling wrote:

It got worse.

Can you send me some simple sample DXF that got worse? And what exactly did got worse, the path is less optimal now?

--
--
You received this message because you subscribed to the Google
Groups-group "dxf2gcode-dev".
To post a message, send mail to dxf2gc...@googlegroups.com

To unsubscribe, send mail to dxf2gc...@googlegroups.com

See http://groups.google.de/group/dxf2gcode-dev?hl=en for more options
and the dxf2gcode project page at http://code.google.com/p/dxf2gcode/
---
You received this message because you are subscribed to the Google Groups "dxf2gcode-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dxf2gc...@googlegroups.com.

[Fuyun Ling]

Hi,

Thank you for looking into this.  I knew it was going to be difficult.  I appreciate your help anyway.

As for the first example, I would not worry about that, even it makes long distance traveling, it makes

To unsubscribe, send mail to dxf2gcode-de...@googlegroups.com

See http://groups.google.de/group/dxf2gcode-dev?hl=en for more options
and the dxf2gcode project page at http://code.google.com/p/dxf2gcode/
---
You received this message because you are subscribed to the Google Groups "dxf2gcode-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dxf2gcode-de...@googlegroups.com.

[Christian Kohlöffel]

Just one additional comment, which i want to add, regarding the following sentence

 

Regarding dxf2gcode new generation, what you're trying to do should be possible with the "POCKET" operation I have in mind. You will not have to fill the pocket with lines manually.

 

Since a long time I had the same additional operation in mind and there are already some parts of the required operations integrated in dxf2gcode. I was not sure weather you are aware about that … (https://sourceforge.net/p/dxf2gcode/sourcecode/ci/develop/tree/source/dxf2gcode/core/shapeoffset.py)

 

 

Regards

Christian

[zappa...@gmail.com]

Of course, I've seen the feature/PocketMill branch and was going to look at it when I will proceed to implementing the POCKET operation.

But there's so much work to do yet, it's a far perspective :)