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
Y2
Z3
X2
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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!
cheers,
Lars
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
Y2
Z3
X2
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.
Hi,
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!
cheers,
Lars