Feature Requests

  • Anonymous - 2011-10-10

    I'm just getting started with DIY CNC, but there'a  couple features I'd love to see as part of the gcode export:
      - commenting style:  thus far I've seen different firmwares supporting (comment), "comment", and ;comment.  It'd be nice to be able to specify start and stop delimiters to comments
      - command termination options:  some particularly finicky firmware I've come across requires commands to be terminated with " ;" (a space and semicolon).
      - G movement modal command group:  I've noticed that pycam emits modal G0/G1 commands, e.g.:
    G1 X1
    Given the repeat of the X parameter, I assume this is "G1 X1; G1 Y2; G2 Z3; G1 X2" and not  "G1 X1 Y2 Z3; G1 X2".  Other firmware expects there to be an explicit command code per line, instead of relying on the modality of G0 and G1.

    These wouldn't seem too difficult to add … although I'm also in the process of modifying various bits of firmware to be less picky.

  • Anonymous - 2011-10-19

    After using pycam for a few mills with a few materials now, there's some other features I'd love to see:
      - Make safety distance, and other setting in prefs, project-based!  This doesn't appear to be stored per-configuration, which I'm storing per-project, which means I have to adjust it for every milling.
      - Separate z and x-y feed rates. 
      - Materials pane:  the feed rate of a given mill changes for different materials, as well as maximum step.  I'd vote for either adding a list of feed rates (and max step) per tool per material, else a materials pane that allows you to specify scaling factors for feed rates and max steps.
      - UI issue:  <return> appears to save changes values, which I occasionally don't hit when changing values.  Perhaps just a "save" button at the bottom of various panes?
      - (this is an alternate to the previous post) allow post-processor scripts.  Right now, I have to run everything through a perl script to fix up the gcode for my aruduino.  Enabling arbitrary post-processors scripts would save me a step, and allow people to generate a library of postprocessors for different machines/firmware.

  • Lars

    Lars - 2011-11-17


    thanks for all these suggestions and ideas!

    You are right: post-processors will be probably very helpful for a lot of people. All your suggestions about GCode variations (comment style, modality, …) will fit well into post-processor definitions, I guess.

    The separate x/y/z feedrate setting is already on my TODO list.

    Regarding the "project-based" settings: all of the gcode settings will move from the program's preferences to the project settings. Thus this problem is about to be solved already.

    Materials: I like the idea, as it will make it easier for people to work with PyCAM in the long term. But since these material parameters are surely machine-dependent values, I guess that everyone needs to create and populate these tables on their own. Anyway: this is an interesting idea - I will think about it …

    UI problem with "save": I did not understand your situation here. Does it mean, that values in control fields return to their previous values, if you omit to press <return>? This sounds weird to me.

    thanks for your efforts!



Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks