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.:
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.
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.
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!
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.