Git Product home page Git Product logo

marlindocumentation's People

Contributors

anhardt avatar bob-the-kuhn avatar brettvitaz avatar descipher avatar edwilliams16 avatar ellensp avatar evilgremlin avatar filipgoc avatar gmagician avatar jbrazio avatar landodragon141 avatar lvd-ac avatar manuelmclure avatar marcio-ao avatar mbuc avatar njdancer avatar rfbomb avatar roxy-3d avatar sarf2k4 avatar shitcreek avatar sineos avatar slowbro avatar speaka avatar stevilknevil avatar teemuatlut avatar thinkyhead avatar thisiskeithb avatar tombrazier avatar tworedcells avatar vovodroid avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

marlindocumentation's Issues

M203 report wrong argument

Don't know if right place.
On web site M203 report [?] as argument, but argument is velocity, not acceleration

M43 documentation is not up to date WRT the implementation

The M43 gcode doc is not up to date WRT the implementation

  • The L has only changed as a selector for one of the options, the E is still used for endstop tracking.
  • The S option (to testservo probe) is missing

The different sub-options would need clean argument explanations.

Got a compiler error: can't assign float num to parameters

I was setting up the auto bed leveling parameters when I encountered the "floating constant in preprocessor expression" error.

#define X_PROBE_OFFSET_FROM_EXTRUDER 1.23
#define Y_PROBE_OFFSET_FROM_EXTRUDER -8.3
#define Z_PROBE_OFFSET_FROM_EXTRUDER -14.3

Arduino reports this error if I use floating numbers. Meanwhile fixed parameters will certainly pass compilation.

Trying to fix it. Anyone got some tips?

pub-marlindoc.sh

I ran into a couple of items when using the pub-marlindoc.sh script:

  • I couldn't find a HTMLPROOFER so I used the Ruby HTML-PROOFER. Is that the correct one?
  • Here's the text from the end of the script. Either I don't have the privileges to write to gh-pages or the script has a bug.
    '''
    sent 23,659,233 bytes received 5,761 bytes 3,640,768.31 bytes/sec
    total size is 23,635,701 speedup is 1.00
    HEAD is now at f90933c Trying to fix some broken links
    error: pathspec 'gh-pages' did not match any file(s) known to git.
    '''

Add the output of the G-code command

Adding syntax for the response of a G-Code command for each G-Code

Example:

G-Code M105
will create a response like
ok T:195.4 / 195.0 B: 27.8 / 0.0 T0: 195.4 / 195.0 @:29 B@:0

The documentation should contain the explanation of each component of the response.

Coding Standard refactoring

TL/DR

I read the Coding Standards to contribute code to the Project. After reading it I found (in my opinion) not optimal rules.

abbreviations

the rules

Filenames (optional):

even trough the CCG allows .h [CCG-SF.1]. It is good practice to use differending endings like .hpp or .hh to differential between C-Headers, C-only-Headers and C++-only-headers.

Capitalization

okay but the reason to use camelCase is not valid. Namespaces are there to prevent namingproblems. Thats why we use C++ not C. The Rule should then not allow camelCase but a new rule should force using of namespaces.

Language Features

  • Should be updated for newer Marlinversions to get access for newer compiler and languagefeatures. Arduino 1.6.8 is from 9 march 2016.

  • Dissallowing STL is really a bummer. I understand the conflict that big parts of the standard are note usable in bare metal but to forbid useful, working, powerful parts makes no sense.

Primitive Types

First rule is really good. I'm missing it in almost every project!
Second rule is is suboptimal. Because of roundingerrors floating point datatypes should be forbidden.

  • just check 0.1f+0.2f.
    For every positioning or other things integers must be used. (didnt checked the usage in code)

Memory Usage

if macros are forbidden (later in this issue) a static can be annoying with enabled compilerwarnings

-Wunused-function

Warn whenever a static function is declared but not defined or a non-inline static function is unused. This warning is enabled by -Wall.

SRC

Minimize Repetition

  • seriously. This example and the rule are the worst part in the document. You are dividing understandable code to a less good readable one? just to save 18 (19characters saved - new newline) Characters? Even in UTF8 it is nothing. That is not clever. Its overengineered without benefits.
  • Macros are bad. They are not debuggable in Debuggers. Use Variables, Enums etc. CCGEnum.1 Even trough some Controllerboards use Debugpins for other functions there are some that work. Other ones can be misused.

Best-Practices for #include

you can save many problems with namespaces and a filestructure that mirrors it and with #pragma once (include only one time). developer discipline is still needed but static tools can help

Preprocessor directives

we use C++11. #define is the enemy of every C++-Coder.

  • #define instead of const?
  1. const is a extrem helpful. If you need a runtimevariable that should be not rewritten you use it. That can happen in specific structs.
  2. Language Features saidsomething about constexpr. Use it and not #defines. You get the benefits of #define but with debuggable code. already mentioned but C++11 > C

Macros

  • already said something about macros
  • already said something about floating point numbers

Math Macros

same as Macros

Adding a New Feature

i don't want to repeat myself.

CI failure: broken link(s) to source files?

Travis CI has been failing on recent documentation PRs, with what appear to be broken links to source file(s). I tried looking into this but I'm not familiar enough with how Jekyll and Github interact to fix this.

Failing section of CI run:

