-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Quick-Start Documentation Updates - PurpleHullPeas rev1 #26
Comments
Thanks. I do want to improve the documentation, so your observations and comments are helpful. While git is not new to me, creating and maintaining a GitHub project is. The wiki is ok, but as you point out it has its limits. I took a stab at using GitHub's Pages web hosting for one of the repositories, and it seems to work. So, I think I may move the wiki content into a separate project repository, so things like a pull request, separate branches, etc. are readily available. |
I've incorporated your suggestions into the wiki page -- good suggestions. Sadly my wiki page is filled with information, but light on being useful -- structure and organization problems, I believe. Now that content is collecting in the wiki pages, it's probably time for a documentation overhaul and a re-think on making the wiki content more purposeful. |
@PurpleHullPeas, in a calmer, take a step back moment I clicked on the "Quick Start" link -- your critique is dead-on, and I think my "band-aid" attempts to fix the issue(s) actually make things worse. So I'm in the "spit-balling" phase of a plan to overhaul the Quick Start information specifically and all of the documentation generally. To this end I'm thinking:
That's it so far. Again mulling things over, planning. Thoughts and suggestions welcomed. |
Thanks for updating it. My ultimate goal is to be able to simply point someone to the Quick-Start Guide, without any additional commentary, whenever someone asks about flashing MPMD Marlin 1.1.X. I maintain a calibration guide document and frequently answer questions in the Facebook Group. Questions appear less-frequently on Reddit, but I try to answer questions there, too. Many of the questions that pop up are super repetitive and also involved enough that I don't want to type things out over-and-over again. However, when I can simply post a screenshot or a link, helping others becomes much easier. Additional Notes: I was under the impression that the following link would always go to the latest release: CALIBRATE_25MM.gcode is a nice addition. I feel like extra attention may need to be called towards it in the Quick-Start Guide, but perhaps a well-organized FAQ is a better answer. This is certainly a recurring question in the Facebook Group. Thanks for your work. Take whatever approach you want to document your firmware. I've noticed that Marlin4MPMD's GitHub wiki is editable by pretty much anyone. I don't think that has ever been a problem for mcheah, but I understand if you want to maintain better control of the documentation. |
@PurpleHullPeas, I like your ideas. I have no particular insight into how to improve the documentation, only hunches. So, embarking on a documentation overhaul seems to me to be a "hit or miss" proposition. I think your idea of opening up the wiki has a much better chance of yielding better documentation. Yes, this a better approach. I like the wiki (over git pages) because it doesn't require a development system; a web browser does just fine. And for documentation, the wiki's limitations (no theming, limited formatting options and markup, etc.) aren't really show-stoppers. Although, it does seem overly complicated to store images in the wiki repository. I have to no problems making the wiki public -- it's a good idea. And I'm slightly embarassed that the solution didn't cross my mind. I do have one or two style guidelines, and I think we'll need one or two participation rules. I'll write them up, put them in the wiki, and then open the wiki up. And, yes, you are correct:
I was hoping to generically point directly to the latest zip file with something like: |
@PurpleHullPeas, the wiki should now be editable to all GitHub users. I posted a few "rules" but I really have only two concerns: that we are disciplined about the name of the project, and that the participants respect each other. I don't see either as a problem. You have a much better vision than I of how this documentation should serve its audience. So, please, have at it. Feel free to change the structure and organization as you see fit. I will probably be asking a lot of "why" questions -- please, don't be put out. They're not a judgment, but rather the way I come to understand things. |
@PurpleHullPeas, I'm thinking of dropping all of the variants in the assets list of the next release. I've placed the variants in a folder, |
Consolidated into one zip to download seems like a good idea for the releases. I'd restructure zip so that there is one folder in the zip to copy to the SD card. This would minimize unnecessary folders and files on the SD card that could lead to confusion. I have been putting all the M851 setup files in a subfolder to save some button presses on the LCD. |
@aegean-odyssey @mulcmu I like both of these suggestions. Admittedly, I have been doing all of my calibrating/printing directly over Octopi or Python, so my input here is based purely on guessing what might make it easier for newcomers. |
Thank you, both! @mulcmu, I think I see what you're getting at with the structure. The zip file is intended to be the entrie micro SD card contents -- the printer's firmware ignores all files but directories and g-code files, so I don't think there is problem with a simple installation instruction like "copy the entire contents to the root directory of the micro SD card". I really like the @PurpleHullPeas, are you considering turning your python script into an OctoPrint-plugin? Interesting possibility. |
@aegean-odyssey Nope. My understanding is that if Issue #25 gets added, then there will be no need for my script anymore. It could all be replaced with simple gcode files. |
My goal is to get a very good automatic calibration out of the There is a certain elegance to an external calibration tool like your script. It's scope is rather focused, but at the same time, it is open-ended along the proper lines to accommodate alternate methods, objectives, and desires. It's a solution that fits the nature of the problem well. |
I have a few suggestions for updating the Quick-Start Documentation based on some recurring questions in the Facebook Group and my experience making/updating tutorials to make them more noob-friendly. I would do the changes myself, but the Wiki is not open for editing and it appears that I cannot do a pull request for wiki updates (???).
-Add more direct links in the Quick-Start Guide to point to relevant topics.
Some users had trouble finding mpmd_marlin_1.1.x-uSDCard.zip, which I can understand. A note that it can be found near the bottom of the latest release page (hyperlinked), could be helpful here.
I realize that "Configuring a Print" is already linked, but I think adding a direct link to the Start/End Gcode could help drive the point home. I.E., 95% of the time anyone started to ask any questions about flashing MPMD Marlin 1.1.X or its predecessor, this would come up.
A reference to this issue within the "Calibrating the Printer" section may also be helpful.
-Firmware Flashing Details (including alternate method):
Here is a quick Google Doc I slapped together, which contains a method to flash the firmware via STLink. Feel free to link the document directly or extract the information as you see fit.
https://drive.google.com/file/d/1qK-VuOvtXk0OAKperCJYZGfuytqHtzNo/view?usp=sharing
-More emphasis on Start/End Gcode: I saw a lot of people simply using the same gcode from the built-in Cura definition. I'll copy-paste some suggested notes to add to the Start Gcode page.
Start Gcode Notes:
The text was updated successfully, but these errors were encountered: