Document G-Codes used in current firmware

[pschuster]

G-Codes are hardcoded in the firmware (see Printr.cpp). This has issues with sending files via WiFi and for overall flexibility.

As a first step we should document current G-Codes used and then decide where to split them or where to implement them. Documentation is required in Wiki

There are various possibilities:

1. Keep them in the firmware as is (hard coded)
2. G-Codes downloaded from the Cloud contain all G-Codes (i.e. G-Codes are generated in the cloud)
3. G-Codes are stored on internal SD card.
4. ...

Tasks

• Document G-Codes used in current firmware
• Discuss and decide where to put them (in this issue)
• Create issues required for refactoring

[oddirmeyer]

Starting G-code descriptions updated and ready for review. @abdrumm Can you double-check for accuracy, please? https://github.com/Printrbot/Printrhub/wiki/G-Codes

[pschuster]

Awesome. Thank you very much. That makes things easier I think. The next step would be to cluster those G-Codes in basic setup, and print preparation or should we do things like reset x and y and probing before each print?

What I mean is this: We could have basic printer setup in the firmware that runs when the printer is turned on, i.e. reseting X/Y, and probing Z. Then we would not need to have those G-Codes in files sliced in the cloud or at home, simplifying both aspects and users cannot make dump mistakes by copying wrong setup G-Codes in their slicer.

@abdrumm: Do we need to have that probing before each print? Or would it be enough to have that once when the printer is turned on?

[abdrumm]

I am ok w minimum viable product that works ;) so we don’t HAVE to do it before every print. I think since all printers probe before print, it’s just best practice... conservative but not necessary