Add the output of the G-code command about marlindocumentation HOT 6 CLOSED

You will contribute these to the documentation?

from marlindocumentation.

I have allready done the M114 (current position)

I want to now the "path" to develop a page and get it pushed to GitHub and
approved thru the Pullrequest and published

Its more the git-flow and proper way to work I want to learn.

I have a up and running Ruby/Jekyl workspace and have alredy done a minor
change to The G21 gommand (= typo). That was easy, but bulding something
from scratch is more complicated. (I think anyway)

I have not found any documentation about the format of the output from a
G-code.
Some is ending with ok\n and some is not (Initial responce from Marlin at
startup is not ending with ok\n . M105 is not ending with ok\n)
Some G-code responses are clear but some contains mysterious properties (=
M105 and the @: propertie for example)

Could it be an idea to add the output of a g-code to the documentation. ( I
have made an issue)

I have also made a configure and setup tool for Marlin called
Marlin3DprinterTool. Its like a working "documentation" of how to test and
setup a 3d printer.
(This is where I need to understand the response frome th G-code cmmands )

It contains:

• Visual endstop testing (X-min. X-max, Ymin, Y-max Z-Min = Z-Probe, Z-Max)
• Bed limitations. ( Use jog control to find the limits and save them)
  • Next option is to update Firmware from the values found
• Bed level ( Use the probe to find how uneven the buildingsurface is
  • Suggest how to turn the adjusters (clockwise/CCW and amount of turn)
• Visual picture of how uneven the building surface is
  • the 4 corners = Bed Level
  • Many points = show if the surface has hig and/or low spots
• Z-probe Heigth calibration
  • Find the Z_PROBE_OFFSET by using GUI and a paper
• PID autotune with GUI
  • Update Firmware from found new PID
• Z maintenanse
  • Move the Z up and down and make it possible to oil and clean Z-rods
    while moving
  • Search for spots where the Z-rods dont move smooth
• Firmware
  • Find all "features" in current firmware files
  • Show feature value
  • Update current firmware files
  • Run Arduino IDE to upload changed Firmware files
• Firmware update (Update from current Marlin to new Marlin RC X)
  • Current firmware and new firmware compare
  • "Feature" in current firmware is found in new firmware files
  • Transfer current firmware feature value to new firmware files. (keep
    rowposition in new Firmware regardless rowline in current Firmware)
  • Update new Firmware files
  • Makes old values in new Firmware as comment with ending date and time
    (= Keep track of changes)
  • Run Arduino IDE to upload changed new Firmware files

Under development:

• Extruder calibration
• FilamentSensor
  • Use I2C with Marlin to find realtime movement of filament
  • Out-of-Filament
  • Filament diameter

Its available at GitHub as a VS2015 project. (
https://github.com/cabbagecreek/Marlin3DprinterTool )

Could this be something to look at?

MANY REGARDS

2016-08-19 23:07 GMT+02:00 Scott Lahteine [email protected]:

You will contribute these to the documentation?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#34 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAriYcKd6I3Gxsa5IFuP__BurYsM250vks5qhhscgaJpZM4JkJ3G
.

from marlindocumentation.

to develop a page and get it pushed to GitHub and approved thru the Pullrequest and published

Have you read all the Github documentation on this subject? I would explain it all at length, but Github have done a very good job of covering this topic. You would also benefit greatly from watching some videos and engaging in some interactive online tutorials to learn the basics of Git branching, merging, rebasing, etc. The first thing you need to do is create forks of Marlin and the Marlin documentation repository under your own Github account. Then, get a copy of Github Desktop, which makes dealing with branches, commits, etc. much easier.

from marlindocumentation.

I have done all in the Github documentation and got it up and running. I
guess that I have lack experiance in Git so I will do some tutorials.

I did a copy of the Marlin dokumentation and NOT a fork to my Github
account. Thats may be the key to get this up and running and be able to
make the right commits

Thank you for your suggestions

from marlindocumentation.

You should always fork because then you have a link upstream so you can rebase as primary repository is updated and you can create your own downstream forks to test changes so you don't have to break the
"master" code in your forked repository.

from marlindocumentation.

Honestly the best way to figure this out would be to test sending these commands to a printer and observing the response in host program like Repetier or Pronterface, etc.

from marlindocumentation.