Quotedc42 The only significant approximation that RepRapFirmware does for Cartesian, CoreXY and Delta machines is to approximate smooth motion by individual microsteps - we don't use Bresenham. the algorithm the planner uses usually dissects each movement into an accel phase, near constant velocity and deccel phase at least. this has nothing to do with bresenham. i am talking about this: //by xor_ea_ebx - Controllers
should be discusses elsewhere. we lost focus on the threads topic. doesn't sound it irrational/unlogical to you that your toolpath generator doesn't know about the used tool? i would say something is definitely wrong. each movement is split into accel / decel / linear approximated segments any way. so whats the problem there? a good planner "joins" these segments an ideally makes a smooth motionby xor_ea_ebx - Controllers
dc42, yes of course. but ir latency was just one of my "concerns". i do not like the added complexity during (initial) development. so step rates are not everything. proper motion planning (no not trapezoidal 2nd order / constant accel) using e.g. S-curves might be even more important. from this viewpoint the main difference between marlin and klipper, reprapfirmware is RRF&klipper are not usby xor_ea_ebx - Controllers
from the linked article: "Another problem with ARM processors is the severe 12-cycle interrupt latency. When coupled with the large number of registers that are saved and restored in the prologue and epilogue of the ISR handlers, these cycles start to add up. ISR latency is one area where a 16 MHz 8-bit part can easily beat a 72 MHz 32-bit Arm microcontroller." from the arm reference manual: doby xor_ea_ebx - Controllers
sorry dc42, i disagree. there are alternative firmwares available for 8bit controllers which allow high speed and smooth movements. e.g. there are at least teacup (which using a Gen7 board is also 32bit capable and below 40$ i guess -- if you like isolation milled boards) and klipper. what i think, and probably the creator of klipper, the path planning should happen on a compute host. i.e. a raby xor_ea_ebx - Controllers
sieht das druckbild nicht wie eine instanz von z-wobble durch beheiztes bett im bang-bang modus aus? vgl.: Building the C-Bot 3d Printer : Part 38 : PID Autotune on RepRap Firmware, fix z-artifactsby xor_ea_ebx - Allgemeines
i can't comment on autotune because my dyzendx with 500C thermistor and 60W heater did not work this way. had to find suitable values manually. my hotend fan starts automatically when temp is >60. i use the following config: M307 H1 A500.0 C200.0 D5.0 B0 S0.8 M305 P0 T100000 B4719 R4700 L0 H0 M305 P1 T4700000 B5253 R4700 H0 L0 M106 P1 S1 I0 F500 H1 T60 ; hotend fan on when temp >60by xor_ea_ebx - Controllers
you are right the problems with 1/128 and 0.9 steppers where at travel speeds set to 300mm/s. the 1/32 works flawlessly for >2weeks almost continous printing (i tested the previous radds versions as well). print speed usually at 100-120mm/s and travel 300mm/s. steps/mm roughly 226.by xor_ea_ebx - Controllers
i can confirm the current/official RADDS port works very well (i'm using it on a cartesian printer). I use RAPS128 @ 1/32 and 0.9 steppers. with 1/128 microstepping i had performance issues. i plan to use different drivers anyway so this is not a big deal for me. thanks @dc42 for doing the extra work!by xor_ea_ebx - Controllers