This is a great free CAM software.
I tested if the output gcode could be fed to a Reprap-based cartesian robot . Unfortunately the firmware accepts only basic gcode format instead of PYCAM's ngc format. Too bad because the reprap-based cartesian robots are getting popular among hobbyists and have the potential to become the next control standard for home CNC machining.
I understand that you are working on a new version of the postprocessor. I suggest that you add Reprap compatible gcode output by the same occasion.
Thanks for a great software,
Cybair
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All Mcodes and Tcodes are machine-specific and related to extrusion so you can ignore them; that leaves the following set of gcodes:
G0 - rapid positioning, input X Y Z, syntax: G0 X1.25 Y0.025 Z0.0
G1 - linear interpolation, input X Y Z F(feedrate in inch/min or mm/min depending on unit sys), syntax: G1 X1.5 Y0.5 Z0.0 F10.0
G4 - dwell, input P(dwell time in ms), syntax: G4 P115.0
G20 - inch unit system
G21 - millimeter unit system
G28 - move to origin
G90 - absolute coordinate system
G91 - incremental coordinate system
G92 - set current position, input X Y Z, syntax: G92 X0 Y1 (set current position as X=0.0, Y=1.0, and Z remains unchanged)
- One of the many reprap gcode interpreters can read the G2 and G3 arc commands (syntax is G3 X20.0 Y0.0 I5.0 J0.0). However, producing gcode with arc commands would greatly reduce the compatibility of the gcode with the largest base of reprap machines out there. Is it possible to stay away from the arcs commands and use instead the G1 linear interpolation command to produce a succession of straight lines?
- It is better not to code for spindle control. This is easy to control manually and would be machine-specific anyway. It could be the source of problems and incompatibilities. I'm a firm believer in the KIS principle (Keep It Simple).
- One limitation that I noticed on my Reprap Darwin is that the Z moves have to be independent from the X and Y moves. Otherwise, the motor drivers cannot cope and do weird stuff. The Z moves have to be written on a separate line with their own feedrates.
- The file extension should be .gcode instead of .ngc
- Here is an example of a gcode file written by the Reprap Slicer. This is the top of the file so that you can reproduce the start protocol and independent Z moves. Here again, ignore the Tcodes and Mcodes which are related to the plastic extrusion head.
One of the many reprap gcode interpreters can read the G2 and G3 arc commands (syntax is G3 X20.0 Y0.0 I5.0 J0.0). However, producing gcode with arc commands would greatly reduce the compatibility of the gcode with the largest base of reprap machines out there. Is it possible to stay away from the arcs commands and use instead the G1 linear interpolation command to produce a succession of straight lines?
This is no problem - in fact: right now PyCAM generates only straight moves.
It is better not to code for spindle control. This is easy to control manually and would be machine-specific anyway. It could be the source of problems and incompatibilities. I'm a firm believer in the KIS principle (Keep It Simple).
hehe - you forget the final "S" in KISS: "Stupid" :)
But I agree - the spindle control will be optional.
One limitation that I noticed on my Reprap Darwin is that the Z moves have to be independent from the X and Y moves. Otherwise, the motor drivers cannot cope and do weird stuff. The Z moves have to be written on a separate line with their own feedrates.
Hm - this sounds like a problem. For 3D models it is a very common thing to move to the side and up and the same time - any slope will trigger this move.
I hope that this limitation only applies to repraps (not milling machines), since it would simply turn every ascending move into hundreds of small steps.
In other words: I don't think, this will be implemented.
The file extension should be .gcode instead of .ngc
OK - this will be part of the machine-specific postprocessor.
Here is an example of a gcode file written by the Reprap Slicer. This is the top of the file so that you can reproduce the start protocol and independent Z moves. Here again, ignore the Tcodes and Mcodes which are related to the plastic extrusion head.
Thanks for the example!
I will take a look at this listing again, as soon as the basic structure of the postprocessors is fixed.
cheers,
Lars
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I spent the last few days testing GCODE commands on the RepRap interpreter and there are a few more things that I would like to add concerning the format of RepRap-compatible GCODE.
1 - All comments should be excluded from the file. They produce a major error.
2 - The G0 command causes problems with the Z axis feedrate. It works well when all the G0 commands are replaced by G1 commands.
3 - I have found that this minimalist startup protocol works well. The feedrate is set by PYCAM.
G21
G90
G92 X0 Y0 Z0
F70
4 - Each line that contains a move should begin by G1. It is not necessary to write the full form such as G1 X5 Y20 Z12 F70 .The short form such as G1 Y23 or G1 X34 Y62 works as well as the long form.
5 - Contrary to what I said before, it seems that there is no need for an independent Z move. The problem is said to be related to wrong feedrate set by other postprocessors. PYCAM uses the same feedrate for all 3 axis and that works fine.
Thanks again for taking a shot at Reprap GCODE. Now that parallel ports are being eliminated from computers, Arduino-based bot control with USB will become the standard for hobby CNC's, routers and fabbers. By being compatible with that bunch, PYCAM might well become the standard hobby 3D CAM software as well… Who knows? ;-)
Cybair
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
2) this sounds like a firmware bug (rapid feedrate too high by default?)
3) thanks for testing!
4) G0 and G1 are specified as modal commands - thus it is not necessary to prefix these to every command line. Thus this would be a bug, as well.
5) good to know!
Regarding (2) and (4): these changes would be easy to implement, but I really would not want to do this.
It should not take more than five minutes to fix these firmware bugs, thus I would not want to spoil the sphere of GCode implementations by supporting obviously broken parsers.
Please just send these firmware developers a mail - they will fix this issue instantly, I guess.
If everything else fails, it will still be fairly easy to adapt your own PyCAM postprocessor to the above limitations. But walking down that road would not be a good long-term choice and it is absolutely not necessary (AFAIK).
cheers,
Lars
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
that would be a great option for me as well. I downloaded Pycam yesterday and was so pleased with it's user interface and performance that I don't want to switch anymore. Unfortunately I need simple G-code as well , with always X, Y and Z per line. The reprap format should be an ok format as it is easy to strip the F's and startup codes.
We us it to mill with an old Fanuc Robot.
For now I just rebuild the G-code in Excel, but when this addition should appear in the future it would be real great!
thanks for all your efforts, and the great result,
Bastiaan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
my question is: is it possible to add this scripts inside pycam? the only way I've found to use them is by using terminal, but it's not user-friendly at all.
thanks a lot for your work,
wasproject
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks for the link to the script!
Integrating the script directly does not suit to the concept of PyCAM - the (new) output formatter selection (emc2, marlin, …) will be the way to go. Thus I will probably take this script as a reference for the marlin-compatible gcode formatter.
cheers,
Lars
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the tip. I downloaded the file and I'm going to test the
gcode compatibility with Contraptor's firmware (Chris Meighan's
"reprap new firmware") and GRemote sender interface. But I'm not in a
rush to do that because I lost faith in Reprap software functionality
(lack of standards).
This is a great free CAM software.
I tested if the output gcode could be fed to a Reprap-based cartesian robot . Unfortunately the firmware accepts only basic gcode format instead of PYCAM's ngc format. Too bad because the reprap-based cartesian robots are getting popular among hobbyists and have the potential to become the next control standard for home CNC machining.
I understand that you are working on a new version of the postprocessor. I suggest that you add Reprap compatible gcode output by the same occasion.
Thanks for a great software,
Cybair
Hi Cybair,
thanks for your suggestion - that sounds like a good idea.
Could you point me to some kind of gcode reference for the cartesian bot? Or could you list its exceptions/limitations?
cheers,
Lars
Hi Lars,
I am so glad you are interested in this. I am not knowledgeable in gcode but here is what I know.
The main gcode syntax reference for reprap bots is located here:
http://objects.reprap.org/wiki/Mendel_User_Manual:_RepRapGCodes
All Mcodes and Tcodes are machine-specific and related to extrusion so you can ignore them; that leaves the following set of gcodes:
G0 - rapid positioning, input X Y Z, syntax: G0 X1.25 Y0.025 Z0.0
G1 - linear interpolation, input X Y Z F(feedrate in inch/min or mm/min depending on unit sys), syntax: G1 X1.5 Y0.5 Z0.0 F10.0
G4 - dwell, input P(dwell time in ms), syntax: G4 P115.0
G20 - inch unit system
G21 - millimeter unit system
G28 - move to origin
G90 - absolute coordinate system
G91 - incremental coordinate system
G92 - set current position, input X Y Z, syntax: G92 X0 Y1 (set current position as X=0.0, Y=1.0, and Z remains unchanged)
- One of the many reprap gcode interpreters can read the G2 and G3 arc commands (syntax is G3 X20.0 Y0.0 I5.0 J0.0). However, producing gcode with arc commands would greatly reduce the compatibility of the gcode with the largest base of reprap machines out there. Is it possible to stay away from the arcs commands and use instead the G1 linear interpolation command to produce a succession of straight lines?
- It is better not to code for spindle control. This is easy to control manually and would be machine-specific anyway. It could be the source of problems and incompatibilities. I'm a firm believer in the KIS principle (Keep It Simple).
- One limitation that I noticed on my Reprap Darwin is that the Z moves have to be independent from the X and Y moves. Otherwise, the motor drivers cannot cope and do weird stuff. The Z moves have to be written on a separate line with their own feedrates.
- The file extension should be .gcode instead of .ngc
- Here is an example of a gcode file written by the Reprap Slicer. This is the top of the file so that you can reproduce the start protocol and independent Z moves. Here again, ignore the Tcodes and Mcodes which are related to the plastic extrusion head.
; GCode generated by RepRap Java Host Software
; Created: 2011-05-25:02-23-11
G21 ;metric is good!
G90 ;absolute positioning
G1 X-999 Y-999 F1600.0 ;xy home
G1 Z-999 F50.0 ;z home
G92 X0 Y0 Z0; set current position as home
M104 S100.0 ;set temperature
;#!LAYER: 1/15
M107 ;cooler off
G1 Z0.5 F50.0 ;lift down <--- See! the independent Z move!
G1 Z0.5 F50.0 ;z down
G1 X90.1 Y88.9 F1600.0 ;xy move
M108 S3000.0 ;extruder speed in RPM
M101 ;extruder on, forward
G4 P400 ;delay
G4 P200 ;delay
G1 X90.0 Y89.0 Z0.5 F1600.0 ;print segment
G1 X87.2 Y89.0 Z0.5 F1600.0 ;print segment
G1 X90.1 Y86.1 Z0.5 F1600.0 ;print segment
G1 X90.1 Y83.3 Z0.5 F1600.0 ;print segment
G1 X84.4 Y89.0 Z0.5 F1600.0 ;print segment
etc…etc…etc…etc…
G1 X9.0 Y14.4 Z0.5 F1600.0 ;print segment
G1 X14.4 Y9.0 Z0.5 F1600.0 ;print segment
G1 X11.6 Y9.0 Z0.5 F1600.0 ;print segment
G1 X10.4 Y10.2 Z0.5 F1600.0 ;print segment
G1 X9.7 Y10.9 Z0.5 F1600.0 ;print segment
G1 X9.0 Y11.6 Z0.5 F1600.0 ;print segment
M103 ;extruder off
;#!LAYER: 2/15
M107 ;cooler off
G1 Z0.8 F50.0 ;lift down <--- See! the independent Z move!
G1 Z0.8 F50.0 ;z down
G1 X90.0 Y9.0 F1600.0 ;xy move
M108 S3000.0 ;extruder speed in RPM
M101 ;extruder on, forward
G4 P400 ;delay
G4 P200 ;delay
G1 X90.1 Y9.1 Z0.8 F1600.0 ;print segment
G1 X90.1 Y11.9 Z0.8 F1600.0 ;print segment
G1 X87.2 Y9.0 Z0.8 F1600.0 ;print segment
G1 X84.4 Y9.0 Z0.8 F1600.0 ;print segment
G1 X90.1 Y14.7 Z0.8 F1600.0 ;print segment
G1 X90.1 Y17.5 Z0.8 F1600.0 ;print segment
G1 X81.5 Y9.0 Z0.8 F1600.0 ;print segment
etc…etc…etc…etc…
Hi cybair,
thanks for putting the information together!
This is no problem - in fact: right now PyCAM generates only straight moves.
hehe - you forget the final "S" in KISS: "Stupid" :)
But I agree - the spindle control will be optional.
Hm - this sounds like a problem. For 3D models it is a very common thing to move to the side and up and the same time - any slope will trigger this move.
I hope that this limitation only applies to repraps (not milling machines), since it would simply turn every ascending move into hundreds of small steps.
In other words: I don't think, this will be implemented.
OK - this will be part of the machine-specific postprocessor.
Thanks for the example!
I will take a look at this listing again, as soon as the basic structure of the postprocessors is fixed.
cheers,
Lars
Hi Lars,
I spent the last few days testing GCODE commands on the RepRap interpreter and there are a few more things that I would like to add concerning the format of RepRap-compatible GCODE.
1 - All comments should be excluded from the file. They produce a major error.
2 - The G0 command causes problems with the Z axis feedrate. It works well when all the G0 commands are replaced by G1 commands.
3 - I have found that this minimalist startup protocol works well. The feedrate is set by PYCAM.
G21
G90
G92 X0 Y0 Z0
F70
4 - Each line that contains a move should begin by G1. It is not necessary to write the full form such as G1 X5 Y20 Z12 F70 .The short form such as G1 Y23 or G1 X34 Y62 works as well as the long form.
5 - Contrary to what I said before, it seems that there is no need for an independent Z move. The problem is said to be related to wrong feedrate set by other postprocessors. PYCAM uses the same feedrate for all 3 axis and that works fine.
Thanks again for taking a shot at Reprap GCODE. Now that parallel ports are being eliminated from computers, Arduino-based bot control with USB will become the standard for hobby CNC's, routers and fabbers. By being compatible with that bunch, PYCAM might well become the standard hobby 3D CAM software as well… Who knows? ;-)
Cybair
Hi cybair,
thanks for digging further into this issue!
1) omitting comments (optionally) sounds reasonable
2) this sounds like a firmware bug (rapid feedrate too high by default?)
3) thanks for testing!
4) G0 and G1 are specified as modal commands - thus it is not necessary to prefix these to every command line. Thus this would be a bug, as well.
5) good to know!
Regarding (2) and (4): these changes would be easy to implement, but I really would not want to do this.
It should not take more than five minutes to fix these firmware bugs, thus I would not want to spoil the sphere of GCode implementations by supporting obviously broken parsers.
Please just send these firmware developers a mail - they will fix this issue instantly, I guess.
If everything else fails, it will still be fairly easy to adapt your own PyCAM postprocessor to the above limitations. But walking down that road would not be a good long-term choice and it is absolutely not necessary (AFAIK).
cheers,
Lars
Hi Lars,
that would be a great option for me as well. I downloaded Pycam yesterday and was so pleased with it's user interface and performance that I don't want to switch anymore. Unfortunately I need simple G-code as well , with always X, Y and Z per line. The reprap format should be an ok format as it is easy to strip the F's and startup codes.
We us it to mill with an old Fanuc Robot.
For now I just rebuild the G-code in Excel, but when this addition should appear in the future it would be real great!
thanks for all your efforts, and the great result,
Bastiaan
hi everyone!
I'm trying to use a reprap-like machine with pycam as well, and I've found an interesting tool on the net:
the user 'riverallen' in this blog post http://chmodux.wordpress.com/2012/07/13/g-code-mendrel/ links some python scripts that apparently does the job ( https://bitbucket.org/raw/cnc_mendel/src ): the ngc becames gcode and the marlin seems to accept it.
my question is: is it possible to add this scripts inside pycam? the only way I've found to use them is by using terminal, but it's not user-friendly at all.
thanks a lot for your work,
wasproject
Hi wasproject,
thanks for the link to the script!
Integrating the script directly does not suit to the concept of PyCAM - the (new) output formatter selection (emc2, marlin, …) will be the way to go. Thus I will probably take this script as a reference for the marlin-compatible gcode formatter.
cheers,
Lars
thanks heaps! I'm really looking forward to check out the new version!
cheers,
wasproject
Hi everyone, if someone is interested thingiverse user Mgmatteo created a useful script for converting pycam files into Marlin-friendly gcodes.
http://www.thingiverse.com/thing:52706
WasProject,
Thanks for the tip. I downloaded the file and I'm going to test the
gcode compatibility with Contraptor's firmware (Chris Meighan's
"reprap new firmware") and GRemote sender interface. But I'm not in a
rush to do that because I lost faith in Reprap software functionality
(lack of standards).
Cybair
On 3/8/13, wasproject wasproject@users.sf.net wrote: