› ›

DEV2: DIR signal at low speed

karl_ranseierkarl_ranseier
in General
Hi,
I observed with my oscilloscope, that the DIR signal is not a DC value for small movements. There is just an area around the step signal. I fully understand that this is enough. But in fact this is just another operation which may consume some time.
Would't is make sense to change the value of DIR only when there is a change in direction?

Just a thought. There is no need for me to change that. It took me some time to understand that and now I want to share it.

If this is not interesting, feel free to ignore or delete this post.

Comments

  • RepetierRepetier
    > I observed with my oscilloscope, that the DIR signal is not a DC value for small movements. 
    What does not a DC value mean for someone without electronic background?

    You are right that with SLOW_DIRECTION_CHANGE 1 there is a interrupt pause in step signals when direction changes or a new move is started. I think it would be good to remove the new move part. I could force setting old directions every time when a driver is switched. So it only happens if any of the xyze axes change direction. Also often it is the case anyway for a circle it will happen only 4 times. So still a gain and minimal timing improvement.
  • karl_ranseierkarl_ranseier
    edited October 2020
    Sorry.
    DC= direct/constant current (or voltage)
    AC= alternating current (or voltage)
     Normally AC is for +/- current, so therefore I used a wrong term.

    Here I meant with "not DC" a "not constant" voltage, so an alternating voltage between 0 and 3.3 or 5V for each step!

    Upper line is DIR-signal, lower line is STEP-signal. The dir signal alternates between 3.3 and 0V (upper part is 3.3 V). It is only set to the desired value around the step-signal. For the other direction it is not changed and therefore constant.

    I did not know the "slow direction change" option. What means slow? Is there a value which I can read from the datasheet of the driver? Would be nice to comment on this in the configuration.h. Like: "if your driver needs more than x µs to react on a dir-change, you should set this to 1, e.g. DRV... needs y µs"

    So it makes absolutely sense to make this dir signal a constant value, if this is for SLOW drivers.

  • RepetierRepetier
    SLOW_DIRECTION_CHANGE 1 makes a timer interrupt call pause = 1/STEPPER_FREQUENCY seconds. This is for drivers that don't see the changed direction when step follows very quickly. The drivers datasheet normally has a timing diagram on required times.


    Your step/dir image makes me a bit nervous if it would not already work. But we only set dir pin when it changes to new value while steps are set and unset at next interrupt call. Or did I see multiple direction changes in that image? But will test soon with my logic analyser.


  • AbsoluteCatalystAbsoluteCatalyst
    edited October 2020
    I was curious and wanted to see this too. These are my results
    (I don't have slow direction changed enabled btw)

    https://tinyurl.com/y4c49b5r
    My step pin is on the top, dir on the bottom.

    It happens during interpolated moves/direction changes/corners.
    https://tinyurl.com/y3ynkj5y

    Here's the short capture if you happen to use saleae's Logic 2 app or (anything that can open these): 
    https://drive.google.com/file/d/1jU0PkJ8GWlr0MIOuOH7GXg20ARW1emsr/view?usp=sharing ;

    I once actually saw this a while back when I was debugging timer frequencies.
    Uh, somehow it never came across me that that dir "fade" might not be normal until now, haha. 
  • karl_ranseierkarl_ranseier
    Repetier said:
    SLOW_DIRECTION_CHANGE 1 makes a timer interrupt call pause = 1/STEPPER_FREQUENCY seconds. This is for drivers that don't see the changed direction when step follows very quickly. The drivers datasheet normally has a timing diagram on required times.


    Your step/dir image makes me a bit nervous if it would not already work. But we only set dir pin when it changes to new value while steps are set and unset at next interrupt call. Or did I see multiple direction changes in that image? But will test soon with my logic analyser.



    I am sorry, the image was taken BEFORE your changes.
  • karl_ranseierkarl_ranseier
    AbsoluteCatalyst said:

    It happens during interpolated moves/direction changes/corners.
    https://tinyurl.com/y3ynkj5y

    I think it always happens, but if the steps are very close to each other, it is still in the other state and one does not see it. The areas are overlapping.

  • karl_ranseierkarl_ranseier
    edited October 2020
    I checked wit the version downloaded some minutes ago, but it still looks like this:

  • RepetierRepetier
    Just tested with my due + RADDS board. Made a 5 mm move right then left and measured X axis. Result is this:

    https://imgur.com/a/3hu1JPL

    you see I have no spikes/switches for dir here. This is even with SLOW_DIRECTION_CHANGE 1

    @AbsoluteCatalyst
    You have same behaviour left and right and different in a intermediate area. What were the move commands you used to measure this for? Also could not access the logic file - it is private. Wanted to check closely if the dir changes are same time as steps or not. And also when does dir get set back - seems somewhere between steps. Maybe a stepper interrupt without step contained. So far a bit mysterious.
  • AbsoluteCatalystAbsoluteCatalyst
    https://drive.google.com/file/d/1jU0PkJ8GWlr0MIOuOH7GXg20ARW1emsr/view?usp=drivesdk
    Sorry about that, file should be public now
    I'll do another test today soon too
    the command I used was
    G1 X150 F500000
    (just maxed out speed)
  • RepetierRepetier
    I think I may have solved this one. lastDirection was never stored so any direction would match changed. Not so much an issue if there are not some special cases where we send usedAxes=0 with dummy directions. No need to copy them as well. 

    Actually there might even the case that by chance some steps not counted would get executed.

    With this fix it seems fixed at least where I saw some toggling previously I now don't see them any more. Hope this is in your test case as well. I had a hard time with my timings to get these special condition.
  • AbsoluteCatalystAbsoluteCatalyst
    Can't reproduce it any longer. Looks like that was it! Thanks.

    Interesting, I wonder if it was creating any strange artifacts or vibrations in prints.
    Can't see any though, coming from my main Due machine.

    I hadn't run the analyzer on my Due, but my newer mini V2 which seemed to have it happen every time I made a direction change unlike your RADDs. Odd.
  • RepetierRepetier
    The bad effect was that it set directions on every new 1/BLOCK_FREQUENCY second long block. With slow directions enabled that means 1/BLOCK_FREQUENCY extra delay between them. That was when you had no dir switching. When you are moving slow enough to get no virtual step at all you would have had direction=0 which is what we actually saw. So in any case it should now be smoother and print maybe 1% faster depending on the settings. It should not have caused wrong motions.
  • karl_ranseierkarl_ranseier
    I can confirm that it is removed now. Level of dir is constant low or high for both directions
Sign In or Register to comment.