/home/travis/build/MarlinFirmware/MarlinDocumentation/_site/docs/development/lcd_language.html
  *  External link https://github.com/MarlinFirmware/Marlin/blob/Development/Marlin/ultralcd_implementation_hitachi_HD44780.h failed: 404 No error
  *  internally linking to /MarlinFirmware/Marlin/tree/1.1.x/buildroot/share/fonts#readme, which does not exist (line 46)
     <a href="/MarlinFirmware/Marlin/tree/1.1.x/buildroot/share/fonts#readme"> file</a>
  *  trying to find hash of /MarlinFirmware/Marlin/tree/1.1.x/buildroot/share/fonts#readme, but /home/travis/build/MarlinFirmware/MarlinDocumentation/_site/MarlinFirmware/Marlin/tree/1.1.x/buildroot/share/fonts does not exist (line 46)
     <a href="/MarlinFirmware/Marlin/tree/1.1.x/buildroot/share/fonts#readme"> file</a>
htmlproofer 3.7.4 | Error:  HTML-Proofer found 3 failures!

I think the first failure may be cause by ultralcd_implementation_hitachi_HD44780.h being renamed to ultralcd_impl_hitachi_HD44780.h. I'm not sure about the second error, since MarlinFirmware/Marlin/tree/1.1.x/buildroot/share/fonts#readme works in my browser.

I'll submit a PR if I can figure out what's going on, otherwise I wanted to document it.

Bitmap Converter comma issue

There is a bug in the Bitmap Converter for _Bootscreen.h and _Statusscreen.h generation.

http://marlinfw.org/tools/u8glib/converter.html

The last element of the bmp array is not comma separated from the previous one.

Arduino IDE throws a compilation error if the generated bootscreen was copy&pasted to the _Bootscreen.h file in the Marlin folder.

Docco or Code issue with Z_MIN_PROBE_ENDSTOP

While working through Configuration.h setting up UBL without a probe I encountered some behaviour that took me ages to track down.

/**
 * Z_MIN_PROBE_ENDSTOP
 *
 * Enable this option for a probe connected to any pin except Z-Min.
 * (By default Marlin assumes the Z-Max endstop pin.)
 * To use a custom Z Probe pin, set Z_MIN_PROBE_PIN below.

There seem to be a couple of issues here.

  1. I don't think it does default to Z_MAX_PIN
    The reason I don't think it does is that I get a compile time error:
    In file included from /tmp/arduino_build_434346/sketch/Marlin_main.cpp:308:0:
    /tmp/arduino_build_434346/sketch/endstop_interrupts.h: In function 'void    setup_endstop_interrupts()':
    endstop_interrupts.h:198: error: static assertion failed: Z_MIN_PROBE_PIN is not interrupt-capable
           static_assert(digitalPinToPCICR(Z_MIN_PROBE_PIN) != NULL, "Z_MIN_PROBE_PIN is not interrupt-capable");
           ^
    
    When I add
    #define Z_MIN_PROBE_PIN Z_MAX_PIN
    
    This compile issue goes away.
  2. In the section Endstop Settings the docco does say
    // Specify here all the endstop connectors that are connected to any endstop or probe.
    
    but that is in a different section of the config file. It took me a hell of a lot of grepping to realise that is what was missing from my config, causing more errors. I think it'd be nice to mention this in the Z_MIN_ENDSTOP comment, and/or upgrade the sanity check, which fails with
    #error "Z_MIN_PROBE_ENDSTOP requires the Z_MIN_PROBE_PIN to be defined."
    
    because pins.h says
    #if DISABLED(USE_ZMAX_PLUG)
      #undef Z_MAX_PIN
      #define Z_MAX_PIN          -1
    #endif
    

Cannot communicate with RAMPS 1.4 w/TMC2130 enabled

Using atom successfully compiled and uploaded to two Panucatt rearm boards.

Board 1 setup with TMC2130s - Unable to communicate with board when TMC2130s are enabled
Board 2 setup with A4988 Drivers - Able to communicate with RAMPS board with no issues.

Problem re-created by enabling TMC2130s on Board 2 (after swap out) and unable to communicate using Pronterface

Boards - RAMPS 1.4
Panucatt Rearm
Pronterface version 1.6.0
Windows 10 - Comms Ports (default settings)
Com 7 - setup for Board 1
Com 8 - setup for Board 2

Configuration for both in Configuration.h
#define SERIAL_PORT 0
#define SERIAL_PORT_2 -1
#define BAUDRATE 1000000 - Multiple board rates configured and tested.

Where to put documentation on how to use G26 to physically level the bed?

I want to write a documentation section on how to use G26 to help physically level the bed by moving to each of the four corners and running a partial G26 (producing a 2x2 subgrid) at each corner, for example:

G26 D X0 Y0 R4 B65 H205 L0.2 O3
G26 D X220 Y0 R4 B65 H205 L0.2 O3
G26 D X220 Y220 R4 B65 H205 L0.2 O3
G26 D X0 Y220R4 B65 H205 L0.2 O3

My first thought was to add this to the UBL doc, but this really applies to any of the leveling methods that can enable G26_MESH_VALIDATION so I'm not sure where the best place to put it is. Any suggestions?

On a different note, I was thinking of possibly adding an option to G26 that would automate generating this pattern. I'm trying to figure out which letter would be the best for this option - it looks like E I M N T V W Z are still available. Do you think this would be a good addition to G26, and which letter would be the best? Unfortunately P for physical and C for corner are already used. Maybe T for tramming would work.

[FR] Y or opposite X options in k-factor tuning gcode generator

Feature request:

First, I want to thank whoever recently added the k-factor tuning G-code generator - this is AMAZING. I've only recently started playing with linear advance, and it definitely lowers the barrier to entry with respect to tuning.

Since I have zero experience with HTML or JS, my request is this: I would love to see an option to do one (or either?) of the following:

  • Have the tuning lines run in Y instead of X (basically, swap X and Y in all the generated Gcode?)
  • Have the tuning lines run from R to L (X+ to X-) instead of L to R

The reason is this: I have a dual extrusion machine, with the primary nozzle on the right side. With the default motion (L to R in most coordinate spaces, I think), this means that the inactive nozzle is dragging right over the beginning of each line.

With some materials this isn't so bad - PLA for example - but I've tried numerous times to print test patterns with PETG to no avail. There's too much tendency for the beginning of at least one line to lift a little, then the inactive nozzle grabs it, and I end up with a tangle of filament that kills the rest of the test print since these are all single extrusion, single-layer lines.

In my case, which I think is representative of many dual-extrusion machines, either reversing the direction of the test lines or printing them in Y rather than X should completely solve this problem. This isn't a symptom of poor dual extrusion setup IMO, just a consequence of the fact that sometimes there's a tiny amount of peel at the beginning of an extrusion.

If nobody wants to jump on this maybe it will be an excuse to learn a bit of JS... but real life is keeping me pretty busy right now, and I'm hoping to contribute to the project and documentation in other ways.

M208 S/W parameters description error

The description for the S and W parameters is incorrect for the M208 - Set Firmware Recovery command

[S<length>] | Recover length
[W<length>] | Recover swap length (multi-extruder)

The parameters are are a plus/minus offset to the lengths set with the M207 command, not absolute lengths. Suggested change:

[S<length>] | Recover length offset
[W<length>] | Recover swap length offset (multi-extruder)

[Bug] Online image converter not Marlin 2.0 compatible

Foreword: I'm putting this here in the Marlin issue tracker because I don't see a more appropriate place. Issue moved here at @Ludy87's suggestion.

Description

The online image converter located at http://marlinfw.org/tools/u8glib/converter.html has several minor bugs, when generating a status screen logo. The code block generated has incorrect syntax, and what it creates is not Marlin-2.0 compatible at any rate:

  • The converter sets the image width as STATUS_SCREENWIDTH, but Marlin 2.x expects STATUS_LOGO_WIDTH.
  • The name of the array (? what we call a table in Lua) is incorrect. The converter sets it to
    status_screen0_bmp but Marlin expects status_logo_bmp.
  • Minor nitpick: the converter is appending a redundant comma to the end of the bitmap data. (fixed by 7ac32c6)
  • Not sure if it matters: #pragma once is used in other example status screen images supplied with Marlin, but the converter does not insert that directive into its output.
  • Also, the converter is inserting at least one space between items in the last line of output, where it should be inserting a comma. B00000000,B00000000,B00000000,B00000001 B11000000, This confuses the compiler, causing it to error out (look between the 4th and 5th bytes). (fixed by 7ac32c6)
  1. On the converter page, the text "If this tool doesn't work in your browser, use the server-side tool at digole.com." links (at the end there) to a page that declares itself as deprecated, which then recommends users follow another link to an "online emulator", which, to put it politely, looks like something straight out of 1990, and seems not to be particularly useful... I recommend just deleting this line of text from the page.

Steps to Reproduce

Browse to http://marlinfw.org/tools/u8glib/converter.html and plug in a suitable image file, examine the output.

Expected behavior:

I should get a block of code I can copy/paste directly into _Statusscreen.h

Actual behavior:

I got a block block of code that required an enormous 😉 4-line change to make it work.

Additional Information

_Statusscreen.h as generated by the converter (outdated)
/**
 * Made with Marlin Bitmap Converter
 * http://marlinfw.org/tools/u8glib/converter.html
 *
 * This bitmap from the file 'marlin-prusa-i3-status-screen-logo.png'
 */
