RRF Cheat Sheet

JoergS5

@sinned6915 I think you should make a working cheat sheet for yourself primarily, how you like it. So you have a benefit for yourself. Then you can publish it. If someone likes it or want to change, is not so important: you have already your benefit.

That said, I would make my cheat sheet with a cube, magnets inside, then 6 sheet with grouped information which can be exchanged easiy, than lamination on top, held by magnets. The sides would be

1 config
2 move (specific H of G1) and information/debug
3 fan, heaters , thermo...
4 procedures for power up, mesh calibration etc
5 filament parameters of my favorite filament (temp etc settings)
6 rare commands like SC Card related.

The sides are colored, so I find the right side fast. Step 5 is not for work at the printer, but when you configure the slicer, but it fits good to the cube content.

I saw those cubes for consultant topics (method xy), they had about 10 cm edge length each.

sinned6915

I realized that I had not updated this in a while. Its still a work in progress, but this PDF should print to US Letter landscape. I could use some help converting to SVG so it would be page independant.

Contribution/Objective Critique and Collaboration welcome.

files on git here: https://github.com/nionio6915/RRF-Cheat-Sheet

robinh23

I merely have the link bookmarked. I use Firefox, which is synced between all of my devices. Even saving tabs to the phone's home screen is possible with the most recent version of Firefox. I can get where I'm going by pressing the icon just once. The fact that there is already a quick and easy way to find the information that works well for me does not mean that having cheat sheets is a bad idea.

Falcounet

My input on this matter which others may find useful : I have added a custom search engine on Chrome (but that feature also exists on Firefox) :

This way, I just type "gcode" followed by a space in the URL bar to activate this search engine then I can type the gcode I want to get information about.

MJLew

Seems to me that it should be possible to make a cheatsheet for gcode both more easily arranged and less necessary. Make frequently used gcode numbers have plain language names that the firmware substitutes appropriately based on a straightforward substitution table. G1 could be called move(), G2 could be arc_ccw(), and so on. Include as many different parameters as needed, and increase the number of codes that have plain language names gradually. It would make manual manipulation of gcode much easier.

Yes, more work for the firmware, but not really hard work given that a one to one lookup table would suffice for the commands. A second level might be nice to deal with the parameters, but I would say that is less important.

If this is so simple, then why would it not have been done in the first place? Maybe because the letter and number codes are more concise and take less space than readable names would. The original specification of gcode was (presumably) done long enough ago that memory considerations would have been much more important than they are nowadays. The 32 bit Duet cards have more than enough grunt and space, I expect.