RepRap compatible gcode

Cybair
2012-01-18
2013-03-11
  • Cybair
    Cybair
    2012-01-18

    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

     
  • Lars
    Lars
    2012-01-19

    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

     
  • Cybair
    Cybair
    2012-01-21

    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…

     
  • Lars
    Lars
    2012-01-21

    Hi cybair,

    thanks for putting the information together!

    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

     
  • Cybair
    Cybair
    2012-01-25

    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

     
  • Lars
    Lars
    2012-01-25

    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

     
  • betserd
    betserd
    2012-02-29

    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

     
  • wasproject
    wasproject
    2012-09-04

    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

     
  • Lars
    Lars
    2012-09-04

    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

     
  • wasproject
    wasproject
    2012-09-05

    thanks heaps! I'm really looking forward to check out the new version!

    cheers,
    wasproject

     
  • wasproject
    wasproject
    2013-03-08

    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

     
    • Cybair
      Cybair
      2013-03-10

      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:

      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

      RepRap compatible
      gcode


      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/pycam/discussion/860183/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/prefs/