#define STATUS_SCREENWIDTH 40
const unsigned char status_screen0_bmp[] PROGMEM = {
  B00000001,B11111111,B00000001,B00000000,B00000000,
  B00000010,B00000111,B00000011,B00000000,B00000000,
  B00000100,B01010011,B00000011,B00000000,B00000000,
  B00000100,B10101001,B00000111,B10000000,B00000000,
  B00000100,B10101001,B00000111,B10000000,B00000000,
  B00000100,B10101001,B00000111,B11001110,B00000000,
  B00000100,B10001001,B00001000,B01111010,B00000000,
  B00000010,B00000010,B00001111,B10010100,B00000000,
  B00000001,B11111100,B00011111,B11111100,B00000000,
  B00000000,B00000000,B00111111,B11111110,B00000000,
  B00000000,B00000001,B11111111,B11111111,B00000000,
  B00000011,B11111111,B11110111,B11111111,B10000000,
  B00000000,B00001111,B10111011,B11111111,B10000000,
  B00000000,B00000001,B11111011,B11101101,B11000000,
  B00000000,B00000010,B11111011,B11110101,B11000000,
  B00000000,B00000101,B10110111,B11110101,B11000000,
  B00000110,B00001110,B00001111,B11111110,B11000000,
  B00000101,B00000000,B00000000,B00000110,B11000000,
  B00000101,B01010101,B00110011,B10000110,B11000000,
  B00000110,B01100101,B01100100,B10000011,B11100000,
  B00000100,B01000101,B00110101,B10000010,B11100000,
  B00000100,B01000011,B01100010,B10000001,B11110000,
  B00000000,B00000000,B00000000,B00000001,B11010000,
  B00000000,B00001110,B00000000,B00000011,B10000000,
  B00000000,B00100010,B00000000,B00000111,B10000000,
  B00000000,B00000100,B00000001,B11111111,B10000000,
  B00000000,B00100010,B00000111,B11111100,B10000000,
  B00000000,B00100010,B00001100,B00000000,B11000000,
  B00000000,B00101100,B00000000,B00000111,B11000000,
  B00000000,B00000000,B00000000,B00000001 B11000000,
};
The corrected code (outdated, see below)
/**
 * Made with Marlin Bitmap Converter
 * http://marlinfw.org/tools/u8glib/converter.html
 *
 * This bitmap from the file 'marlin-prusa-i3-status-screen-logo.png'
 */

