#59 Enter and exit point is outside of compensated shape

[Anonymous]

Originally created by: inner.bushman
Originally owned by: christian.kohloeffel

What steps will reproduce the problem?
1.load .dxf
2.add compensation to the right to all shapes, (adjust other values as needed)
3.optimize and export as usual

What is the expected output? What do you see instead?
Expected optimized shapes, got optimized shapes with entry and exit points outside the shape causing the tool to run into full thickness of material
(with 3mm acrylic it's not an issue but imagine 20mm steel).

What version of the product are you using? On what operating system?
Version:
PyQt4 Beta: $Rev:: 549 $
Last change: $Date:: 2015-02-04 13:44:52#$
Changed by: $Author:: Christian Kohlöffel $

Ubuntu 14.04

Please provide any additional information below.
There are 3 shapes in the dxf file, normal circle, circle modified with a notch inside and normal polyline rectangle. The code for the circle is generated ok, but for both, the circle with a notch and polyline rectangle the entry point and exit point are both outside the compensated shape. while the entry point is easy to work around cause i can let the machine run one pass in mid air the last horizontal move goes outside the shape causing it to ram the tool into full thickness of the material.

Please let me know if you need any additional information.

Thanks in advance,
Wojtek

[Anonymous]

Originally posted by: christian.kohloeffel

Hi Wojtek,

It's not a but it's a feature" :-)
Well dxf2gcode has implemented two ways of lead in moves. The one you might expect can be changed within the postprocessor.

Try to Change the following:

    cc_outside_the_piece = False

Hope this is the expected solution.

Labels: OpSys-All
Owner: christian.kohloeffel
Status: Done

[Anonymous]

Originally posted by: inner.bushman

Hi, Christian,

There's so many features. Is there any sort of documentation for all of them? :P

But sadly that didn't fix it :( The setting changes where the compensation entry move is on Z axis while the problem is with (not "entry" move) start and finish of the shape. Please see attached screenshot where i tried to visualize it better.

Cyan: original behavior,
Green: after your suggested change in config,
Red: actual problematic (parts of) moves.

Please let me know is the image makes sense or should i clarify anything else.

Thanks in advance,
Wojtek

[chrisko]

Hi Wojtek,

we just moved to SourceForge since Google Code is shutting down. I hope you receive this message anyhow (please give answer if so)

I see the problem in the picture, however i can not explain why dxf2gcode should produce such an output. I think this is just a display Topic of Axis (LinuxCNC) which shows the red move on the end of the shape when cutter compensation is switched off (G40). The red move on the begin is the lead in move which is required by EMC otherwise cutter compensation won't work.

Can you try to check that on the real Machine?

regards
Christian

[InnerBushman]

Hi Christian,
I have an account on sourceforge so it's ok the project was moved.
I did tested the code on real machine... you might say i "tested it" by running it and didn't notice till it was to late. it's hard to notice 3mm move on 400mm part.
The part is ruined but it's ok, it was used as prototype only and the wrong cuts could be masked out with button's flanges.

Tho now i have a new project where i need to cut something really small with 0.8m cutter and the compensated shape is really small, sometimes 0.1mm, so a move of 0.4mm at the ends in any direction would create huge difference.

I've looked into g-code and it looks ok. the compensation is turned on (G41/42) before enty arc/move and going down on Z and turned off (G40) after the last Z move.
The problem might be that linuxCNC treats the last move as straight line and not as part of a closed shape and therefore goes where ordered, all the way to the end of the uncompensated line.

It sort of makes sense, when you order the machine to go from 0 to 100 on X but add compensation on Y it still needs to go all the way to 100 on X, unless you make a turn on Y in the direction of compensation, then it doesn't make it to 100 but stops before crossing the compensated shape.
I'm not sure who's to blame now cause both sides seem to have their job done correctly :P

[chrisko]

I assume that means we can close this topic, since dxf2gcode cannot fix it ...
sorry and regards
Christian

[InnerBushman]

Actually, i think DXF2GCODE can fix this.
I talked to some people on #linuxCNC IRC channel and it seems there might be some misconception in how the code handles compensation.
For start, i was told that the entry move should be perpendicular to the first move for it to start "compensated" in both axis. As you can see on the attached drawing that currently the code adds an arc, which end is in-line with (parallel to) first move. This causes the shape to be interpreted together with the arc, causing it to stretch out. Also the finish could be handled the same, adding a perpendicular move after going up on Z could make sure the shape is interpreted as a "corner" rather than "straight line".

Please let me know what do you think about it and if there is a chance to fix this in the code.

Thanks in advance,
Wojtek

PS: i was referenced to this link: http://www.linuxcnc.org/docs/html/gcode/tool_compensation.html#_overview
it agrees with what they said about how to start and end a compensated move.

[chrisko]

Hi Wojtek,

for sure DXF2GCODE can handle that. I just created a new branch to work on this topic. Since i didn't really understood what you require me to change, i suggest you try to implement that directly into the code. I highlighted the areas where you may need to change something. Should be very straight forward to do (Not to much python etc. needed to understand what to do).

Feel free to ask for any explanation / support if required.

https://sourceforge.net/p/dxf2gcode/sourcecode/ci/Tickets/59_EnterExitMoves/~/tree/source/

https://sourceforge.net/p/dxf2gcode/sourcecode/ci/Tickets/59_EnterExitMoves/~/

Head out for the latest changes, so you will see the areas to change. If required or preferred i can add you to the developers group of the project to directly contribute.

regards
Christian

[Robert Lichtenberger]

Ran into basically the same problem and opened another bug (https://sourceforge.net/p/dxf2gcode/tickets/61/) for it, since I didn't know this entry...

I just finished a patch for "my problem". I am not 100% sure if it will also fix Wojteks problem, but it could well be the case.

BTW, Christian: what is the reason, that entry-moves are implemented as arcs?

[InnerBushman]

Hi Christian, Robert.

@Cristian, yes please, add me to developers group. Seeing there are other people that have the same issue we might be able to come up with the solution together.
@Robert, i've already tried what you suggested in your ticket, but that doesn't work for me. In some cases this seem to fix the problem. In others it's still there.
Please try shapes other than rectangle with relatively large tool diameter to emphasize the issue visually.

I use this file (in attachment) with 5 primitives to test my results, they vary from shape to shape and so far the only thing i was able to think of, that would completely fix the issue, is to start in the middle of any geo (be it arc or straight).
We can skip this for full circles but still need to solve it for arc to arc connecting at an entry angle other than exit angle of previous/last geo.

Thanks,
Wojtek

PS: Christian, maybe we can merge those two issues? (59&61)

[Robert Lichtenberger]

Did you apply the patch from issue 61?

I think it is not necessary to start in the middle of a geo, you only need to have an entry exit move that is perpendicular to the angle of the shape and coming from the correct side (G41 ... from the left, G42 ... from the right).

[InnerBushman]

Yes i have. I also thought it's just to have an entry move that is perpendicular. That's why i've tried what you did in your patch before.
Your exit move strategy it also something i have thought about but gets troublesome when the first move is LOOOOOOONG. Imagine milling at 300mm/min profile that is a huge triangle with all sides 300mm long... just exiting it would take 1/3 of the time used to mill one pass. That's unacceptable, that's why i didn't post my tries.

EDIT: sorry i didn't used reply button :(

[InnerBushman]

Gentlemen, I suggest a solution:
we could force the start point to be on the middle of edge.

I tested it with Split Edges feature (fixed a teeny tiny bug in it btw) and manually moving the start point to the center of the split line. That eliminated the problem even when using the already existing entry moves and no special exit move. We should also do the same with arcs. Split them and move the start point to the split points. Prohibiting using corners could help too tho i'm not sure it won't collide with compensation on the outside of the shapes.

Any ideas how to implement that in the code? Where to look for good spots to do that?

Cheers,
Wojtek

PS: maybe "Split Edges" should be invoked by default and not as an option?

[Robert Lichtenberger]

I just tried issue03.dxf with my patch applied, all shapes put to G42. The resulting .ngc file cannot be read by LinuxCNC however, there is a rogue G41 line somewhere. I'll have to check that if/when I have time.

[chrisko]

Hi, just applied both patches provided by Robert and Wojtec. Continue on the branch 59 please. Also added the options in the option menu to used different lead in / lead out moves.

[InnerBushman]

Chistian, the patch made by Robert doesn't really help to solve the problem. As i mentioned before it only mask it for certain cases. In fact the original lead in moves are correct, only the place where we make them isn't.

Please see "Figure 5. Inside Profile" in linuxCNC documentation:
http://linuxcnc.org/docs/html/gcode/tool_compensation.html#_examples

It is clearly shown that lead in and lead out (if needed) for inside profile should be done on the length of the profile's edge and not in the corner. Putting it in corners causes problems. Putting them on the length of the edge works out of the box!

Now if only D2G could do that by default? (put the start in the middle of split edge)

[Robert Lichtenberger]

I am not 100% sure but I think the fact that lead-in is shown on the length of the profile's edge is for illustration purpose only and not strictly required.

[Robert Lichtenberger]

On branch Tickets/59_EnterExitMoves:
Configuration:
lead_in_move = radius2
lead_out_move = add_first
Loaded issue03.dxf
Selected all shapes and made them G42.

In ss1.png we have the dxf2gcode screenshot: All the lead-in moves are now perpendicular and coming from the right hand side.

[Robert Lichtenberger]

Next attachment: The generated G-Code.

Note line 136: G41

This seems like an old bug to me: When milling non-closed shapes in multiple passes, the direction is reversed at the end and also the G41/G42. But this simply does not work, LinuxCNC does not allow it.

To that end, I just commented out the line to be able to load the file.

[InnerBushman]

Please change post processor config to to have this lines:

cutter_comp_left = G40%nlG41%nl
cutter_comp_right = G40%nlG42%nl

That solves the problem of open shapes.
It's a workaround for this issue that Cristian helped me to solve before. See: https://sourceforge.net/p/dxf2gcode/tickets/57/

Not sure why it's not in the main trunk yet.

[Robert Lichtenberger]

And finally a screenshot from LinuxCNC itself.

Looks like a perfect cut to me, but I will probably try it out.

As for the exit move: Yes, it is just a workaround to take the first geometry and yes, it may take a long while (e.g. half the circle).

Since christian already has added configuration options, I may try to add 'line' as possible values for lead_in_move and lead_in_move and lead_out_move. These would then be simple perpendicular lines to the left/right of the shape whose length is determined by the tool diameter.

[Robert Lichtenberger]

Just pushed a "lines" option for perpendicular lead-in/lead-out moves.

This should work great for polygons, but I suspect it will suffer from "the bump" (http://linuxcnc.org/docs/html/gcode/images/comp02.png), described at http://linuxcnc.org/docs/html/gcode/tool_compensation.html

I think the only way to get clean inner contours (for closed shapes) is to follow the first geometry.

[InnerBushman]

Robert, i loaded your .ngc file and i can still see the issue. it's only smaller and the exit moves are ridiculous.
Also, now i can't export a working code when using "line" entry moves. I get errors every time, corner or split edge.

Robert, please try this:
- use split edges and radius entry moves,
- move the start point to any of the split edges centers
- export and visaually compare

Please notice that no matter what the shape is (except arcs that are not full circles. that needs to be addressed) the entry and exit point is spot on on the profile and both PERFECTLY the same... not just close enough.

[chrisko]

Any news on this? How to proceed?

[InnerBushman]

Hi Christian, there is no consensus whether to go with corner entry/exit moves or in the middle of split geo.

From my initial tests it seems a good idea to me to place the entry/exit move in the center on split edge. This gave me the best results with straight lines and full circles. Since there's no edge splitting for arcs i could not test it with such.
Also, when trying to come up with working algorithm for corner entry/exit moves i found multiple issues that would have to be addressed in the algorithm. This makes it complicated. That's why i personally am in favor of mid-geo, split-edge entry/exit moves.

I'll do some more extensive testing and post results later.