This is the recommended approach for object initialization. The change
doesn't affect binary size (although in theory it could make it smaller).

Signed-off-by: Joseivaldo Benito Junior <jrbenito@benito.qsl.br>

Signed-off-by: Joseivaldo Benito Junior <jrbenito@benito.qsl.br>

This reverts commit b7eadb9f37.

if you try to enable Z_DUAL_STEPPER_DRIVERS the error "You cannot have dual drivers for both Y and Z" shows even if you don't have defined Y_DUAL_STEPPER_DRIVERS and don't let you compile the firmware

to solve this problem i change this line:

#ifdef Z_DUAL_STEPPER_DRIVERS && Y_DUAL_STEPPER_DRIVERS

to:

#if defined (Z_DUAL_STEPPER_DRIVERS) && defined (Y_DUAL_STEPPER_DRIVERS)

now the error only show if you define both Z_DUAL_STEPPER_DRIVERS and Y_DUAL_STEPPER_DRIVERS

The code for the LSQ solver (qr_solve) is copyrighted by John Burkardt and released under LGPL here:
http://people.sc.fsu.edu/~%20jburkardt/c_src/qr_solve/qr_solve.html
(see qr_solve.cpp for further copyright information)

Removed the calculation of the inverse matrix since the rotation matrix is orthogonal, therefore inverted == transposed.
Much simpler and mathematically robust.

In some cases the Bed Heater FET heats up more then stepper drivers, so
this change add the bed monitoring to the controller fan. As soon as the
bed heater is turned on, the controller fan will run as well.

Recommended for those who are using the Z Probe for Z Homing (as
Z-Endstop)

This feature has two changes:

1) Allow user to choose where the Z Probe will touch the bed when homing
all axis together (G28) by setting below defines:

Z_SAFE_HOMING_X_POINT
Z_SAFE_HOMING_Y_POINT

2) Prevents the user to perform Z Axis Homing when the Z Probe is
outsite bed.

In previous version, even with PWM = 127, the system turns the FET off
and then on in the next cycle. This bevavior may increase the FET heat
dissipation.
It was fixed keeping the FET always On when PWM=127.

This allows a hot end with two heaters and a FET for each heater. This is useful if the FET is not capable of heating two heaters.

Implemented M226 as described here:
http://reprap.org/wiki/G-code#M226:_Gcode_Initiated_Pause

Waits for pin to be become either HIGH, LOW or the inverse of what it
was before. Allows printing to pause until user interaction

start another print with suicide feature after a print without
suicide...

Added AT90USB device BT connectivity support using second UART.

I tested this and it works.

If only an LCD is defined and no menu or keyboard defined, there is a
compilation error.

Added conditional compilation.

Included support for BT dongle on AT90USB boards.
Added LCD Shift Register LCD control
Included support for RepRap Clone Wars project board (SAV MKI).

Allows the user to select wheter or not the PSU should be turned on or
kept in standby when marlin boots

since it can occure in comments.

If a print is stopped, it would be nice in the future to write a file with the printer state, the filename of the print, and the position within the print.
this file could be read, to continue a previously stopped print.
not finished yet.

by overloading M32 it is now possible to execute gcode files from other gcode files, with a fixed recursion level.
This can be used e.g. for having a real start.g and end.g somewhere on the sd card, which are then called from the normal print file.
Another usecase would be to have macro-files for nozzle-change and layerchange.
I have not tested the speedwise performance. The testing was done with pronterface.

syntax:
normal call from sd card will open the new file and continue executing there.
M32 !/path/filename#
this however will call the new file and return to the caller file.
M32 P !/path/filename#
with the optional "S<position>" the  file starting position can be set.
this is for continuing prints from a previous location.

if a '#' is read now the buffer will be emptied before reading ahead.
This is so one can execute files from within gcode files, without messing the buffer with preread characters from the caller file.
# can not occure in sd files imho, because it should only occure within checksums in ther serial communication.
Yes, thats a lame argument. If you have a better idea please tell me. It has to be a character that one can type
on a keyboard manually.

Hopefully fixed viky button handling without braking other boards

This reverts commit 314fd13c39.

- Added "Z_RAISE_BEFORE_HOMING" for raising Z the defined distance
before homing. This is useful to avoid Z-Probe collision when hotend is
near bed.

- Fixed the issue of Z not going bellow Z_PROBE_OFFSET when
"min_software_endstops" is true.
Now the Z_PROBE_OFFSET is not set in Z_MIN_POS, it is added after
homing.

If "SHOW_TEMP_ADC_VALUES" is defined in Configuration_adv.h, the M105
command will present, after tradicional temperatures, the ADC value read
from temp sensors. This is great for adjusting thermistor tables with
thermocouple.

From Pronterface you can see the ADC value and compare with a
thermocouple reading.. then you just need to create your own thermistor
table.

Since this merge doesnt change the original information, it doesnt mess
with PC software parsing (tested under Pronterface and Repetier-Host).

This is _not_ automatically the cronological, since deleting a file will free
the filesystem descriptor for it, which then will be used by the next file copied on it.
Since this makes the auto0.g file very inaccessible, I put the option back, to have it in the prepare menu.

this should satisfy https://github.com/ErikZalm/Marlin/pull/373

as a reminder, auto0.g will be executed every time after a boot with sd card present and file present.
thereafter, if there is a file auto1.g this will be done. Thats IMHO the best place to put settings, and prepare heating.
I also execute again after each (now again via the prepare menu) before starting a new print/ after a failed one.
It for me 100% replaces any start.gcode form the slicers.

also, removed some trouble for compilation with corexy.
I think that babystepping is only possible in z for a delta tower.
not sure if it would be usefull to step individual motors on a delta, i don't own one

I strongly vote for it being a single gcode, because otherwise the triggering from the menu is terrible.

It is a realtime control over the head position via the LCD menu system that works _while_ printing.
Using it, one can e.g. tune the z-position in realtime, while printing the first layer.
Also, lost steps can be manually added/removed, but thats not the prime feature.
Stuff is placed into the Tune->Babystep *

It is not possible to have realtime control via gcode sending due to the buffering, so I did not include a gcode yet. However, it could be added, but it movements will not be realtime then.

Historically, a very similar thing was implemented for the "Kaamermaker" project, while Joris was babysitting his offspring, hence the name.

say goodby to fuddling around with the z-axis.

Check the Readme for instruction how to enable and configure the feature