Closed Macgyver001 closed 7 years ago
Sounds like a possible bug! Between myself and @Sebastianv650 we should be able to figure it out…
If the problem is also there if K=0 then it should be something with the extruder ISR. This is the only big change when LIN_ADVANCE is enabled. I had a short look on your config, the values look quite strange to me:
#define DEFAULT_AXIS_STEPS_PER_UNIT {320,320,800,386} // default steps per unit for Ultimaker
#define DEFAULT_MAX_FEEDRATE {500, 500, 2, 50} // (mm/sec)
#define DEFAULT_MAX_ACCELERATION {60,60,200,500} // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for Skeinforge 40+, for older versions raise them a lot. was 75
#define DEFAULT_ACCELERATION 60 // X, Y, Z and E acceleration in mm/s^2 for printing moves
#define DEFAULT_RETRACT_ACCELERATION 300 // E acceleration in mm/s^2 for retracts
#define DEFAULT_TRAVEL_ACCELERATION 80 // X, Y, Z acceleration in mm/s^2 for travel (non printing) moves
// The speed change that does not require acceleration (i.e. the software might assume it can be done instantaneously)
#define DEFAULT_XYJERK 500.0 // (mm/sec) was 20 was 700
#define DEFAULT_ZJERK 0.4 // (mm/sec)
#define DEFAULT_EJERK 50.0
Why do you use so incredible high jerk values combined with ultra-low acceleration values? I can't imagine this can work..! Do you ever printed good things with theese values?
Hi thanks for the quick response.
The jerk settings are not aligned very carefully so thank you for your comment. I have lowered a lot of values one by one, but without any result, no extruding when Lin_advance is enable, final settings are listed below:
#define DEFAULT_AXIS_STEPS_PER_UNIT {320,320,800,100} // default steps per unit for Ultimaker 160*2,160*2,800,((200*64)*1.0/(10.56*3.14159))=386
#define DEFAULT_MAX_FEEDRATE {200, 200, 2, 10} // (mm/sec)
#define DEFAULT_MAX_ACCELERATION {60,60,100,10} // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for Skeinforge 40+, for older versions raise them a lot. was 75 e=500
#define DEFAULT_ACCELERATION 10 // X, Y, Z and E acceleration in mm/s^2 for printing moves
#define DEFAULT_RETRACT_ACCELERATION 10 // E acceleration in mm/s^2 for retracts
#define DEFAULT_TRAVEL_ACCELERATION 80 // X, Y, Z acceleration in mm/s^2 for travel (non printing) moves
// The speed change that does not require acceleration (i.e. the software might assume it can be done instantaneously)
#define DEFAULT_XYJERK 5.0 // (mm/sec) was 20 was 500
#define DEFAULT_ZJERK 0.4 // (mm/sec)
#define DEFAULT_EJERK 2.0 // (mm/sec) 5.0 was 2000
Is there something changed in the extruder stepper motor signals when using Lin_advance? I have connected my ramps 1.4 via self made wiring towards my stepper drivers m542T (but as I mentioned I do not change connections Lin_advance disabled or enabled and it works when I disable Lin_advance)
I recommend you keep testing daily with RCBugFix
as we keep fixing things by mistake. This will also allow us to insert some debugging code to help track the issue – something we would generally only do with the working branch.
No, LIN_ADVANCE
isn't changing anything in the way the stepper is electrically driven. The only difference is the timing, when enabled the extruder has its own ISR.
I would start with common configuration values and see what happens. For example, maybe a value can overflow with an acceleration of only 10mm/s². Therefore, I would set all acceleration values to 500 and test again.
If a simple extruder-only move (for example G1 E3 F50
) isn't working with enabled advance, I would check the wiring or other values in the basic config. There is no reason I can think of why such a command should fail due to LIN_ADVANCE
.
@Sebastianv650 Well, you will want to look through the LIN_ADVANCE
code and make sure nothing got broken since it was first integrated. So far it looks okay, but my eye is not likely to be as keen.
Possibly this? 2/4 phase Nema 23 Stepper Motor Driver 24-50VDC 1.5A-4.5A 256 Microstep M542T|M542T|Stepper Motor Drivers http://www.omc-stepperonline.com/24-phase-nema-23-stepper-motor-driver-2450vdc-15a45a-256-microstep-m542t-p-293.html
For reliable response, pulse width should be longer than 1.5μs.
Extruder working fine with A4988s, not with DRV8825, repetier works, marlin not · Issue #975 · MarlinFirmware/Marlin https://github.com/MarlinFirmware/Marlin/issues/975#issuecomment-47515225
From Pololu's site:
With the DRV8825, the high and low STEP pulses must each be at least 1.9 us; they can be as short as 1 us when using the A4988.
@To see the Repetier-Firmware, Additional delay is added in here and there (STEPPER_HIGH_DELAY
and DOUBLE_STEP_DELAY
) for stepper driver that it needs long pulse.
Hello all,
Today I checked the enable signal on my stepper driver, that seems to work fine and is not the issue I also tried the acceleration = 500 and jerk 50 but that also did not help. It could be related to pulse width? Is there an option to change that in the code. I will check if I can find anything related to pulse with in the data sheet of the m542 driver?
With a jerk of 50, you may end up with such high speed changes that the extruder can't keep up with the pressure adjustment moves. Extruder only moves shouldn't be affected by LIN_ADVANCE
, but I will have a look at the latest Marlin code after my holidays in about 2 weeks.
Ok, but last time I tested with jerk of 2! I checked the timing of the step pulse and its indeed 1.5 us up and down and 5 us after a direction switch, I don't know what the current timing is, and if its shorter than that?
Thanks for checking, I will also go on holiday, so lets catch up after..
@esenapaj Do the Marlin settings CONFIG_STEPPERS_TOSHIBA
and MAX_STEP_FREQUENCY
seem to be equivalent to the repetier delay options?
No, it isn't.
It looks like that CONFIG_STEPPERS_TOSHIBA
of Marlin suppress the MAX_STEP_FREQUENCY
simply, and disable double / quad stepping mode automatically.
In case of STEPPER_HIGH_DELAY
and DOUBLE_STEP_DELAY
of Repetier-Firmware,
those add additional delay to section of stepper.
For example, they add additional delay to A, B, C.
Maybe those lines of Marlin are A, B, C.
And, Marlin decide threshold value between single and double stepping automatically.
In case of Repetier-Firmware, threshold value between single and double stepping is configurable (STEP_DOUBLER_FREQUENCY
).
@thinkyhead does this make a bell ring ? :-D
I'm too shy to start messing with the stepper code at this junction.
Hi all,
I have tried to reduce MAX_STEP_FREQUENCY to 10000, but without any result. Is there a dirty way to add a delay in only the Extruder stepper, for testing purposes? If this is the correct direction. In the older version of marlin from April 2016 I enabled the 128 u stepping, this gives me a resolution of 640 steps/mm and Extruder 772 steps/mm, at 20mm/s the processor is still capable of running this setup.
Is there a dirty way to add a delay in only the Extruder stepper, for testing purposes? If this is the correct direction.
Can you explain in a little more detail what you are thinking and why this would be beneficial? I need to understand the problem a little better.
But the reason I'm asking for more detail is this: Right now I'm messing with the mesh_buffer_line() routine to make it non-recursive (to lighten the CPU load). On any given Planner request, it would not be difficult to stagger when an axis moves relative to the other axis.
Hi Roxy,
The problem is that when I enable Lin_advance my extruder stepper does not work. In the documentation of my external stepper controller it is stated that the steps (digital signals) should not be shorter than 1.5 u seconds. Therefore I would like to enlarge the timing of a high / low signal of only the extruder (or all stepper signals if necessary) (nothing else), to investigate if this is the problem. When I disable LIn_advance everything is working correctly. The XYZ axis are working fine in all occasions.
Try if https://github.com/MarlinFirmware/Marlin/pull/4738/files#diff-20025b9ffe01efeb4272ee752f32170dR712 helps.
@Blue-Marlin Is the overhead of invoking interrupts very large, I wonder? I was thinking that the advance ISR could start the pulse(s) for E, and instead of sitting and waiting, it could instead set up an interrupt to stop the pulse(s) (soon) and exit right away. Perhaps the same approach is possible with the main stepper ISR.
This would allow them both to exit sooner and give time back to the main thread. But if the overhead of interrupts is significant, then this might actually lead to more cycles being used up, or if other interrupts might block the pulse-stopping interrupt, then pulses might not be stopped soon enough.
There's also the notion of not using any timer-based interrupts at all, but instead just always set up the next single-fire interrupt that's needed, and use a persistent shared state so that each of these tasks can be much smaller slices of the whole stepping procedure.
I might have seen something like that in ether grbl or RepetierFirmware. On the other hand i had a look into Prusa-Firmware today, where they not even have the interleave
counter_x += current_block->steps_x;
if (counter_x > 0) {
WRITE(X_STEP_PIN, !INVERT_X_STEP_PIN);
counter_x -= current_block->step_event_count;
count_position[X_AXIS]+=count_direction[X_AXIS];
WRITE(X_STEP_PIN, INVERT_X_STEP_PIN);
}
But with supporting only 2-3 defined boards they pretty well know what timing to expect. (And they kicked Advance at all.)
not be shorter than 1.5 u seconds. That is ~24 ticks. With only one extruder in the loop this could be a bordercase, especially with the old
STEP_E_ONCE(INDEX)
. (Have not really counted cycles.)
@Macgyver001 asked for a delay - there it is. But in reality i do not believe there is one needed. Let' see if it helps.
had a look into Prusa-Firmware today, where they not even have the interleave
Hmm! I've wondered if possibly some of these stepper drivers are smartly leaving the pulse on for the duration needed, even though it's been turned off very quickly. I suppose we can query that with an oscilloscope.
Meanwhile, apparently Prusa Research has employed fixed-point maths where performance matters. I've been thinking about that a lot also.
I still try to find out what they have really done. The forks are pretty far apart from each other. For now i was mostly interested what they have done with the new bed and the inductive sensor. Really interesting.
Comments like
//FIXME This routine is called 15x every time a new line is added to the planner,
// therefore it is a bottle neck and it shall be rewritten into a Fixed Point arithmetics,
// if the CPU is found lacking computational power.
do look more like a plan than like a done.
Searching the interwebs turns up a lot of discussion about pulse widths, decay time, etc. Lately I'm extra-interested in the topic because I'm not sure I'm a fan of DRV8825 for the current application. The SCARA machine I'm writing code for is currently set up to use 100:1 harmonic drives on the A/B axes, which means if using 32x micro-stepping, we need 1778 pulses per degree to move the steppers (which results in ~7mm per degree in the most extreme case, but only half of that per linkage).
Or in other words, total overkill in terms of movement accuracy. Even at 16x microstepping it amounts to 889 pulses per degree. When we start having this many pulses the bugs and errors start to get a bit weird. Imagine also, this is all on a Mega2560 platform, so again, really pushing the limits unnecessarily. I'm inclined to drop down even as low as 8x microstepping, but wondering how much extra sound that will produce.
In the end, I may have no choice but to either go with far lower microstepping or insist that we switch to 25:1 harmonic drives, just so the Mega can keep up.
Hey guys,
@Macgyver001 asked for a delay - there it is. But in reality i do not believe there is one needed. Let' see if it helps.
I am sorry, but I am quite new in C, so Blue Marlin I don't know what I have to change where? I downloaded the latest RC bugfix but I don't know where to find STEP_E_ONCE(INDEX). Unfortunately I don't have a oscilloscope else I would have checked it. Advance and Lin_advance are both not extruding when one off them is enabled. including the use of CONFIG_STEPPERS_TOSHIBA to limit the frequency.
Thinkyhead, I have changed my drivers for m542T because they run smoother and I had some resonance problems. My CoreXY is quite stiff (ridgid) and I have better looking prints with higher mirco-stepping. If you like I can show the difference between lets say 16 and 128 (mirco stepping), I need some time for that? My latest Treefrog is really nice except some small artifacts I hope to resolve with Lin_advance, and the Lin_advance concept is way smarter than the normal implementation, that's why I like to enable Lin_advance.
@Macgyver001 Did you test with MINIMUM_STEPPER_PULSE
set around 9 or 10? With only a single extruder, the advance ISR makes extremely short pulses.
Thanks thinkyhead, I now tested this option Minimum stepper pulse. Started with 10 it worked, but marlin did not response well after. Went down to 1 and the extruder is reacting, I have to see if my marlin configurables are correct and see if everything is working well. Something went NOK with my G28 homing, Z was not responding correctly. This MINIMUM_STEPPER_PULSE accepts only integers? For now this Minimum_stepper_Pulse is doing the Job for me, I can start testing with LIN_ADVANCE.
Nice. I will Keep you updated.
This
MINIMUM_STEPPER_PULSE
accepts only integers?
It does. If you want to reduce the time it may accrue, you can strip off individual 1/16ths of a µs by increasing the value of CYCLES_EATEN_BY_CODE
and/or CYCLES_EATEN_BY_E
which are "hidden" in stepper.cpp
.
@Sebastianv650 It looks like we need to add a small delay into the advance ISR to get a long enough pulse. If a stepper pulse needs to be 9 or 10µs long, then it should do something like this…
void Stepper::advance_isr() {
old_OCR0A += eISR_Rate;
OCR0A = old_OCR0A;
#define SET_E_STEP_DIR(INDEX) \
E## INDEX ##_DIR_WRITE(e_steps[INDEX] <= 0 ? INVERT_E## INDEX ##_DIR : !INVERT_E## INDEX ##_DIR)
#define START_E_PULSE(INDEX) \
if (e_steps[INDEX]) E## INDEX ##_STEP_WRITE(INVERT_E_STEP_PIN)
#define STOP_E_PULSE(INDEX) \
if (e_steps[INDEX]) { \
e_steps[INDEX] <= 0 ? ++e_steps[INDEX] : --e_steps[INDEX]; \
E## INDEX ##_STEP_WRITE(!INVERT_E_STEP_PIN); \
}
SET_E_STEP_DIR(0);
#if E_STEPPERS > 1
SET_E_STEP_DIR(1);
#if E_STEPPERS > 2
SET_E_STEP_DIR(2);
#if E_STEPPERS > 3
SET_E_STEP_DIR(3);
#endif
#endif
#endif
// Step all E steppers that have steps
for (uint8_t i = 0; i < step_loops; i++) {
START_E_PULSE(0);
#if E_STEPPERS > 1
START_E_PULSE(1);
#if E_STEPPERS > 2
START_E_PULSE(2);
#if E_STEPPERS > 3
START_E_PULSE(3);
#endif
#endif
#endif
// For a minimum pulse time wait before stopping pulses
#if MINIMUM_STEPPER_PULSE > 0
#define CYCLES_EATEN_BY_E_CODE 10
#define ADDED_DELAY (MINIMUM_STEPPER_PULSE) * (F_CPU / 1000000UL) - 20 * (E_STEPPERS - 1) - CYCLES_EATEN_BY_E_CODE
#if ADDED_DELAY > 0
static uint32_t pulse_start;
pulse_start = TCNT0;
while ((uint32_t)(TCNT0 - pulse_start) < (uint32_t)(ADDED_DELAY)) { /* nada */ }
#endif
#endif
STOP_E_PULSE(0);
#if E_STEPPERS > 1
STOP_E_PULSE(1);
#if E_STEPPERS > 2
STOP_E_PULSE(2);
#if E_STEPPERS > 3
STOP_E_PULSE(3);
#endif
#endif
#endif
}
}
I obtained oscilloscope in this month and now I'm observing stepping pulses, I found direction signal of LIN_ADVANCE
(and ADVANCE
)is broken.
Yellow: direction signal
Cyan: stepping pulse
Magenta: enable signal
#define XYZ_FULL_STEPS_PER_ROTATION 400 // original is 200
#define E_FULL_STEPS_PER_ROTATION 1024 // 5.18 : 1 geared // original is 200
#define XYZ_MICROSTEPS 8
#define E_MICROSTEPS 8
#define XYZ_BELT_PITCH 2
#define XYZ_PULLEY_TEETH 16
#define E_GEAR_EFFECTIVE_DIAMETER 10.94 // Bondtech QR: Effective diameter : 10.94mm?
#define XYZ_STEPS (double(XYZ_FULL_STEPS_PER_ROTATION) * XYZ_MICROSTEPS / (XYZ_BELT_PITCH * XYZ_PULLEY_TEETH))
#define E_STEPS (double(E_FULL_STEPS_PER_ROTATION) * E_MICROSTEPS / (E_GEAR_EFFECTIVE_DIAMETER * M_PI))
LIN_ADVANCE
g1 e10 f10 |
g1 e100 f1200 (this was taken in microstep = 16, sorry) |
---|---|
This problem had been also occurred in my 32bit branch,
but when I change the Stepper::old_OCR0A
and Stepper::eISR_Rate
from unsigned char
to uint32_t
and down a threshold of double-stepping, problem was solved roughly.
But in case of official 8bit Marlin, even if I change the old_OCR0A
and eISR_Rate
to unsigned int
or unsigned long
, problem isn't solved.
and, I awaken stepper pulse of ADVANCE
and LIN_ADVANCE
are inverted for some reason.
g1 e100 f1200
normal | ADVANCE |
---|---|
Also: Is the pulse duration in advance_isr
too short? There is no added delay, and with only a single E stepper, this might cause some issue.
But your report is interesting, because the stepper direction is definitely being set there:
SET_E_STEP_DIR(0);
#if E_STEPPERS > 1
SET_E_STEP_DIR(1);
#if E_STEPPERS > 2
SET_E_STEP_DIR(2);
#if E_STEPPERS > 3
SET_E_STEP_DIR(3);
#endif
#endif
#endif
I can see a couple possible changes that may help. Try this…
In the Stepper::set_directions()
method change:
#if DISABLED(ADVANCE)
if (motor_direction(E_AXIS)) {
REV_E_DIR();
count_direction[E_AXIS] = -1;
}
else {
NORM_E_DIR();
count_direction[E_AXIS] = 1;
}
#endif //!ADVANCE
…so it always sets the direction for E, even with regular ADVANCE
enabled…
if (motor_direction(E_AXIS)) {
REV_E_DIR();
count_direction[E_AXIS] = -1;
}
else {
NORM_E_DIR();
count_direction[E_AXIS] = 1;
}
That doesn't affect LIN_ADVANCE
, only regular ADVANCE
. I can't see why ADVANCE
would want to do it any differently. As long as the two ISRs are properly synchronizing, there should be no need to wait until the advance_isr
to set E stepper directions. Maybe –just maybe– the concern is that advance_isr
may not be done at the point where the new block is starting. In which case, maybe this needs to be skipped for both types of advance extrusion.
The other change to make, along with the one above, is: In Stepper::advance_isr()
drop the code that sets the E direction by removing this:
#define SET_E_STEP_DIR(INDEX) \
E## INDEX ##_DIR_WRITE(e_steps[INDEX] <= 0 ? INVERT_E## INDEX ##_DIR : !INVERT_E## INDEX ##_DIR)
…and this…
SET_E_STEP_DIR(0);
#if E_STEPPERS > 1
SET_E_STEP_DIR(1);
#if E_STEPPERS > 2
SET_E_STEP_DIR(2);
#if E_STEPPERS > 3
SET_E_STEP_DIR(3);
#endif
#endif
#endif
According to my reading of the code, either one or the other of these should be kept, but not both. If anything should be fixed, it is that the E stepper directions should only be set once, when initializing the advance_isr
for a new block, and not within the ISR itself.
One other thing, maybe…
#if ENABLED(LIN_ADVANCE)
- volatile int Stepper::e_steps[E_STEPPERS];
+ volatile long Stepper::e_steps[E_STEPPERS];
Allowing more than 32,767 E steps. Probably needed for long straight lines when using high microstepping.
About ADVANCE
:
- #if DISABLED(ADVANCE) if (motor_direction(E_AXIS)) { REV_E_DIR(); count_direction[E_AXIS] = -1; } else { NORM_E_DIR(); count_direction[E_AXIS] = 1; } - #endif //!ADVANCE
It seems that this is a precise fixing. Direction signal works rightly. (but stepper signal is still inverted)
g1 e100 f1200 |
g1 e100 f3000 |
---|---|
About LIN_ADVANCE
:
-#define SET_E_STEP_DIR(INDEX) \ - E## INDEX ##_DIR_WRITE(e_steps[INDEX] <= 0 ? INVERT_E## INDEX ##_DIR : !INVERT_E## INDEX ##_DIR)
-SET_E_STEP_DIR(0); -#if E_STEPPERS > 1 - SET_E_STEP_DIR(1); - #if E_STEPPERS > 2 - SET_E_STEP_DIR(2); - #if E_STEPPERS > 3 - SET_E_STEP_DIR(3); - #endif - #endif -#endif
It seems that these are precise fixing, too. (but stepper signal is still inverted, too.)
g1 e100 f1200 |
g1 e100 f3000 |
---|---|
About pulse width and period:
Is the pulse duration in advance_isr too short?
In case of ADVANCED
and LIN_ADVANCED
and no added any delays,
HIGH (but inverted) pulse width is 1.6 ~ 1.8μs, LOW pulse width on multi-stepping mode is under 1μs, pulse period is 2.6μs (≒ 384.61KHz).
From datasheets, A4988 and A5984 needs 1μs HIGH/LOW pulse width at least, DRV8824, DRV8825, and DRV8834 needs 1.9μs HIGH/LOW pulse width at least, and 250KHz (4μs) step frequency(pulse period)is maximum. DRV8880 needs 470ns HIGH/LOW pulse width at least, and 1MHz (1μs) step frequency(pulse period) is maximum. TMC2100 needs 120ns HIGH/LOW pulse width at least. About THB6128(RAPS128), I don’t get it... (needs 40ns HIGH/LOW pulse width at least?)
About LIN_ADVANCE
part2:
#if ENABLED(LIN_ADVANCE) - volatile int Stepper::e_steps[E_STEPPERS]; + volatile long Stepper::e_steps[E_STEPPERS];
I saw strange phenomenon.
When I changed the e_steps[]
from volatile int
to volatile long
,
HIGH pulse width grew to 3μs, LOW pulse width on multi-stepping mode grew to 1.4μs, pulse period grew to 4.4μs (≒ 227.27KHz) for some reason...
g1 e100 f1200 |
g1 e100 f3000 |
---|---|
Allowing more than 32,767 E steps.
2,147,450,880?
This is my misunderstanding, sorry.
A branch that it's being used for test: https://github.com/esenapaj/Marlin/tree/testes
About inverted stepper signal:
It seems that it's simple bug. In advance_isr()
,
#define START_E_PULSE(INDEX) \
- if (e_steps[INDEX]) E## INDEX ##_STEP_WRITE(INVERT_E_STEP_PIN)
+ if (e_steps[INDEX]) E## INDEX ##_STEP_WRITE(!INVERT_E_STEP_PIN)
#define STOP_E_PULSE(INDEX) \
if (e_steps[INDEX]) { \
e_steps[INDEX] <= 0 ? ++e_steps[INDEX] : --e_steps[INDEX]; \
- E## INDEX ##_STEP_WRITE(!INVERT_E_STEP_PIN); \
+ E## INDEX ##_STEP_WRITE(INVERT_E_STEP_PIN); \
}
Results looks like good.
g1 e100 f3000
ADVANCE |
LIN_ADVANCE |
---|---|
Good sleuthing! One of us should make a PR soon!
Oscilloscopes FTW!
When I changed the e_steps[] from volatile int to volatile long, HIGH pulse width grew to 3μs, LOW pulse width on multi-stepping mode grew to 1.4μs, pulse period grew to 4.4μs (≒ 227.27KHz) for some reason
I'm guessing long
takes long
'er to process. But this is probably a good thing. Pulse widths are probably too small. I think 8-9µs is considered best.
Very good sleuthing indeed. What is the theoretical effect of these issues when running with LIN_ADVANCE and these bugs not fixed?
Theoretically, erratic behavior.
I submitted a PR.
But, maybe more research and improvements are needed.
About pulse width:
g1 e100 f3000
Normal (not advance algorithms ) | ADVANCE |
LIN_ADVANCE |
---|---|---|
Normal | ADVANCE |
LIN_ADVANCE |
|
---|---|---|---|
HIGH pulse width (μs) | 6.7 | 1.81 | 3.0 |
LOW pulse width (μs) | 13.1 | 1.31 | 1.38 |
Pulse period (μs) | 19.8 | 3.12 | 4.38 |
minimum requirements specification | DRV8825 | M542T |
---|---|---|
HIGH pulse width (μs) | 1.9 | 1.5 |
LOW pulse width (μs) | 1.9 | 1.5 |
Pulse period (μs) | 4.0 | 3.0? |
Marlin can adjust HIGH pulse width by MINIMUM_STEPPER_PULSE
, but hasn't solution for changing LOW pulse width.
About between enable signal (EN) and direction signal (DIR), between direction signal and stepping signal (STP):
minimum requirements specification | DRV8825 | M542T |
---|---|---|
EN - DIR (μs) | 0.65 | > 5 |
DIR - STP (μs) | 0.65 | > 5 |
But maybe anyone hasn't grasped at this time that how much Marlin has those.
About limitation of ISR frequency of ADVANCE
and LIN_ADVANCE
:
I'm seeing that "dead zone" exists in transition of stepping rate with 5.18 : 1 geared extruder at 32 micro-stepping (Bondtech QR, about 950steps / mm).
In case of LIN_ADVANCE
, When I order g1 e100 f600
(single-stepping), pulse timing fall into disorder, subsequently, Marlin freeze completely.
Green LED flash repeatedly, watchdog and reset button on RAMPS doesn't work. It needs complete power off.
But when I order g1 e100 f630
(double-stepping), it looks like stable.
I'm still researching now.
LIN_ADVANCE
g1 e100 f600 |
g1 e100 f630 |
---|---|
I'm guessing long takes long'er to process.
It appears so. This is benchmark program that it was ported from Arduino Playground - ShowInfo
In case of MEGA2560, calculation of long
is x 1.99 ~ x 4.58 slower than calculation of int
.
# Really great all that hard work. I will try LIN_ADVANCE part2:
#if ENABLED(LIN_ADVANCE)
- volatile int Stepper::e_steps[E_STEPPERS];
+ volatile long Stepper::e_steps[E_STEPPERS];
About inverted stepper signal:
It seems that it's simple bug. In advance_isr()
,
#define START_E_PULSE(INDEX) \
- if (e_steps[INDEX]) E## INDEX ##_STEP_WRITE(INVERT_E_STEP_PIN)
+ if (e_steps[INDEX]) E## INDEX ##_STEP_WRITE(!INVERT_E_STEP_PIN)
#define STOP_E_PULSE(INDEX) \
if (e_steps[INDEX]) { \
e_steps[INDEX] <= 0 ? ++e_steps[INDEX] : --e_steps[INDEX]; \
- E## INDEX ##_STEP_WRITE(!INVERT_E_STEP_PIN); \
+ E## INDEX ##_STEP_WRITE(INVERT_E_STEP_PIN); \
To see if that's working more stable ( without the : MINIMUM_STEPPER_PULSE = 0 )
To see if that's working more stable ( without the : MINIMUM_STEPPER_PULSE = 0 )
I finally tried MINIMUM_STEPPER_PULSE
recently (in general) and it made the steppers sluggish. But in my case the machine has 100:1 harmonic gears on some axes, so probably it just can't afford any extra delay.
This is benchmark program
That is some very useful info. Perhaps it can be timed with all interrupts (temporarily) disabled, using TCNT0
(or another hardware counter) instead of millis
to get completely accurate values.
Great research!! I'm realy sad I still have no time to contribute in this topic (even my printer wasn't running the last months) but I definitly must so some tests with the merged PR :)
Thanks to everyone here :+1:
@thinkyhead is #4852 already landed/merged in the RCBugFix branch? I can't find it back in the stepper.cpp file?
PR #4852 (Fix for advance extrusion algorithms) was merged to RCBugFix branch.
Configuration_and_adv.zip
Problem: When I enable Lin_advance my extruder motor does not turn/extrude. What Have I tried to do.
Turn off core XY, but still no extruding K factor put to 0 no effect Tried to lower the extrusion speed no effect Extruding in reverse is also not working When disable watchdog does not help
When I disable Lin_advance it extrudes well.