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
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.
Enables two stepper drivers to be used for the Y axis (useful for
Shapeoko style machines)
Each Y driver can be stepped in either the same way or in opposite
directions, accounting for different hardware setups (leadscrew vs. belt
driven)
Enables two stepper drivers to be used for the Y axis (useful for
Shapeoko style machines)
Each Y driver can be stepped either the same way or in opposite
directions, accounting for different hardware setups (leadscrew vs. belt
driven)
Bug introduced in version 6beb42cdf6.
Robert did a good job of simplifying but messed up this chunk of code.
Looking at working version: 839bef6d5d
it seems there is no case where encrot3 should be defined as 2
because if ULTICONTROLLER is defined then NEWPANEL is also defined.
bkubicek