GCode Category Tags
-
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 ).
-
@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
-
@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?
-
@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
-
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).
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.
-
@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...
-
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
-
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.