It’s really stopping that’s the hardest
I’m able to print in 3mm PLA, finally. I’m not able to print in 1.75mm PLA without jamming unless I crank the volume up to 11, er, 111%. My best explanation for the latter is a mix of slightly-off pulley diameter with that size of PLA mixed and that it simply provides more pressure. Even at 111% it jams, it just takes an hour.
Nick Starno said…
Nick told me that he believes that acceleration of the filament to speed would work better than going directly to full power. I don’t know if he was speaking of this particular problem, but I think it’s a valid idea.
Also, I had some skipping because I set the feed-rate on bridges to 2*40mm/s. I really don’t think that that should be a problem.
As you can see from the image at the top of this post I’ve been doodling. I haven’t tried any of this yet, but here it goes.
Setup
- Acceleration and deceleration are set independently and for each axis. They will be measured in mm/s/s. That can and probably will be translated to steps/s/s (in ReplicatorG, at least).
- Direction doesn’t matter except for when switching directions, which means stopping first.
- At all times the movement of all axes is to be synchronized.
Rules
- Acceleration happens after a point that sets the speed.
- The speed being accelerated to does not have to be achieved.
- Deceleration happens before the point that sets the speed.
- The speed being decelerated to must be achieved.
- Switching directions implies a stop at the set-point that first goes the opposite direction.
- All of the steps required to reach a set-point must be completed.
Implementation
TBD.
I plan on using the command queue to look ahead and determine the points where deceleration must start. I suspect I may have to implement a minimum speed that applies only to acceleration so that it doesn’t take all day to get moving from a dead stop.
What do you think?
-Rob
Each path has a beginning and an end. Each path's beginning mm/s (velocity) ~ 0 mm/s. Each path's beginning mm/s/s (acceleration - acc.) ~ 0 mm/s/s. When graphed the ideal path will not be linear as in your sketch but sinusoidal or since widely varying it would be made curvilinear. Thus, every path will have a start where acceleration (acc.) increases to the maximum at the apex of the path where acc. is zero then deceleration to the end of the path where acc. is zero.
ReplyDeletePick a nice curve equation with harmonic frequency and wavelength. Generate a relationship for the period and amplitude. Then apply to the current draw/supply to the motor based on this relationship. Is this maximizing the use of PWM?
This would make the motors general speed vary at all times where longer moves had higher velocities (mm/s) and accelerations (mm/s/s) and small moves would be slower. But, all moves would have a gentle stop and return. This would immensely decrease machine vibrations, noise, part shake off, print detail anomalies.
I disagree. Most moves are continuations of a line of extrusion, pick a minimum speed (say, 30mm/s) that the machine can handle with acceptable stress. Then simply look at the duration of the move and spend half accelerating and half decelerating. Top speed is merely a limiting value, not a target. You may also want to implement a 'dead zone' at the ends of the line where acceleration doesn't happen. That would both allow things to stabilize on the new vector before acceleration begins, but also set a threshold that drops acceleration from being used on super tiny mover where all its really doing is over complicating the GCode.
ReplyDeleteI plan on implementing this completely in firmware, so that the gcode will be unchanged. This also matches the acceleration/deceleration profile capabilities of the Motate128 chipset.
ReplyDeleteBAS:
The lines I drew are for acceleration rate. The actual speed would end up being a sinusoidal curve, yes.
To explain further:
Each step is timed. The timing between each step will either increase, stay the same, or decrease at each step. I drew this. In reality the timing decreasing also means that the next decrease will happen sooner, etc, so the speed will indeed end up making a curve.
In software it feels more like what I drew: increase speed each step until step X, maintain speed until step Y, decrease speed until step Z.
I don't like the idea of handling each line segment independently. If you stop or slow down between line segments on an object that is mostly curves (broken into line segments, of course) then you will mostly be going the minimum speed. Instead I feel that it should go the maximum speed that it can handle given enertia, etc. When it leaves one segment and enters another it should only slow down as much as it needs to to handle the change of angle or anticipated need to stop or reverse directions. (That's why I look ahead as many segments as I need to.)
Ideally the speed will always be set to 10,000 in skeinforge (etc.) and the bot will either go as fast as it can without skipping or intentionally slow down (in Gcode) in order for something to cool or for some other reason that's not enertia or motor torque.