[BUG] The parameter dir does not change, checked by oscilloscope

[sky4fly]

There was a problem with the displacement of the layers.

Reason detected

Experiments were conducted during which it became clear that the parameter dir does not change with the change.

1. Dir changed in configuration_adv.h
2. We tried to change dir in stepper.spp

In the pictures below you can see that dir with different parameters is the same!
From above it is dir. Bottom is step.

Dir values do not change.

Testing was on the arduino due and mks sbase 1.3 control boards.

What are your thoughts on this?

[p3p]

It's not clear from the post what configuration parameters you change can you edit the post and add some more context, labelling the traces with exactly what you changed for each image?

[sky4fly]

The // # define function MINIMUM_STEPPER_DIR_DELAY does not work properly. Everything was checked by oscilloscope. I tried to set a delay per minute. But he does not react to it. Because of this, the x displacements appeared on the leadshine em705 driver.

And you know what I did?

I installed the rep rap Frimware to DUE. It all worked with her. I checked the values ​​with an oscilloscope and everything was fine.

569 P0 S1 T10: 10: 50: 50

On marlin it is useless.
I also tried to put the dir value in stepper.cpp
 DELAY_US (50); wherever it occurs, but it did not help
 
// # if MINIMUM_STEPPER_DIR_DELAY> 0
DELAY_US (50);
// # endif

Please check this parameter MINIMUM_STEPPER_DIR_DELAY. I would like to stay on marlin.

thank

[Sineos]

Related to #12403?

[Bob-the-Kuhn]

MINIMUM_STEPPER_DIR_DELAY is measured from when DIR changes to the start of the next STEP pulse.

I can't tell from your timing displays what this is. Could you add a table of specified delay vs. measured delay?

[Bob-the-Kuhn]

I couldn't find a problem. Below is a capture with
#define MINIMUM_STEPPER_DIR_DELAY 50000000 // 50,000,000

This one is with it set to 500,000

I added a OUT_WRITE(15,1); before the delay routine and OUT_WRITE(15,0); after the routine so that it would be visible on the logic analyzer.

The delay routine tracked fairly well with the count:

 specified     measured
     50,000       52,440
    500,000      502,500
  5,000,000    5,003,000
 50,000,000   50,010,000
500,000,000       39,830   exceeded 32 bit capacity

My jerk settings resulted in about a 1.5mS initial step spacing so the effect of the delay wasn't seen until it exceeded 1,500,000.

This is with Marlin 2.0 on a DUE + RAMPS_FD_V1 with no changes to the default configuration except as stated above.

[sky4fly]

At the moment of changing the dir signal, an extra step impulse occurs. This can be seen even on the basis of your diagrams.

This step step is a terminating pulse, i.e. last one.

Suppose if you set 44 pulses per 1 mm axis displacement. Then this extra step will appear on the 44th impulse when the DIR signal changes

How to remove this extra momentum step.

I repeat.
In the firmware reprap firmware everything works.
In marlin, this pulse is fatal.

thank

[AnHardt]

So you are asking for a new delay?
We already have MINIMUM_STEPPER_DIR_DELAY - waiting this time after a change of dir before the next step pulse.
You are asking for: wait this time after a step pulse before dir can change?

[maukcc]

So, is that last pulse part of the move or is that generated by the directional change?
Either way it seems that the time between the end of the pulse and the directional change is always equal.

We have to assume that the timing to the directional change is planned (and changeble). In the below example you can see a little pause where it waits for the directional change.

In more powerfull drivers the time between last pulse and directional change will be too short and a directional change will happen while the driver is still discharging(motor is still moving). This is generating the "missed" steps

[InsanityAutomation]

@maukcc @rusnob Can you record the same trace on RRF so we can see the dwell between the last step and dir change there? Im curious if it echoes the duration value, or uses a different variable.

