Printrbot
Document G-Codes used in current firmware
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:
- Keep them in the firmware as is (hard coded)
- G-Codes downloaded from the Cloud contain all G-Codes (i.e. G-Codes are generated in the cloud)
- G-Codes are stored on internal SD card.
- ...
Tasks
- [x] Document G-Codes used in current firmware
- [ ] Discuss and decide where to put them (in this issue)
- [ ] Create issues required for refactoring
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
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?
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
