reformatting
This commit is contained in:
		
							parent
							
								
									11a42c3215
								
							
						
					
					
						commit
						c98d87935a
					
				| @ -1,6 +1,4 @@ | ||||
| 
 | ||||
| Features: | ||||
| ========= | ||||
| # Features | ||||
| 
 | ||||
| *   Interrupt based movement with real linear acceleration | ||||
| *   High steprate | ||||
| @ -19,12 +17,12 @@ Features: | ||||
| *   Arc support | ||||
| *   Temperature oversampling | ||||
| *   Dynamic Temperature setpointing aka "AutoTemp" | ||||
| *   Support for QTMarlin, a very beta GUI for PID-tuning and velocity-acceleration testing. https://github.com/bkubicek/QTMarlin | ||||
| *   Support for [QTMarlin](https://github.com/bkubicek/QTMarlin), a very beta GUI for PID-tuning and velocity-acceleration testing.  | ||||
| *   Endstop trigger reporting to the host software. | ||||
| *   Updated sdcardlib | ||||
| *   Heater power reporting. Useful for PID monitoring. | ||||
| *   PID tuning | ||||
| *   CoreXY kinematics (www.corexy.com/theory.html) | ||||
| *   [CoreXY kinematics](www.corexy.com/theory.html) | ||||
| *   Delta kinematics | ||||
| *   SCARA kinematics | ||||
| *   Dual X-carriage support for multiple extruder systems | ||||
| @ -36,12 +34,9 @@ Features: | ||||
| 
 | ||||
| The default baudrate is 250000. This baudrate has less jitter and hence errors than the usual 115200 baud, but is less supported by drivers and host-environments. | ||||
| 
 | ||||
| ## Differences and additions to the already good Sprinter firmware | ||||
| 
 | ||||
| Differences and additions to the already good Sprinter firmware: | ||||
| ================================================================ | ||||
| 
 | ||||
| Look-ahead: | ||||
| ----------- | ||||
| ### Look-ahead | ||||
| 
 | ||||
| Marlin has look-ahead. While sprinter has to break and re-accelerate at each corner, | ||||
| lookahead will only decelerate and accelerate to a velocity, | ||||
| @ -49,21 +44,18 @@ so that the change in vectorial velocity magnitude is less than the xy_jerk_velo | ||||
| This is only possible, if some future moves are already processed, hence the name. | ||||
| It leads to less over-deposition at corners, especially at flat angles. | ||||
| 
 | ||||
| Arc support: | ||||
| ------------ | ||||
| ### Arc support | ||||
| 
 | ||||
| Slic3r can find curves that, although broken into segments, were ment to describe an arc. | ||||
| Marlin is able to print those arcs. The advantage is the firmware can choose the resolution, | ||||
| and can perform the arc with nearly constant velocity, resulting in a nice finish. | ||||
| Also, less serial communication is needed. | ||||
| 
 | ||||
| Temperature Oversampling: | ||||
| ------------------------- | ||||
| ### Temperature Oversampling | ||||
| 
 | ||||
| To reduce noise and make the PID-differential term more useful, 16 ADC conversion results are averaged. | ||||
| 
 | ||||
| AutoTemp: | ||||
| --------- | ||||
| ### AutoTemp | ||||
| 
 | ||||
| If your gcode contains a wide spread of extruder velocities, or you realtime change the building speed, the temperature should be changed accordingly. | ||||
| Usually, higher speed requires higher temperature. | ||||
| @ -76,42 +68,36 @@ The wanted temperature then will be set to t=tempmin+factor*maxerate, while bein | ||||
| If the target temperature is set manually or by gcode to a value less then tempmin, it will be kept without change. | ||||
| Ideally, your gcode can be completely free of temperature controls, apart from a M109 S T F in the start.gcode, and a M109 S0 in the end.gcode. | ||||
| 
 | ||||
| EEPROM: | ||||
| ------- | ||||
| ### EEPROM | ||||
| 
 | ||||
| If you know your PID values, the acceleration and max-velocities of your unique machine, you can set them, and finally store them in the EEPROM. | ||||
| After each reboot, it will magically load them from EEPROM, independent what your Configuration.h says. | ||||
| 
 | ||||
| LCD Menu: | ||||
| --------- | ||||
| ### LCD Menu | ||||
| 
 | ||||
| If your hardware supports it, you can build yourself a LCD-CardReader+Click+encoder combination. It will enable you to realtime tune temperatures, | ||||
| accelerations, velocities, flow rates, select and print files from the SD card, preheat, disable the steppers, and do other fancy stuff. | ||||
| One working hardware is documented here: http://www.thingiverse.com/thing:12663 | ||||
| Also, with just a 20x4 or 16x2 display, useful data is shown. | ||||
| 
 | ||||
| SD card folders: | ||||
| ---------------- | ||||
| ### SD card directories | ||||
| 
 | ||||
| If you have an SD card reader attached to your controller, also folders work now. Listing the files in pronterface will show "/path/subpath/file.g". | ||||
| You can write to file in a subfolder by specifying a similar text using small letters in the path. | ||||
| Also, backup copies of various operating systems are hidden, as well as files not ending with ".g". | ||||
| 
 | ||||
| SD card folders: | ||||
| ---------------- | ||||
| ### Autostart | ||||
| 
 | ||||
| If you place a file auto[0-9].g into the root of the sd card, it will be automatically executed if you boot the printer. The same file will be executed by selecting "Autostart" from the menu. | ||||
| First *0 will be performed, than *1 and so on. That way, you can heat up or even print automatically without user interaction. | ||||
| 
 | ||||
| Endstop trigger reporting: | ||||
| -------------------------- | ||||
| ### Endstop trigger reporting | ||||
| 
 | ||||
| If an endstop is hit while moving towards the endstop, the location at which the firmware thinks that the endstop was triggered is outputed on the serial port. | ||||
| This is useful, because the user gets a warning message. | ||||
| However, also tools like QTMarlin can use this for finding acceptable combinations of velocity+acceleration. | ||||
| 
 | ||||
| Coding paradigm: | ||||
| ---------------- | ||||
| ### Coding paradigm | ||||
| 
 | ||||
| Not relevant from a user side, but Marlin was split into thematic junks, and has tried to partially enforced private variables. | ||||
| This is intended to make it clearer, what interacts which what, and leads to a higher level of modularization. | ||||
| @ -121,8 +107,7 @@ In the serial communication, a #define based level of abstraction was enforced, | ||||
| some transfer is information (usually beginning with "echo:"), an error "error:", or just normal protocol, | ||||
| necessary for backwards compatibility. | ||||
| 
 | ||||
| Interrupt based temperature measurements: | ||||
| ----------------------------------------- | ||||
| ### Interrupt based temperature measurements | ||||
| 
 | ||||
| An interrupt is used to manage ADC conversions, and enforce checking for critical temperatures. | ||||
| This leads to less blocking in the heater management routine. | ||||
|  | ||||
		Loading…
	
	
			
			x
			
			
		
	
		Reference in New Issue
	
	Block a user