Add manipulation of G-Code format by user.

Issue #100 open
Juan Pablo Caram repo owner created an issue

Users have requested to be able to:

  • Add space between X and Y coordinates, e.g.: G01 X10.0 Y5.5 instead of the current default of `G01 X10.0Y5.5. (Note: This is to support non-compliant interpreters.)
  • Replace Z up/down movements with laser on/off.

These can be addressed with defaults in the CNCJob class, which can be set via the shell. For example (not implemented):

set_sys cncjob_number_format "G0%d X%.4f Y%.4f\n"

This would be rather advanced feature, so it seems fine to keep it in the shell and away from the GUI.

Comments (15)

  1. Mikk Kiilaspää

    What about the ability to suppress Z moves (and enable M03/M05 for those who need it) without post-processing?

  2. Juan Pablo Caram reporter

    Oh, I totally missed the laser part. Did you refer to M03/M05 to turn on/off the laser? I think there are specific commands for the laser, while M03/M05 are specific for turning on/off the spindle in a router.

  3. Mikk Kiilaspää

    Well, in my case, I don't need any command at all, since I'm on an Azteeg X5 with Smoothieware, where every G01 move has laser enabled (with an optional S parameter to PWM the output in the range of 0.0 to 1.0).

    Some firmwares activate laser upon M03 and turn it off upon M05 accordingly (though, I guess these could be different on some) and don't act differently on the G01 command.

  4. Bill McK

    I have a 3D printer with RAPS 1.4 board running Marlin. I have installed a laser and driver that uses the fan's PWM output to modulate the laser power. I would like to know how I can use Flatcam to run my laser as I am going to fab PC boards (burn paint to expose the copper to be etched.). The commands are M106 Sxxx (xxx is 0-255 for laser power), and M107 to turn the fan (laser) off (or S000). Also, Flatcam generates a G94 F100.0 that throws an error as not a valid code. I imagine this is the non-printing speed, but Marlin doesn't understand it. Not a big deal but would be nice to use it. I am running Repetier on a Win7 box.

  5. Matthieu Berthomé

    I also need this feature, I'm outputting the gcode to a web app called easel for a CarveY from inventables, works OK, would be even better if the gcode contained G0/G1 and not G00/G01 (the leading zeros are not recognized).

    e.g. These parts

    # Basic G-Code macros
    t = "G00 " + CNCjob.defaults["coordinate_format"] + "\n"
    down = "G01 Z%.4f\n" % self.z_cut
    up = "G00 Z%.4f\n" % self.z_move
    up_to_zero = "G01 Z0\n"
    

    in camlib could be configurable, I guess

  6. Juan Pablo Caram reporter

    @matthieu_berthome , could you please explain your approach in pull request #67 ?

    It looks like you are trying to implement post-processors by writing Python code. I think we need to create a method to help non-coders.

  7. Matthieu Berthomé

    I tried other systems while developing this, and I think this way is the easiest and most powerful. I've tried to use a jinja2 (a web templating engine) system, some python string.format, but all of it would ultimately reinvent the wheel and recreate a whole programing language 100% usable only for flatcam postprocessors. This feels wrong and complicated to me, the syntax of a python postproc in this system looks simple and even a coder could poke in it and modify the strings that are relevant to what he wants to modify. Not sure it's the best solution, especially w.r.t packaging.

  8. Juan Pablo Caram reporter

    What I'm specifically trying to avoid is having to make an update and a new release for every new post-processor, since the things the end-user might want to do could be infinite. I was thinking more of something the users could manipulate themselves.

    This is how the TCL shell got started. Users were wanting to do so many different things, that it was better to provide an in-app interpreter so they could do whatever they wanted. If one user needed to solve some problem and another had already done it, they could just share some TCL code instead of modifying the FlatCAM source, making a pull request, waiting for the review, and then waiting for a new release (for those not using the master).

    I'm not saying your work is not the best solution, I just want to make sure that it is going to be truly practical. By this I mean useful to the majority of users, who are not coders (look at the number of downloads for the windows installer). Maybe your approach could be the starting point for a user-configurable post-processing system.

    Also, could you please explain how your approach works, and perhaps some examples here.

    Thanks

  9. Matthieu Berthomé

    Definitely, this system is designed to be completely independent on your release. I made it like a plugin system.

    So, to explain the system: Each postprocessor is a .py file. The postprocessor files are not included in flatcam, they are in the data_path folder, which is in a user folder somewhere that depends on the OS (maybe we could add a menu somewhere in flatcam to navigate to it?). By default, there is only one postprocessor, 'default'. Every .py file in the data_path/postprocessors folder is imported in python then metaclass magic happens that makes them registered in the global flatcam app object. The postprocessor is selected by name at the same point as when creating a cnc/gcode object, there is the option to modify the append/prepend text, there is now a dropdown with 'default' or other postprocessor depending on what postprocessors the user has installed in his data_path folder. This is saved in the project file just like other options.

    I can write a wiki page for all this if you need.

    In camlib.py, the postprocessor object is used to generate the gcode lines that are relevant to the context. Each postprocessor method, like start_code(p) gets a parameter p that is the context-aware "post data", for example when generating gcode for a tool change, then p.toolC is the number of the tool, some other times p.x,p.y is the X,Y point to go to, etc. I think default.py is plenty self-documenting, but it's difficult to see from an outsider perspective when you designed the stuff ^^

    No matter how it's done in the end, there is a need to get a postprocessor system. Every CAM software I touched has a system with "a postprocessor fil" = "a machine", all of them use different languages in those files but the idea of a postprocessor file that is copied around and tweaked is almost universal.

  10. Juan Pablo Caram reporter

    I understand your code now.

    With regards to the "plugin system":

  11. Log in to comment