4axis into edge #5
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ontop of the edge planner examples run byte for byte identical old and new version
New planner commits merge into dev branch.
the stepper interrupt is only halted when necessary and for the shortest time possible (8% cycle time)
integrating soft limits
- Changed up mc_line to accept an array rather than individual x,y,z coordinates. Makes some of the position data handling more effective, especially for a 4th-axis later on. - Changed up some soft limits variable names.
…Line overflow feedback. - Increased g-code parser line buffer to 70 characters (from 50) to prevent some long arc commands from getting truncated. - Decreased planner buffer from 18 to 17 blocks to free up memory for line buffer. - Added a line buffer overflow feedback error (Thanks @BHSPitMonkey!)
- **NON-FUNCTIONAL** - Contains an old draft of separating the stepper driver direct access to the planner buffer. This is designed to keep the stepper and planner modules independent and prevent overwriting or other complications. In this way, feedrate override should be able to be installed as well. - A number of planner optimizations are installed too. - Not sure where the bugs are. Either in the new planner optimizations, new stepper module updates, or in both. Or it just could be that the Arduino AVR is choking with the new things it has to do.
… things still broken with overhaul. Development push. Lots still broken. - Protected planner concept works! This is a critical precursor to enabling feedrate overrides in allowing the planner buffer and the stepper execution operate atomically. This is done through a intermediary segment buffer. - Still lots of work to be done, as this was a complete overhaul of the planner and stepper subsystems. The code can be cleaned up quite a bit, re-enabling some of the broken features like feed holds, and finishing up some of the concepts - Pushed some of the fixes from the master and edge branch to here, as this will likely replace the edge branch when done.
- New stepper algorithm with the new optimized planner seems to be working nearly twice as fast as the previous algorithm. - For one, the planner computation overhead is probably a fraction of what it used to be with the worst case being about half still. - Secondly, anytime the planner plans back to the first executing block, it no longer overwrites the block conditions and allows it to complete without lost steps. So no matter if the streams slows, the protected planner should keep the steppers moving without risk of lost steps (although this still needs to be tested thoroughly and may audibly sound weird when this happens.) - It now seems that the bottleneck is the serial baudrate (which is good!)
… step prediction for segment buffer. - Cleaned up the new stepper algorithm code with more commenting and better logic flow. - The new segment buffer now predicts the number of steps each segment should have to execute over about 8 milliseconds each (based on the ACCELERATION_TICKS_PER_SECOND setting). So, for when the whole segment buffer is full, the stepper algorithm has roughly 40 milliseconds of steps queued before it needs to refilled by the main program. - Readjusted the max supported step rate back to 30kHz from the lower development 20kHz. Everything still works amazing great and the test CNC machine still runs twice as fast with the new stepper algorithm and planner. - Upped the standard serial baudrate to 115200 baud, as it is clear that the bottleneck is the serial interface. Will now support this, as well as the old 9600 baud, in new firmware builds.
- Added some compile-time error checking. Will add more in future pushes to ensure settings are correct and within parameters that won't break anything. - Pushed some master branch changes with MEGA pin settings. - Cleaned up planner code and comments to clarify some of the new changes. Still much to do here. - Cleaned up the new stepper code. May need to abstract some of the segment buffer more to fix the feed holds (and integrate homing into the main stepper routine). With what's planned, this should make the stepper algorithm easier to attach other types of processes to it, where it is now tightly integrated with the planner buffer and nothing else.
…dable. Added step locking note. - Updated config comments and stepper code comments for the new changes. - Changed stepper algorithm variable names to be more understandable in what they actually do. - Added a stepper lock note in default.h per user request. - Started some code layout in handling feed holds and refactoring the homing routine to use the main stepper algorithm instead of a seperate version.
Conflicts: README.md gcode.c motion_control.c planner.c planner.h protocol.c report.c settings.c settings.h stepper.c stepper.h
Conflicts: README.md gcode.c motion_control.c planner.c planner.h protocol.c report.c settings.c settings.h stepper.c stepper.h
- Overhauled the stepper algorithm and planner again. This time concentrating on the decoupling of the stepper ISR completely. It is now dumb, relying on the segment generator to provide the number of steps to execute and how fast it needs to go. This freed up lots of memory as well because it made a lot tracked variables obsolete. - The segment generator now computes the velocity profile of the executing planner block on the fly in floating point math, instead of allowing the stepper algorithm to govern accelerations in the previous code. What this accomplishes is the ability and framework to (somewhat) easily install a different physics model for generating a velocity profile, i.e. s-curves. - Made some more planner enhancements and increased efficiency a bit. - The changes also did not increase the compiled size of Grbl, but decreased it slightly as well. - Cleaned up a lot of the commenting. - Still much to do, but this push works and still is missing feedholds (coming next.)
…raft, but working. - Reinstated the feed hold feature with the new stepper algorithm and new optimized planner. It works, but will be re-factored a bit soon to clean up the code. - At this point, feedrate overrides may need to be installed in the v1.0 version of grbl, while this version will likely be pushed to the edge branch soon and pushed to master after the bugs have been squashed. - Measured the overall performance of the new planner and stepper algorithm on an oscilloscope. The new planner is about 4x faster than before, where it is completing a plan in around 1ms. The stepper algorithm itself is minutely faster, as it is a little lighter. The trade-off in the increased planner performance comes from the new step segment buffer. However, even in the worse case scenario, the step segment buffer generates a new segment with a typical 0.2 ms, and the worse case is 1ms upon a new block or replanning the active block. Added altogether, it’s argubly still twice as efficient as the old one.
… Cleaned up codebase. - Pushed limit switch active high option (i.e. NC switches). - Updated defaults.h to be in-line with the new settings. - Refactored feed hold handling and step segment buffer to be more generalized in effort to make adding feedrate overrides easier in the future. Also made it a little more clean. - Fixed G18 plane select issue. Now ZX-plane, rather than XZ-plane, per right hand rule. - Cleaned some of the system settings by more accurately renaming some of the variables and removing old obsolete ones. - Declared serial.c rx_buffer_tail to be volatile. No effect, since avr-gcc automatically does this during compilation. Helps with porting when using other compilers. - Updated version number to v0.9b. - Updates to README.md
- A minor issue with deceleration ramps when close to zero velocity. Should be virtually unnoticeable for most CNC systems, but fixed in this push and accurate to physics. - Updated some of the junction deviation defaults. Because the new stepper algorithm can easily maximize a CNC machine’s capabilities or simply go much faster, this means the speed in which it enters junctions has to be a little more constrained. Meaning that, we have to slow a little bit down more so that we don’t exceed the acceleration limits of the stepper motors.
…fo. Refactored config.h. - Revamped and improved homing cycle. Now tied directly into the main planner and stepper code, which enables much faster homing seek rates. Also dropped the compiled flash size by almost 1KB, meaning 1KB more for other features. - Refactored config.h. Removed obsolete defines and configuration options. Moved lots of “advanced” options into the advanced area of the file. - Updated defaults.h with the new homing cycle. Also updated the Sherline 5400 defaults and added the ShapeOko2 defaults per user submissions. - Fixed a bug where the individual axes limits on velocity and acceleration were not working correctly. Caused by abs() returning a int, rather than a float. Corrected with fabs(). Duh. - Added build version/date to the Grbl welcome message to help indicate which version a user is operating on. - Max travel settings were not being defaulted into the settings EEPROM correctly. Fixed. - To stop a single axis during a multi-axes homing move, the stepper algorithm now has a simple axis lock mask which inhibits the desired axes from moving. Meaning, if one of the limit switches engages before the other, we stop that one axes and keep moving the other.
Added the use of homing_dir_mask to homing_cycle
- Minor bug fix that caused G92.1 not to work. The mantissa of G92.1 was not computed correctly due to floating point round-off errors and the use of trunc(). Fixed it by changing the computation with round(). - Installed tool length offsets with G43.1 and G49! True tool length offsets via G43 are not supported, because these require us to store tool data that we don’t have space for. But we’ve come up with a good solution for users that need this. Instead we are strictly using the dynamic version G43.1 via linuxcnc.org. Visit their website for more details on the command. - G43.1 operates by requiring an axis word and value to offset the configured tool length axis, which can be configured for any axis (default Z-axis) in config.h. For example, ```G43.1 Z0.5``` will offset the work coordinates from Z0.0 to Z-0.5. - G49 will cancel the last tool length offset value and reset it to zero. - Tweaked the ‘$#’ parameters report. `Probe` is now `PRB` and a new value `TLO` states the tool length offset value.
- Whoops! Missed a bracket and it wasn’t compiling. Now fixed. - Updated the unsupported gcodes listed at the end of the gcode.c file.
Resolved Conflicts: config.h gcode.c gcode.h motion_control.c nuts_bolts.c nuts_bolts.h probe.c report.c settings.c settings.h sim/simulator.c
Resolved Conflicts: gcode.c limits.c motion_control.c probe.c settings.h
$E for encoder reading $S for system status
…gger gcode buffer.
Conflicts: Makefile config.h sim/serial.c sim/simulator.c sim/simulator.h
ashelly
pushed a commit
that referenced
this pull request
May 21, 2015
Improve support for encoders and home repeatability testing.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.