Entry/Exit moves should start in the middle of an edge

[GoogleCodeExporter]

For G41/G42 compensation to work correctly, the entry and exit moves should 
start in the middle of an edge and not at a corner.
The machines compensation code (EMC2.2.5) can only know that it needs to stop 
before the end of the programmed line if there's another path "in the way".

A quick fix would be convert the first edge into two edges and use that middle 
coordinate as start and end.

Original issue reported on code.google.com by goo...@e-trolley.de on 26 Oct 2010 at 11:46

[GoogleCodeExporter]

Hello,

The start of the entity is not at a corner. It adds a 90° arc with a user 
definable radius at the being.

The following code is used:

        #Fräsradiuskorrektur Links        
        elif self.cut_cor==41:
            #Mittelpunkts für Einlaufradius
            Oein=start.get_arc_point(start_ang+90,start_rad+tool_rad)
            #Startpunkts für Einlaufradius
            Pa_ein=Oein.get_arc_point(start_ang+180,start_rad+tool_rad)
            #Startwerts für Einlaufgerade
            Pg_ein=Pa_ein.get_arc_point(start_ang+90,start_ver)

            #Eintauchpunkt errechnete Korrektur
            start_ein=Pg_ein.get_arc_point(start_ang,tool_rad)
            self.st_move.append(start_ein)

            #Einlaufgerade mit Korrektur
            start_line=LineGeo(Pg_ein,Pa_ein)
            self.st_move.append(start_line)

            #Einlaufradius mit Korrektur
            start_rad=ArcGeo(Pa=Pa_ein,Pe=start,O=Oein,r=start_rad+tool_rad,dir=1)
            self.st_move.append(start_rad)

        #Fräsradiuskorrektur Rechts        
        elif self.cut_cor==42:

            #Mittelpunkt für Einlaufradius
            Oein=start.get_arc_point(start_ang-90,start_rad+tool_rad)
            #Startpunkt für Einlaufradius
            Pa_ein=Oein.get_arc_point(start_ang+180,start_rad+tool_rad)
            #IJ=Oein-Pa_ein
            #Startwerts für Einlaufgerade
            Pg_ein=Pa_ein.get_arc_point(start_ang-90,start_ver)

            #Eintauchpunkts errechnete Korrektur
            start_ein=Pg_ein.get_arc_point(start_ang,tool_rad)
            self.st_move.append(start_ein)

            #Einlaufgerade mit Korrektur
            start_line=LineGeo(Pg_ein,Pa_ein)
            self.st_move.append(start_line)

            #Einlaufradius mit Korrektur
            start_rad=ArcGeo(Pa=Pa_ein,Pe=start,O=Oein,r=start_rad+tool_rad,dir=0)
            self.st_move.append(start_rad) 

However, but i dont understand the problem with this startmove and why you 
think it should be changed? 

Regards
Chirstian 

Original comment by christian.kohloeffel on 27 Oct 2010 at 9:02

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Generally it is a good idea to add several start moves etc which can be 
selected by user. But i dont have the time to do it since i have some other 
very important project running at the same time (building a house etc.). If you 
want i can add you to the developer group of this project and your able to 
commit changes to it. Maybe you want to contribute to the next version ....

Regards
Christian 

Original comment by christian.kohloeffel on 27 Oct 2010 at 9:14

[GoogleCodeExporter]

I created a dxf with a square, consisting of 4 lines, that should be cutted 
from the inside.
In the attached image you can see, that the entry move starts at the beginning 
of a line. Furthermove you can see, that the first and last moves would cut the 
workpiece, as EMC can't compensate correctly.

The EMC guys told me, that for the compensation to work I need 5 lines instead 
of 4 for a square. (Not counting the entry & exit moves). As a quick fix they 
suggested, that dxf2gcode doesn't start at the beginning of a line, but split 
the first line and start and stop in it's middle.

Original comment by goo...@e-trolley.de on 27 Oct 2010 at 9:51

Attachments:

• entry_exit.png
• entry_exit.dxf
• entry_exit.ngc

[GoogleCodeExporter]

Unfortunately I'm not a skilled Python coder (more Java, C++, ...), so adding 
me to the development group wouldn't help much :-/
But if you have Jabber/ICQ/Skype, that would be a great help :-)

Original comment by goo...@e-trolley.de on 27 Oct 2010 at 9:57

[GoogleCodeExporter]

What i understood is that the EMC guys did change the compenstation in the new 
version. I will think about this issue but i dont see a quick fix now since 
it's very difficult to split the first line. Cause this dont work for all 
shapes. Maybe you find a other solution maybe just add the same thing on the 
end, like the start?

Original comment by christian.kohloeffel on 27 Oct 2010 at 5:17

[GoogleCodeExporter]

my bad workaround :-)

Original comment by odippe...@googlemail.com on 6 Jan 2013 at 6:53

Attachments:

• dxf2gcode.py
• dxf2gcode3.png

[GoogleCodeExporter]

Can you please attach the diff too. So it may be possible to include the 
changes into the current code i got. I cant identify the changes.

Original comment by christian.kohloeffel on 6 Jan 2013 at 7:24

[GoogleCodeExporter]

Alright! Great fix odippel75. Will implement this one as an option. I'm still 
thinking about were I should define this option, since I don't want this as a 
standard.

Original comment by jp1...@gmail.com on 16 Aug 2013 at 7:33

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It's partially fixed, not yet working for arcs and rects though

Original comment by jp1...@gmail.com on 17 Aug 2013 at 3:04

• Changed state: Started

[GoogleCodeExporter]

Fixed. Every edge can now be split such that you can place the starting point 
in the middle (option=>split edges). Note: every edge will be split - in other 
words it creates 8 lines for a square. When time permits, this will be fixed.

Original comment by jp1...@gmail.com on 20 Aug 2013 at 5:29

• Changed state: Fixed