RRF Cheat Sheet
-
@sinned6915 said in RRF Cheat Sheet:
@CaLviNx said in RRF Cheat Sheet:
My browser it set to open a specific set of pages on startup, the Duet G-Code Page being one of them
I agree, the webpage is handy, but it does you NO GOOD when the nearest compter is on a different floor of the house and you are standing there looking blankly at a PanelDue screen.
Hence the untility of a couple of pages to keep at the machine.
Bad planning then, the simple/smart solution would be to have a dedicated pc/laptop in same location as the printers...
-
@CaLviNx said in RRF Cheat Sheet:
Bad planning then, the simple/smart solution would be to have a dedicated pc/laptop in same location as the printers...
That is a really disappointing reply and frankly it's borderline insulting. If you have nothing positive to contribute to this topic, then go troll someone else's threads.
The intent of the thread I started was to be about a simple, handy, easilly accessible and useful reference. I certainly did not expect to be hickacked and berated for not having the resources to have a 2nd computer near my printer for convenience.
-
@sinned6915 I looked into your list, I would really like some grouping of the commands like as example https://www.openscad.org/cheatsheet/ so the commands can be found faster.
Another proposal as addition to my list above: I would explain some specific parameters like for probes and heaters, and the H parameters of G1. I must look up H1 vs H2 every time I want to use it, a cheat sheet would speed it up.
Your comment about a procedure checklist: it's true that some procedures are very long and cannot be added to a cheat sheet. But I thought about a list with short description points like an airplane preflight check, to have a list of an ordered checklist. The reason is to procede in the correct order and to not forget a step.
-
I agree with the catagories and heirarchy. I tool a 1st pass at the list to creat catagories.
Here is what I have come up with for the first page -
What I don't like is how long some of the entries have gotten due to all the options. I tried trimming it down from 3-n's to 1, and they are still LONG.
Have a look at the spreadsheet and see if you like the catagories.
i am still trying to figure out what to put in front and on back.There are a LOT of file entries, but wonder their need. I am not sure many people print from SD cards directly.
-
@sinned6915 this is not the sheet how I would do it, but it is a matter of taste. So go ahead how you like it.
The letters and meanings should be linked to the G-Codes, because the meanings differ depending on the G-Code. P has very different meaning for example for different G-Codes, so it is necessary to link them to a specific G-Code imho. A proposal would be to use the example column for the explanation, because the examples are often not necessary. (The examples can be dedicated from Codes&Arguments. In fact the examples are a bit misleading, because most values are not integer, but float).
For XYZ parameters, a comment about the type would be valuable: cartesian or axis value, absolute value of difference value.
-
@JoergS5 can you mock up an example of what you are thinking of as an example?
The difference that I see with OpenSCAD is that the commands there are self explanatory- 'cube' means cube.
https://www.openscad.org/cheatsheet/for the G & M codes, there needs to be some list item to explain before giving the eample
-
@sinned6915 I would group it visually similar to OpenSCAD, groups config, moving, information, fan, heater, calibration, SD card.
M104 Sn.n target temp Tn tool number
I am not sure whether it's worth explaining all commands. Some are used so rare that it's easier to look them up in the documentation. I mean mentioning them to know there is something for a specific topic, but not explaining all parameters. OpenScad is similar: r1, r2 are not explained on the sheet.
If you need more space, you could make a cube cheat sheet with 6 sides.
-
@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.
-
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
-
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.
-
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.
-
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.
