GCode Category Tags

jim · 13 Mar 2020, 21:54

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

droftarts · 13 Mar 2020, 23:34

@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?

Ian

jim · 14 Mar 2020, 00:16

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 ).

droftarts · 14 Mar 2020, 00:26

@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

Ian

jim · 14 Mar 2020, 00:54

@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?

droftarts · 14 Mar 2020, 01:35

@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!

Ian

jim · 21 Mar 2020, 11:07

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.

3DPMicro · 21 Mar 2020, 13:03

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

jim · 22 Mar 2020, 09:43

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).

https://j1mw.github.io/Gcode/index.html

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.

Phaedrux · 22 Mar 2020, 18:52

@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.

Danal · 22 Mar 2020, 19:20

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...

droftarts · 23 Mar 2020, 11:47

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.

Ian

dc42 · 23 Mar 2020, 16:54

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.