#pragma once

#define STATUS_LOGO_WIDTH 39

const unsigned char status_logo_bmp[] PROGMEM = {
  B00000001,B11111111,B00000001,B00000000,B00000000,
  B00000010,B00000111,B00000011,B00000000,B00000000,
  B00000100,B01010011,B00000011,B00000000,B00000000,
  B00000100,B10101001,B00000111,B10000000,B00000000,
  B00000100,B10101001,B00000111,B10000000,B00000000,
  B00000100,B10101001,B00000111,B11001110,B00000000,
  B00000100,B10001001,B00001000,B01111010,B00000000,
  B00000010,B00000010,B00001111,B10010100,B00000000,
  B00000001,B11111100,B00011111,B11111100,B00000000,
  B00000000,B00000000,B00111111,B11111110,B00000000,
  B00000000,B00000001,B11111111,B11111111,B00000000,
  B00000011,B11111111,B11110111,B11111111,B10000000,
  B00000000,B00001111,B10111011,B11111111,B10000000,
  B00000000,B00000001,B11111011,B11101101,B11000000,
  B00000000,B00000010,B11111011,B11110101,B11000000,
  B00000000,B00000101,B10110111,B11110101,B11000000,
  B00000110,B00001110,B00001111,B11111110,B11000000,
  B00000101,B00000000,B00000000,B00000110,B11000000,
  B00000101,B01010101,B00110011,B10000110,B11000000,
  B00000110,B01100101,B01100100,B10000011,B11100000,
  B00000100,B01000101,B00110101,B10000010,B11100000,
  B00000100,B01000011,B01100010,B10000001,B11110000,
  B00000000,B00000000,B00000000,B00000001,B11010000,
  B00000000,B00001110,B00000000,B00000011,B10000000,
  B00000000,B00100010,B00000000,B00000111,B10000000,
  B00000000,B00000100,B00000001,B11111111,B10000000,
  B00000000,B00100010,B00000111,B11111100,B10000000,
  B00000000,B00100010,B00001100,B00000000,B11000000,
  B00000000,B00101100,B00000000,B00000111,B11000000,
  B00000000,B00000000,B00000000,B00000001,B11000000
};

Note: I'm not sure whether it was really necessary to set the width to 39 pixels, but that's what one of the other stock Marlin images used, and I assumed a value one pixel less than a whole byte's worth may be important, so I followed suit.

Incidentally, here is the image I used:
marlin-prusa-i3-status-screen-logo

EDIT: See also MarlinFirmware/Marlin#14534 (comment) for updated image (and code for it).

Problems...

@jbrazio

Hey... Sorry for the inconvenience! I was cleaning up the teams and privileges, and I got rid of (what I thought was) an unused, duplicate team name. And you disappeared. But I've sent out a new invite and when you accept, I'll get things back to where they used to be.

marlifw.org is not served over HTTPS

Marlin's website is served over HTTP, which major browsers (Chrome, Safari) are rightly pointing out is not secure.

It seems easy enough to set up Let's Encrypt to manage SSL certificates automatically. Is there a specific issue preventing you from adopting HTTPS?

Perhaps that's something I can help with? I recently set up https on my website (https://radex.io), which also uses Jekyll

Motor Steps Chart

Hi,

I wanted to add my own content but I'm unable to get jekyll and bundle/bundler installed with ruby. I got some errors. Therefore I don't know how to troubleshoot this thing (although someone did helped me last time) but that was I think last year.

I need help in getting the motor steps chart all into one place.

LCD axis movement display

I notice that when using the LCD to lower the Z axis, if the endstop is triggered the axis will not go any lower. However, the relative position shown on the display continues to decrement.

That causes the display to get out of sync with real life.

Jekyll 3 upgrade - Rouge vs. Pygments.rb & other changes

While playing with the 20 Oct merge I got a message to upgrade to Jekyll 3 (which I did). The Jekyll upgrade page talks about using Rouge instead of Pygments.rb as the highlighter.

Should we start using Rouge?

There were a lot of other changes listed in the upgrade link. Are there any that we need to be paying attention to?

Origin vs Home position vs ...?

I think the way Marlin and more importantly the docs are using 'origin' is confusing and needs to be clarified.

background:

  • In the documentation, 'origin' is used for G28 position, as in G28 ; Go to origin on all axes.
  • In Marlin language files, the MSG_SET_ORIGIN is a somewhat abandoned thing that called up G92 X0 Y0 Z0, but menu-wise replaced by MSG_SET_HOME_OFFSETS with M428. (And we do not usually associate G92 with 'origin'... Even though I guess zeroing all exes does shift the origin. )
  • question is, what is origin on a printer for a user?

reasoning

I think that G28 aftermath should not be called 'origin'. Even though this is fundamentally the origin for the absolute space, we do not expose this origin to the users! Instead, we allow home offsets (and other things) to shift the functional [0,0] around to tweak the actual starting position. (On a cartesian printer, this would correspond to the corner of the build area.)

From the user's perspective, it makes much more sense to refer to the [0,0] as affected by home offsets are the origin. This is the 'origin' of the build area and the start of the print. And this is also what we actually display on the LCD as [0,0]! Surely, it would make sense to refer to [0,0] the origin - or at least it's the tradition.

summary proposal:

  • Home position
    • Use Home position for whatever happens when G28 is run
  • Origin
    • reserve Origin for the [0,0] as affected by home offsets and/or g92
    • i don't think there's need to distinguish between M206 and G92 effects here. that's up to the user
  • in terms of documentation, this means to get rid of the word 'origin' from the G28 help page.
  • ideally, it would also mean to rename the MSG_SET_ORIGIN, but that does seem to be a hassle that is maybe unnecessary.

