GCode Category Tags

  • A feature/documentation request. Would it be possible to get tags/categories assigned to the gcode documentation for Duet (similar to what Marlin do).

    This will help optionally format, structure and with validation of config files (and I seem to have OCD with my code structure). But more importantly help with requests and/or learning - i.e rather than look at complete config.g, can you share the 'motion' settings.

    Reason I ask is that I've recently ripped up my config as converting from plastic to clay printing, I've spent hours going back checking / updating the files and they soon start to get very messy very quick.

    M906 E2000,1200 I60                           ; CALIBRATION  Set motor currents (mA) and increase motor idle current to 60%
    M566 E1200:1200                               ; MOTION       Maximum instant speed changes
    M203 E1200:1200                               ; MOTION       maximum speeds mm/minute
    M201 E1000:1000                               ; MOTION       Accelerations (mm/s^2)
    M140 H-1                                      ; THERMAL      Disable heated bed

  • Moderator

    @jim have you looked at the output of the RRF config tool? https://configtool.reprapfirmware.org/Start Every line is commented for function. Is that what you mean, or somewhere else?


  • Hey Ian, Thanks for quick response.

    I was asking more around tagging gcodes with a category. e.g. M566, M203, M201 all have a the same tags as relate to motion functions.

    This was I can organise my config files and can easily work identify commands that might change as I hack with my build.

    If I look at the Marlin docs (https://marlinfw.org/meta/gcode/) they have a tag next to values (motion, nozzle, calibration, etc ).

  • Moderator

    @jim the config tool outputs Gcodes in sections in config.g, such as Network, drives, heaters, fans etc. Eg:

    ; Configuration file for Duet WiFi (firmware version 2.03)
    ; executed by the firmware on start-up
    ; generated by RepRapFirmware Configuration Tool v2.1.8 on Sat Mar 14 2020 00:23:03 GMT+0000 (GMT)
    ; General preferences
    G90                                     ; send absolute coordinates...
    M83                                     ; ...but relative extruder moves
    M550 P"My Printer"                      ; set printer name
    ; Network
    M552 S1                                 ; enable network
    M586 P0 S1                              ; enable HTTP
    M586 P1 S0                              ; disable FTP
    M586 P2 S0                              ; disable Telnet
    ; Drives
    M569 P0 S1                              ; physical drive 0 goes forwards
    M569 P1 S1                              ; physical drive 1 goes forwards
    M569 P2 S1                              ; physical drive 2 goes forwards
    M569 P3 S1                              ; physical drive 3 goes forwards
    M584 X0 Y1 Z2 E3                        ; set drive mapping
    M350 X16 Y16 Z16 E16 I1                 ; configure microstepping with interpolation
    M92 X80.00 Y80.00 Z4000.00 E420.00      ; set steps per mm
    M566 X900.00 Y900.00 Z12.00 E120.00     ; set maximum instantaneous speed changes (mm/min)
    M203 X6000.00 Y6000.00 Z180.00 E1200.00 ; set maximum speeds (mm/min)
    M201 X500.00 Y500.00 Z20.00 E250.00     ; set accelerations (mm/s^2)
    M906 X800 Y800 Z800 E800 I30            ; set motor currents (mA) and motor idle factor in per cent
    M84 S30                                 ; Set idle timeout
    ; Axis Limits
    M208 X0 Y0 Z0 S1                        ; set axis minima
    M208 X230 Y210 Z200 S0                  ; set axis maxima
    ; Endstops
    M574 X1 Y1 S1                           ; set active high endstops
    M574 Z1 S2                              ; set endstops controlled by probe
    ; Z-Probe
    M558 P1 H5 F120 T6000                   ; set Z probe type to unmodulated and the dive height + speeds
    G31 P500 X0 Y0 Z2.5                     ; set Z probe trigger value, offset and trigger height
    M557 X15:215 Y15:195 S20                ; define mesh grid
    ; Heaters
    M305 P0 T100000 B4138 R4700             ; set thermistor + ADC parameters for heater 0
    M143 H0 S120                            ; set temperature limit for heater 0 to 120C
    M305 P1 T100000 B4138 R4700             ; set thermistor + ADC parameters for heater 1
    M143 H1 S280                            ; set temperature limit for heater 1 to 280C
    ; Fans
    M106 P0 S0 I0 F500 H-1                  ; set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off
    M106 P1 S1 I0 F500 H1 T45               ; set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned on
    ; Tools
    M563 P0 D0 H1 F0                        ; define tool 0
    G10 P0 X0 Y0 Z0                         ; set tool 0 axis offsets
    G10 P0 R0 S0                            ; set initial tool 0 active and standby temperatures to 0C
    ; Custom settings are not defined

    Unless you mean in the Gcode dictionary? https://duet3d.dozuki.com/Wiki/Gcode


  • @droftarts - yes, sorry I wasn't clear.

    I understand and have the generated code from the config tool and all good there. The question was specifically around the documentation in the wiki.

    Taking the code from above, it has M563 and G10 in the tools section, but what other gcode falls into the same logical section? If the Wiki had some additional meta-data / tags to map back it would be great. e.g. I want to add in M568 for mixing I know to add to the 'tools' section.

    I guess my specific ask is can the wiki be updated to tag commands like M563, G10, M568 with 'tools' or similar logical group?

  • Moderator

    @jim ah! I understand. We’ve discussed this internally, particularly as the Gcode dictionary page is rather long and unwieldy; it even causes problems for the hosting company! Unfortunately dokuwiki is rather limited in tagging/metadata. The only option seems to be having each Gcode on a separate page, and having different pages, with gcodes organised in different ways, linked to the individual pages. This makes navigation harder, and would be quite an undertaking to implement. We’re also looking at alternatives to dokuwiki that would give more flexibility in documentation. Suggestions welcome!


  • Hey @droftarts, l've got some time on my hands at the moment, so I have been doing some playing round re suggestions as per above. One option I have been exploring is using github and markdown for the content and then deploying via the github pages engine. This has the potential of tagging individual pages (although a bit crude) and also concatenating back into a full dictionary if needed for searching. If you are interested i'm happy to share thinking / code.

  • Would categorizing the gcode and its description by font color (for visual matching) or utilizing the "find" function to organize with some special character be an option? Not Ideal but wouldn't require a complete rework

  • Taking advantage of being locked-down all day; I've been playing further with potential suggestion for the GCode dictionary. The attached link only contains about half and is not polished / complete. But wanted to test/poc potential option (and selfishly I needed to learn capabilities of Github pages for another project).


    The filters on the left side-bar allow either filtering by G/M codes, or the second level has groupings by tags. Then the top search allows for standard page searches also. It's not complete, however I will have time over the coming days/weeks to spend more time if it's useful.

    pm me if interested/need further info.

  • Moderator

    @jim That looks promising.

    Personally I'm not a fan of breaking up the singular page into smaller sections simply for the reason that it makes it harder to jump around from gcode to gcode. Maybe this could be mitigated by deeper cross linking of related gcodes.

    • From a pure style, "in the eye of the beholder" perspective, I really, REALLY, really don't like the idea of needing to click several times to drill into the g-codes. I realize there is a "full list"; even that requires several clicks to get to anything meaningful.

    Breaking related information into multiple pages is one of the great weaknesses of the web, IMHO.

    From a style perspective, one really long page is highly preferable to me.

    • You can't search it. With a simple browser search.

    Given both above, if someone decides to do this, can we please generate the multi-page, categorized, version from the existing long page? With a script or similar? That way, people can maintain the long page, and the generator can run (or be run) periodically to provide the categorized view. Eat our cake and have it too...

  • Moderator

    Thanks for your work so far, @jim . However, I’d say this is going in the wrong direction. I’d prefer to keep the full, long, monolithic page, too, even though it’s a hassle to update! We could possibly host it on GitHub, though, as we do other pages at RepRapFirmware.org

    What we could do is add a category tag after each G/M code heading on the main page. Codes can fall into multiple categories eg G10, so multiple categories need to be supported. With all gcodes tagged, it should be pretty simple to create ONE new page with a script to parse the main page, take Gcode title, link and categories, and generate a list. The category tag in the main page can be a link to the category page, and categories for each Gcode could link to the related category.

    Well, that’s how I’d like it to work! Dokuwiki can’t do this as far as I know, but it doesn’t preclude the category page being hosted offsite. If it can be done through GitHub, that’s great because we already host some scripted pages with github.


  • administrators

    I've done this sort of thing in the past using XML descriptions of the underlying elements (in this case, G- and M-Code commands) and an XSL style sheet to generate HTML from them. It has the additional advantage that all the boilerplate formatting is done consistently. But maintaining the text in XML format is a pain.

Log in to reply