G-Code Optimization?

[TilTisback]

Hi, i know this is not a real issue report here but i don't know where to post it instead. So here is the thing: is there a way to implement a g-code optimization into bCNC? There are some of command line based optimizators for the traveling salesman problem out there but it would be very nice to have such a tool inside the program itself. Like load a gcode, hit optimize and see the result directly in the main viewport. I would really appreciate it!

[HomineLudens]

@TilTisback something already there, maybe a bit hide:

From code description: Re-arrange using genetic algorithms a set of blocks to minimize rapid movements.

Is this what you was looking for?

[TilTisback]

Ok i haven't seen that but it seems like its not working? Or maybe i am doing something wrong? I load my drill file select everything and hit optimize.-->nothing happens Then i saw it has only one block so i loaded an isolation file with about 209 blocks, select it ,hit optimize and still nothing happening.

The optimization should work for single blocks too right? Here is what my drillfile looks like. It takes more time to travel than actually to drill.

edit: For those who are wondering: I am milling a circuit board.

[HomineLudens]

Select all blocks (es: Ctrl+A) and then use the optimize. It should work, I've made this test:

Before:

After:

[vlachoudis]

@Effer is correct you have to select only the blocks of gcode you want to optimize. Maybe I should put as an option that nothing is selected to select everything before. The algorithm, keeps the first block as the starting position and tries to optimize the selected blocks that follow.

Depending what you want to do you can first re-order the block you want to start with and then select what you want to optimize

[HomineLudens]

@vlachoudis I like the selectAll() if nothing is selected.

Maybe it could be useful to add also a way to invert selection (Ctrl+I ?) that I feel missing from the editor. Also add a couple of button for selection will make the commands more easy to find.

[vlachoudis]

@Effer I've implemented the SelectAll. However it is a bit dangerous in case there is control blocks of code. e.g. starting stopping the spindle or tool change. I am thinking that is more safe to issue a message if nothing is selected instead of re-ordering the code

Ctrl-I and select function are certainly a must of the editor. Maybe a new button group should be created for that.

[HomineLudens]

I didn't tough about that kind of issues. Go for the safe way.

A new group will fit well

[ThierryM]

Hi, I think this implementation has introduced a bug. I can't launch bCNC now (I try to launch in french) : the program is launched but closed immediatly.

thierry@thierry-M70Vn:/HD3_docs/CNC/Logiciels/github/bCNC$ ./bCNC
Traceback (most recent call last):
  File "./bCNC.py", line 2158, in <module>
    application = Application(tk)
  File "./bCNC.py", line 186, in __init__
    page = cls(self.ribbon, self)
  File "/HD3_docs/CNC/Logiciels/github/bCNC/CNCRibbon.py", line 106, in __init__
    self.register()
  File "/HD3_docs/CNC/Logiciels/github/bCNC/EditorPage.py", line 535, in register
    (EditorFrame,))
  File "/HD3_docs/CNC/Logiciels/github/bCNC/CNCRibbon.py", line 120, in _register
    w = g(self.master._ribbonFrame, self.app)
  File "/HD3_docs/CNC/Logiciels/github/bCNC/EditorPage.py", line 78, in __init__
    image=Utils.icons["select_all"],
KeyError: 'select_all'

Regards

[HomineLudens]

It should be fixed with last commit @ThierryM

[ThierryM]

Thanks (I saw the last commit after I've posted...). Regards

[aduckinpants]

Is there a way to optimize within a single block? Flatcam is outputting drill hole movements in a format that bCnc is seeing as one giant block and I don't know how to split it up.

[vlachoudis]

Normally bCNC splits the gcode between the g0 vertical motions. Can you send me one example of the gcode to see why it doesn't split it.

[aduckinpants]

@vlachoudis Try this one. It's pretty short but should demonstrate what I'm seeing: http://pastebin.ca/3334828

[vlachoudis]

Ok. I see that flatcam is retracting the spindle using G1 instead of G0. I am afraid that if I change the algorithm to accept also the G1 vertical motion then it will break normal 3D cuts into artificial blocks of code. I would say in your case the easiest is to replace the "G01 Z1.0000" to "G00 Z1.0000" inside any text editor and then everything works. Or from the linux command line sed -e "s/^G01 Z1.0000/G00 Z1.0000/" flatcam.ngc > newfile.ngc

[CarlosGS]

I had the same problem with gcode generated by FlatCAM in order to drill PCBs: the gcode could not be optimized since it was interpreted as a single block of multiple drills.

Currently bCNC does as follows: https://github.com/vlachoudis/bCNC/blob/master/CNC.py#L1944

        # rapid move up = end of block
        if self._blocksExist:
            self.blocks[-1].append(line)
        elif self.cnc.gcode == 0 and self.cnc.dz > 0.0:
            self.blocks[-1].append(line)
            self.blocks.append(Block())
        elif self.cnc.gcode == 0 and len(self.blocks)==1:
            self.blocks.append(Block())
            self.blocks[-1].append(line)
        else:
            self.blocks[-1].append(line)

The problem is that when raising the drill bit from a PCB the Z motion does not have to be rapid. I propose to also split into blocks whenever Z is raised above Z=0 (self.cnc.zval > 0.0)

        # tool raised to Z>0 = end of block
        if self._blocksExist:
            self.blocks[-1].append(line)
        elif (self.cnc.gcode == 0 or self.cnc.zval > 0.0) and self.cnc.dz > 0.0:
            self.blocks[-1].append(line)
            self.blocks.append(Block())
        elif self.cnc.gcode == 0 and len(self.blocks)==1:
            self.blocks.append(Block())
            self.blocks[-1].append(line)
        else:
            self.blocks[-1].append(line)

I've just tested it and seems to work fine. Thanks again for the hard work Vasilis!! :-)

[CarlosGS]

I just updated the comment incorporating the check of self.cnc.zval to guarantee dZ>0 and Z>0. Sorry for the multiple edits! Also, the code now keeps the G0 check in order to maintain compatibility with the previous system.

[CarlosGS]

Sorry @vlachoudis, I didn't see your message until now.

Changing the algorithm to accept also the G1 vertical motion will break normal 3D cuts into artificial blocks of code

I agree, that's why the latter code does not split anything below Z=0. This would only cause excessive splitting if some [evil] person loaded a g-code file with 3D motions outside the material being milled (I assume that if somebody actually loads this sort of g-code -for a 3D printer?- she won't really be in need for the optimizer anyways...)

Personally, this feature would save me some time long-term (this includes giving support to other users that also need to optimize FlatCam's drills :P). But feel free to discard it if you believe it can actually be problematic

[vlachoudis]

I don't agree on the z=0 condition. Nothing prevents someone to start the stock material with z>0. Maybe I can put the check on dz>0 and dx=dy=0, and final z=safe z. so there is a clear vertical motion, that will not cut anything. Doing so if the user does any other operation on the block, bCNC will assume a rapid motion g0 instead of a g1.

[CarlosGS]

That makes sense, I was wrongly assuming that every gcode for milling should take Z=0 as the surface of the material. Your solutions sounds like a robust approach, the only detail is that the user would need to match-up safeZ in both FlatCAM & bCNC, but that is a reasonable requirement.

[CarlosGS]

It seems they'll fix this in FlatCAM: https://bitbucket.org/jpcgt/flatcam/issues/141/retract-rates-for-gcode-files-from-exelon Will keep you posted with any updates :)