Add available information as appendix to UBL documenation

As I removed my capacitive sensor to go with manual probing I needed more information about the parameters of the P2 commend (to get a better understanding).
Finding it in ubl_G29.cpp was very useful. Why not add these information as an appendix to the UBL documentation?
Or give a hint where to find it.

This is the info I'm referring to:

   *
   *   Parameters understood by this leveling system:
   *
   *   A     Activate   Activate the Unified Bed Leveling system.
   *
   *   B #   Business   Use the 'Business Card' mode of the Manual Probe subsystem with P2.
   *                    Note: A non-compressible Spark Gap feeler gauge is recommended over a business card.
   *                    In this mode of G29 P2, a business or index card is used as a shim that the nozzle can
   *                    grab onto as it is lowered. In principle, the nozzle-bed distance is the same when the
   *                    same resistance is felt in the shim. You can omit the numerical value on first invocation
   *                    of G29 P2 B to measure shim thickness. Subsequent use of 'B' will apply the previously-
   *                    measured thickness by default.
   *
   *   C     Continue   G29 P1 C continues the generation of a partially-constructed Mesh without invalidating
   *                    previous measurements.
   *
   *   C     Constant   G29 P2 C specifies a Constant and tells the Manual Probe subsystem to use the current
   *                    location in its search for the closest unmeasured Mesh Point.
   *
   *                    G29 P3 C specifies the Constant for the fill. Otherwise, uses a "reasonable" value.
   *
   *   C     Current    G29 Z C uses the Current location (instead of bed center or nearest edge).
   *
   *   D     Disable    Disable the Unified Bed Leveling system.
   *
   *   E     Stow_probe Stow the probe after each sampled point.
   *
   *   F #   Fade       Fade the amount of Mesh Based Compensation over a specified height. At the
   *                    specified height, no correction is applied and natural printer kenimatics take over. If no
   *                    number is specified for the command, 10mm is assumed to be reasonable.
   *
   *   H #   Height     With P2, 'H' specifies the Height to raise the nozzle after each manual probe of the bed.
   *                    If omitted, the nozzle will raise by Z_CLEARANCE_BETWEEN_PROBES.
   *
   *   H #   Offset     With P4, 'H' specifies the Offset above the mesh height to place the nozzle.
   *                    If omitted, Z_CLEARANCE_BETWEEN_PROBES will be used.
   *
   *   I #   Invalidate Invalidate the specified number of Mesh Points near the given 'X' 'Y'. If X or Y are omitted,
   *                    the nozzle location is used. If no 'I' value is given, only the point nearest to the location
   *                    is invalidated. Use 'T' to produce a map afterward. This command is useful to invalidate a
   *                    portion of the Mesh so it can be adjusted using other UBL tools. When attempting to invalidate
   *                    an isolated bad mesh point, the 'T' option shows the nozzle position in the Mesh with (#). You
   *                    can move the nozzle around and use this feature to select the center of the area (or cell) to
   *                    invalidate.
   *
   *   J #   Grid       Perform a Grid Based Leveling of the current Mesh using a grid with n points on a side.
   *                    Not specifying a grid size will invoke the 3-Point leveling function.
   *
   *   K #   Kompare    Kompare current Mesh with stored Mesh # replacing current Mesh with the result. This
   *                    command literally performs a diff between two Meshes.
   *
   *   L     Load       Load Mesh from the previously activated location in the EEPROM.
   *
   *   L #   Load       Load Mesh from the specified location in the EEPROM. Set this location as activated
   *                    for subsequent Load and Store operations.
   *
   *   The P or Phase commands are used for the bulk of the work to setup a Mesh. In general, your Mesh will
   *   start off being initialized with a G29 P0 or a G29 P1. Further refinement of the Mesh happens with
   *   each additional Phase that processes it.
   *
   *   P0    Phase 0    Zero Mesh Data and turn off the Mesh Compensation System. This reverts the
   *                    3D Printer to the same state it was in before the Unified Bed Leveling Compensation
   *                    was turned on. Setting the entire Mesh to Zero is a special case that allows
   *                    a subsequent G or T leveling operation for backward compatibility.
   *
   *   P1    Phase 1    Invalidate entire Mesh and continue with automatic generation of the Mesh data using
   *                    the Z-Probe. Usually the probe can't reach all areas that the nozzle can reach. On
   *                    Cartesian printers, points within the X_PROBE_OFFSET_FROM_EXTRUDER and Y_PROBE_OFFSET_FROM_EXTRUDER
   *                    area cannot be automatically probed. For Delta printers the area in which DELTA_PROBEABLE_RADIUS
   *                    and DELTA_PRINTABLE_RADIUS do not overlap will not be automatically probed.
   *
   *                    Unreachable points will be handled in Phase 2 and Phase 3.
   *
   *                    Use 'C' to leave the previous mesh intact and automatically probe needed points. This allows you
   *                    to invalidate parts of the Mesh but still use Automatic Probing.
   *
   *                    The 'X' and 'Y' parameters prioritize where to try and measure points. If omitted, the current
   *                    probe position is used.
   *
   *                    Use 'T' (Topology) to generate a report of mesh generation.
   *
   *                    P1 will suspend Mesh generation if the controller button is held down. Note that you may need
   *                    to press and hold the switch for several seconds if moves are underway.
   *
   *   P2    Phase 2    Probe unreachable points.
   *
   *                    Use 'H' to set the height between Mesh points. If omitted, Z_CLEARANCE_BETWEEN_PROBES is used.
   *                    Smaller values will be quicker. Move the nozzle down till it barely touches the bed. Make sure the
   *                    nozzle is clean and unobstructed. Use caution and move slowly. This can damage your printer!
   *                    (Uses SIZE_OF_LITTLE_RAISE mm if the nozzle is moving less than BIG_RAISE_NOT_NEEDED mm.)
   *
   *                    The 'H' value can be negative if the Mesh dips in a large area. Press and hold the
   *                    controller button to terminate the current Phase 2 command. You can then re-issue "G29 P 2"
   *                    with an 'H' parameter more suitable for the area you're manually probing. Note that the command
   *                    tries to start in a corner of the bed where movement will be predictable. Override the distance
   *                    calculation location with the X and Y parameters. You can print a Mesh Map (G29 T) to see where
   *                    the mesh is invalidated and where the nozzle needs to move to complete the command. Use 'C' to
   *                    indicate that the search should be based on the current position.
   *
   *                    The 'B' parameter for this command is described above. It places the manual probe subsystem into
   *                    Business Card mode where the thickness of a business card is measured and then used to accurately
   *                    set the nozzle height in all manual probing for the duration of the command. A Business card can
   *                    be used, but you'll get better results with a flexible Shim that doesn't compress. This makes it
   *                    easier to produce similar amounts of force and get more accurate measurements. Google if you're
   *                    not sure how to use a shim.
   *
   *                    The 'T' (Map) parameter helps track Mesh building progress.
   *
   *                    NOTE: P2 requires an LCD controller!
   *
   *   P3    Phase 3    Fill the unpopulated regions of the Mesh with a fixed value. There are two different paths to
   *                    go down:
   *
   *                    - If a 'C' constant is specified, the closest invalid mesh points to the nozzle will be filled,
   *                      and a repeat count can then also be specified with 'R'.
   *
   *                    - Leaving out 'C' invokes Smart Fill, which scans the mesh from the edges inward looking for
   *                      invalid mesh points. Adjacent points are used to determine the bed slope. If the bed is sloped
   *                      upward from the invalid point, it takes the value of the nearest point. If sloped downward, it's
   *                      replaced by a value that puts all three points in a line. This version of G29 P3 is a quick, easy
   *                      and (usually) safe way to populate unprobed mesh regions before continuing to G26 Mesh Validation
   *                      Pattern. Note that this populates the mesh with unverified values. Pay attention and use caution.
   *
   *   P4    Phase 4    Fine tune the Mesh. The Delta Mesh Compensation System assumes the existence of
   *                    an LCD Panel. It is possible to fine tune the mesh without an LCD Panel using
   *                    G42 and M421. See the UBL documentation for further details.
   *
   *                    Phase 4 is meant to be used with G26 Mesh Validation to fine tune the mesh by direct editing
   *                    of Mesh Points. Raise and lower points to fine tune the mesh until it gives consistently reliable
   *                    adhesion.
   *
   *                    P4 moves to the closest Mesh Point (and/or the given X Y), raises the nozzle above the mesh height
   *                    by the given 'H' offset (or default Z_CLEARANCE_BETWEEN_PROBES), and waits while the controller is
   *                    used to adjust the nozzle height. On click the displayed height is saved in the mesh.
   *
   *                    Start Phase 4 at a specific location with X and Y. Adjust a specific number of Mesh Points with
   *                    the 'R' (Repeat) parameter. (If 'R' is left out, the whole matrix is assumed.) This command can be
   *                    terminated early (e.g., after editing the area of interest) by pressing and holding the encoder button.
   *
   *                    The general form is G29 P4 [R points] [X position] [Y position]
   *
   *                    The H [offset] parameter is useful if a shim is used to fine-tune the mesh. For a 0.4mm shim the
   *                    command would be G29 P4 H0.4. The nozzle is moved to the shim height, you adjust height to the shim,
   *                    and on click the height minus the shim thickness will be saved in the mesh.
   *
   *                    !!Use with caution, as a very poor mesh could cause the nozzle to crash into the bed!!
   *
   *                    NOTE:  P4 is not available unless you have LCD support enabled!
   *
   *   P5    Phase 5    Find Mean Mesh Height and Standard Deviation. Typically, it is easier to use and
   *                    work with the Mesh if it is Mean Adjusted. You can specify a C parameter to
   *                    Correct the Mesh to a 0.00 Mean Height. Adding a C parameter will automatically
   *                    execute a G29 P6 C <mean height>.
   *
   *   P6    Phase 6    Shift Mesh height. The entire Mesh's height is adjusted by the height specified
   *                    with the C parameter. Being able to adjust the height of a Mesh is useful tool. It
   *                    can be used to compensate for poorly calibrated Z-Probes and other errors. Ideally,
   *                    you should have the Mesh adjusted for a Mean Height of 0.00 and the Z-Probe measuring
   *                    0.000 at the Z Home location.
   *
   *   Q     Test       Load specified Test Pattern to assist in checking correct operation of system. This
   *                    command is not anticipated to be of much value to the typical user. It is intended
   *                    for developers to help them verify correct operation of the Unified Bed Leveling System.
   *
   *   R #   Repeat     Repeat this command the specified number of times. If no number is specified the
   *                    command will be repeated GRID_MAX_POINTS_X * GRID_MAX_POINTS_Y times.
   *
   *   S     Store      Store the current Mesh in the Activated area of the EEPROM. It will also store the
   *                    current state of the Unified Bed Leveling system in the EEPROM.
   *
   *   S #   Store      Store the current Mesh at the specified location in EEPROM. Activate this location
   *                    for subsequent Load and Store operations. Valid storage slot numbers begin at 0 and
   *                    extend to a limit related to the available EEPROM storage.
   *
   *   S -1  Store      Store the current Mesh as a print out that is suitable to be feed back into the system
   *                    at a later date. The GCode output can be saved and later replayed by the host software
   *                    to reconstruct the current mesh on another machine.
   *
   *   T     Topology   Display the Mesh Map Topology.
   *                    'T' can be used alone (e.g., G29 T) or in combination with most of the other commands.
   *                    This option works with all Phase commands (e.g., G29 P4 R 5 T X 50 Y100 C -.1 O)
   *                    This parameter can also specify a Map Type. T0 (the default) is user-readable. T1 can
   *                    is suitable to paste into a spreadsheet for a 3D graph of the mesh.
   *
   *   U     Unlevel    Perform a probe of the outer perimeter to assist in physically leveling unlevel beds.
   *                    Only used for G29 P1 T U. This speeds up the probing of the edge of the bed. Useful
   *                    when the entire bed doesn't need to be probed because it will be adjusted.
   *
   *   V #   Verbosity  Set the verbosity level (0-4) for extra details. (Default 0)
   *
   *   W     What?      Display valuable Unified Bed Leveling System data.
   *
   *   X #              X Location for this command
   *
   *   Y #              Y Location for this command
   *
   *
   *   Release Notes:
   *   You MUST do M502, M500 to initialize the storage. Failure to do this will cause all
   *   kinds of problems. Enabling EEPROM Storage is highly recommended. With EEPROM Storage
   *   of the mesh, you are limited to 3-Point and Grid Leveling. (G29 P0 T and G29 P0 G
   *   respectively.)
   *
   *   When you do a G28 and then a G29 P1 to automatically build your first mesh, you are going to notice
   *   the Unified Bed Leveling probes points further and further away from the starting location. (The
   *   starting location defaults to the center of the bed.)   The original Grid and Mesh leveling used
   *   a Zig Zag pattern. The new pattern is better, especially for people with Delta printers. This
   *   allows you to get the center area of the Mesh populated (and edited) quicker. This allows you to
   *   perform a small print and check out your settings quicker. You do not need to populate the
   *   entire mesh to use it. (You don't want to spend a lot of time generating a mesh only to realize
   *   you don't have the resolution or zprobe_zoffset set correctly. The Mesh generation
   *   gathers points closest to where the nozzle is located unless you specify an (X,Y) coordinate pair.
   *
   *   The Unified Bed Leveling uses a lot of EEPROM storage to hold its data. And it takes some effort
   *   to get this Mesh data correct for a user's printer. We do not want this data destroyed as
   *   new versions of Marlin add or subtract to the items stored in EEPROM. So, for the benefit of
   *   the users, we store the Mesh data at the end of the EEPROM and do not keep it contiguous with the
   *   other data stored in the EEPROM. (For sure the developers are going to complain about this, but
   *   this is going to be helpful to the users!)
   *
   *   The foundation of this Bed Leveling System is built on Epatel's Mesh Bed Leveling code. A big
   *   'Thanks!' to him and the creators of 3-Point and Grid Based leveling. Combining their contributions
   *   we now have the functionality and features of all three systems combined.
   */

Need some good thinking on how to clean up the Z-Probe documentation

I know a fair amount about the Auto Bed Leveling. But, I was trying to bring up RC-5 and I flunked the test. I got confused by some of the things documented in the Configuration.h file. Admitably, I should have known better on some of the mistakes I made. And any thing I wasn't sure about I could have drilled down on the code and realized I was doing something stupid.

It took ThinkyHead explaining several philosophical points to get me pointed in the right direction. (The major point he made that helped clear my thinking was "If your electronics has a function labeled on the board, it is defined and called that in the pins.h file for the board." I was trying to bring up a Delta, and they always home towards Max. So, I didn't want (for safety reasons) to have a Z-Min defined.

Well... Just try to get your Z-Probe working without a Z-Min!

We need better documentation (Both in Configuration.h and the real Documentation) to help people get the Z-Probe configured properly for their printer. I'm proof of that need. If I can have trouble getting my Z-Probe working, for sure, other people are going to have trouble!

I don't pretend to know what the answer is. This whole Z-Probe topic is complicated by a million other factors. But I do know we need to help the users to guarantee they succeed!

If anybody has some good ideas on how to simplify this issue... This thread is for that purpose!

Consolidation of code for 1284p

I was wondering what all I can remove from code if I have very specific hardware? I am using a Melzi (Sanguino) board #63 with SD support, Heated bed, 1X, 1Y, 1Z, 1E, BLTouch and a RepRap Discount Full Graphics Display? I want to have all of the functions of the most current Marlin but a Jenny Craig version. Any and all help would be greatly appreciated!

TIA!

FYSETC v1.0 driver jumper configuration image confusion

The image http://marlinfw.org/assets/images/docs/hardware/tmc_drivers/FYSETC_tmc2130._SPI.jpg found on the page http://marlinfw.org/docs/hardware/tmc_drivers.html is confusing or perhaps wrong.

This is an image of the FYSETEC v1.0 driver, outlining its three jumpers and explaining how to set them for SPI mode. The problem is that one larger jumper is clearly closed but the label over it says open. The other two smaller jumpers are open but the label over them says closed! Which is it supposed to be?

Perhaps the image indicates how the driver comes from the factory and the labels indicate that all three jumpers need to be changed to the opposite of their factory settings to get SPI mode. This isn't very clear in the text. The text does say that the big jumper to the left of the chip needs to be opened but for the other two it just says that they need to be configured "as shown".

Assuming that what is meant is "open the big jumper which comes closed and close the two little jumpers that come open from the factory" then it would be much more clear if either the image showed the "after" picture instead of the "before" or if the text stated everything explicitly. "Open the big jumper and close the two little ones". As it is I think someone installing one of these drivers for the first time might be a little nervous from this ambiguity and be forced to go look up the datasheet before proceeding.

Switch to PlatformIO IDE for VSCode

Firstly, I want to say a big THANK YOU for using @platformio! I personally impressed with your multi-platform configuration https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/platformio.ini

We have a huge plan for PlatformIO Core 4.0. I hope that platformio/platformio-core#1643 will singnificnatly simplify platformio.ini.


We have recently announced the massive release of PlatformIO IDE for VSCode. We received great feedback!

Also, we droped Atom from our main page and now forward all people to PlatformIO IDE for VSCode. I would be thankful if someone could help with updating this documentation: http://marlinfw.org/docs/basics/install_platformio.html

I'm not expert in Marlin Firware but have just tried to use it with our latest version for VSCode and it is MUCH MUCH simpler than for Atom. What I did?

  1. Installed PlatformIO IDE for VSCode
  2. Switch to new PlatformIO View in Activity Bar (left side bar), then Quick Access > Clone Git Project ...
    screen shot 2018-09-10 at 19 38 16
  3. VSCode clonned whole repo and I received access to all branches and tags! Great! I tried different, bugfix-2.0x works great!
    screen shot 2018-09-10 at 19 39 51
  4. Then great addition to our extension for VSCode, that it has Project Task Explorer. Now, no need to edit platformio.ini and setup env_default, developers can work with multi-environments directly from IDE:
    screen shot 2018-09-10 at 19 41 12

Topics needing work

I'll keep filling this out as more ideas come up. There's a lot to do and we need help.

  • Configuration
  • Troubleshooting
    • Controllers
    • Compile Errors
    • MINTEMP/MAXTEMP Errors
  • Bed Leveling
    • Auto Bed Leveling
    • Manual Bed Leveling
  • GCode Commands

Auto-Build instructions?

I'm trying to set up to put Marlin 2.0 onto an SKR-V1.3 board, using PlatformIO (instructions at http://marlinfw.org/docs/basics/install_platformio.html) in Atom.
But running into problems at the "Build Marlin" section:
"Open the top level Marlin directory in PlatformIO.
Click on the “Auto Build” menu at the right end of the main menu bar to bring up the dialog.
"
Where is this "Auto Build" menu (or its Python script file for that matter)? I followed all instructions, but there's no such menu showing in my Atom/PlatformIO installation. What am I missing?
Can't find any reference to "Auto-Build" by searching the PlatformIO docs either. Been at this a while now..

Mixed content

When I enter the page using HTTPS, stylesheets and scripts fail to load because they are requested over HTTP.

SD Card Not working

I just flashed the latest Marlin 1.1.4 hoping to solve an issue I have since 1.1 . The sd card is not working right in my Viki. The Viki displays "No SC Card" but when selecting it I can see the files but not print them.
Repetier does show the files too. When trying to print, the SD LED blinks for a few seconds and goes out and nothing happens. Any suggestions?

Enhancement Request: K-factor Calibration Pattern

I'd like to see (at least) two simple text fields, one labeled Printer and one labeled Filament. These would just get copied into the generated G-code as comments near the top (next to the "; Created:" comment).

A third text field (labeled Filename) could be added (and used) so that multiple outputs could have meaningful names instead of all being named kfactor.gcode.

Code

Is there any Marlin code for Labview ?

Marlin Bootloader

I wanted to see if my experience as a creator of new controller was consistent with how the Marlin team think it should be, I designed a new controller using the LPC1768 and adopted the SKR v1.3 pinouts and because my MCU chips are from the manufactures they needed to be flashed with a suitable bootloader, for that I used the smoothieware precompiled binary and it worked to successfully change the FIRMWARE.BIN to FIRMWARE.CUR on the SD card with a Marlin 2.0 bugfix binary from the platform.io environment.

One thing that does not seem to be documented is the smoothieware bootloader part as that is assumed to come preloaded, is there an official "Marlin" bootloader or is the Smoothieware the way to go and should that be in the Documentation for installation? even as a side note.

how do I auto power e fans?

I have the auto power enabled but I don't use a ATX PSU.
I have my e fan connected to D11 but I can't figure out how to define it and make it auto work.
There is no definition for it in pin_Ramps.h that I see.
I can manually turn it on/off with M42.

[FR] Documentation on how to tune Junction Deviation

Hello! Just updated to the new 2.0 bugfix and so far looking good, movement seems smoother with s curve acceleration, adaptive step smoothing and all the misc fixes and improvements done to the planner!

One of the big features I wanted to try is junction deviation, but as soon as I was going to enable I noticed that I don't really know how to tune it. I've actually read through all discussions involving it here on the Marlin's git but practically I'm still not sure how to go about it.

From what I understood this are the key points:

*Max acceleration is used in the calculation (so default acceleration no longer has any effect?)
*The junction deviation value relates this Accel to the effects old jerk had

But how do I start? I guess I could use the defaults and go from there, but I'm not sure if I should lower Junction deviation value or acceleration if I find too much ringing, or even a starting point for my Max Accel. For example, I'm trying this on a tevo tornado, I use 500 printing Accel and 1000 travel Accel, 7 jerk for x and y. What values would be sensible to start with? How do I tune travel and printing Accel if there is only one single max Accel? I saw the formula relating max Accel and junction deviation value to old jerk, so I could do that to get a starting point with the default 0.02 junction deviation, but how do I go from there?

Edit: This is the most relevant comment for tuning this parameter I think: MarlinFirmware/Marlin#9917 (comment)
But after reading all I still can't help but feel like this guy: MarlinFirmware/Marlin#9917 (comment)

Thanks for the awesome work Marlin team, you're doing the world a great service!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.