Also, did anyone ever confirm is that "extra step" an erroneous step, or is it simply the last step from the processed block? Reading through the above statements, Its unclear.

[Roxy-3D]

@maukcc @rusnob

Also, did anyone ever confirm is that "extra step" an erroneous step, or is it simply the last step from the processed block? Reading through the above statements, Its unclear.

It would be extremely helpful to know exactly where that extra step pulse is being generated in the code. I would do it myself, but I do not have an oscilloscope that can catch that kind of glitch.

Can we put an extra channel of the scope on some unused GPIO pin and toggle the pin high... do the instruction (or lines of code --- Very possibly inside a macro) that are generating the extra step pulse, and then toggle the pin low just so we can confirm EXACTLY where that pulse is being generated?

That extra step pulse glitch is very concerning! If I knew which line of code as causing it, it would be easier to try to understand why it is being generated. I'm wondering if it is something like the Step Pulse pin is being (needlessly) set to be an output pin (when it already is an output). Or maybe some neighboring pin on the same 8-bit port that the Step Pulse pin is on is being setup in a different mode? I don't know... But knowing which line of code in the firmware is causing that pulse to be generated would help get us much closer to resolving this.

I'm very concerned about that extra step pulse because it would seem that can cause positional errors. We don't want the stepper motors getting 'extra' pulses!

[AnHardt]

I looked this up in July. It is not an extra step. It is the last step of a block. If there is a next block this is prepared, in the same interrupt call the previous block ends. Including setup directions.

#13559 (comment)

A simple question. Yes or No?

[Roxy-3D]

Thank You @AnHardt !

Knowing that it is just the last step pulse and not an extra step pulse is very helpful!

A simple question. Yes or No?

Yes. I'm thinking we may want to add a small, experimental delay to give more control of the spacing between the last step pulse and the direction change. I'm not actually saying we should add any more control right now. But I don't think #define MINIMUM_STEPPER_DIR_DELAY gives us enough control. So, I'm wondering if adding a little bit of time around that step pulse and the change of direction might help us. And a little bit of time after the direction change before the first step pulse. (That is two separate time periods. Not one!)

Do you have any thoughts or recommendations on how to proceed?

[InsanityAutomation]

Im going to add this to src/module/Stepper.cpp line 352

#if MINIMUM_STEPPER_DIR_DELAY > 0
  DELAY_NS(MINIMUM_STEPPER_DIR_DELAY);
#endif

Then I will have the same delay before and after. Then ill run the same gcode we were using as a layer shift torture test. This will ensure we do delay an amount of time after the last step before changing directions.

If it looks good to me, maybe we can add a config value for MINIMUM_STEPPER_IDLE_DIR_DELAY or something to ensure its been idle that long prior to triggering the change.

[Roxy-3D]

If this can get rid of the random layer shifts.... We need it merged ASAP.

[maukcc]

It seems to print straight now, we will do more testing.
To be honest we do not now if it comes from this commit or because we changed the pulse direction with #define INVERT_X_STEP_PIN true

[boelle]

@rusnob tested this recently?

[sky4fly]

@rusnob tested this recently?

good afternoon

I have not checked this recently.

Tell me what has changed during this time.

The problem is dir or step signal delay. There are no such problems in the rrf firmware, and there are two (2) timing (delay) settings for dir and step signals. In marlin firmware, only 1 value for dir and step.

I am not an expert in this topic. Tell me better what has changed in the firmware during this time. Not really so difficult to solve. Many people have a problem.

About my problem. Thank.

[boelle]

you need to download latest 2.0.x and test again, we cant keep an eye on every single commit that goes in to 2.0.x

[sky4fly]

I think then you need to close this question.

I am currently printing on the duet board.

If in the future, I will build a large printer with super-fast drivers, then I will check the marlin on it.

thank

[InsanityAutomation]

For those concerned, there is now a pre/post delay that is configurable. I submitted this a few weeks ago and results so far seem good.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.