Marlin and THB6128 Driver

[leseaw]

Hi,

i have an problem with this. Moves are all fine. in print, it puts the tracks in order 1-2mm direction Endstop. Where is my mistake? The driver to fast for marlin? I print with 60mm/s. Or is there a setting for it somewhere?

Thanks for an answer.

[Tommy-LSA]

No, because I havn't seen a commit which could fix that or mentioned that issue. I'll give it a try tomorrow.

[boelle]

np.... the bug fixing branch was just created today...

[Tommy-LSA]

I have tried the latest Dev branch. The Problem further exist. The steps/mm I have tested are as follow

DEFAULT_AXIS_STEPS_PER_UNIT {320,320,772.9,600}

The Printer has a 40 teeth GT2 Pulley on X+Y, A ballscrew 12x4 on Z and a direct extruder with 600 steps/mm. The THB driver with 1/128 is on X+Y only

I have tested with printing a 20x20x20mm cube.

[boelle]

ok, will upgrade this to a verified bug then

[Tommy-LSA]

The Problem also occurs if I set the THB to 1/32 and use this

DEFAULT_AXIS_STEPS_PER_UNIT {80,80,772.9,600}

This combination works fine with DRV8825 but not with THB6128. So I assume that it is not the total number of steps which overloads the Atmega or a calculation issue. I think it's a pulse/timing issue. The issue doesn't occur in Repetier FW as reported by persons in this thread. So it should be solvable in Marlin too.

[Tommy-LSA]

Update: With 1/32 the problem is more massive than with 1/128. With 1/32 the perimeters are nearly beside of the perimeter from last layer. side by side compare - the same file (cube 20x20x20mm) printed with 1/128 and 1/32 with THB6128 driver @ 10mm/s https://www.dropbox.com/s/vuj8quqngrx5386/20141230_170443.jpg?dl=0

[boelle]

dammm the tower of piza :-D i guess the only thing that prevents it from tilting is the adhesion to the bed

[Tommy-LSA]

Yes - BuiltTak has a very good adhesion on cold bed ;)

As you can see on the picture the position difference is higher on first and last 4 layers. These are closed while the layers in the middle have an infill of 20%. So the problem seems to increase on length of printed filement.

[nophead]

Seems like it misses a step when it changes direction and there are more changes of direction when the infill is solid.

This points to the step signal being inverted or not enough setup and hold time for the direction signal. However I think this was suggested a long time ago.

[Tommy-LSA]

The different between 1/32 and 1/128 is the higher number of steps/mm on 128. As far as I understand the code group steps on higher "traffic" while on less "traffic" more single steps are done. So the grouping seems to make it better. Yes, nophead, it seems that there are steps missed. But in interaction FW<->Driver not on mechanical block. I think it's a timing issue in communication

[Tommy-LSA]

I made some tests in the past with delay times in the stepper interrupt. But blocking the interrupt with a delay cannot be a final solution. I don't know what they do different in repetier FW.

[nophead]

With 128 the steps are smaller so one missed step is less significant hence less slope.

Yes I was talking about an electronics timing issue, not mechanically missed steps. The direction signal must be valid a certain period before the step pulse and remain valid for some time after. These are known as setup and hold times. Violating them is likely to have one step in the wrong direction at the start or the end of each line that changes direction.

[Tommy-LSA]

Okay, your first sentence would confirm that there is something wrong around the DIR change. But how to change without side effects to the other drivers? If somebody has a hint with a code change I would test it.

[Tommy-LSA]

I have added a wait behind switching DIR on X. The step_wait() function already exist in stepper.cpp and contaiins a loop 0 to 8. I have added it 5 times but doesn't change anything

// Set the direction bits (X_AXIS=A_AXIS and Y_AXIS=B_AXIS for COREXY) if((out_bits & (1<<X_AXIS))!=0){

ifdef DUAL_X_CARRIAGE

    if (extruder_duplication_enabled){
      WRITE(X_DIR_PIN, INVERT_X_DIR);
      WRITE(X2_DIR_PIN, INVERT_X_DIR);
    }
    else{
      if (current_block->active_extruder != 0)
        WRITE(X2_DIR_PIN, INVERT_X_DIR);
      else
        WRITE(X_DIR_PIN, INVERT_X_DIR);
    }
  #else
    WRITE(X_DIR_PIN, INVERT_X_DIR);
    step_wait();
    step_wait();
    step_wait();
    step_wait();
    step_wait();
  #endif  
  count_direction[X_AXIS]=-1;
}
else{
  #ifdef DUAL_X_CARRIAGE
    if (extruder_duplication_enabled){
      WRITE(X_DIR_PIN, !INVERT_X_DIR);
      WRITE(X2_DIR_PIN, !INVERT_X_DIR);
    }
    else{
      if (current_block->active_extruder != 0)
        WRITE(X2_DIR_PIN, !INVERT_X_DIR);
      else
        WRITE(X_DIR_PIN, !INVERT_X_DIR);
    }
  #else
    WRITE(X_DIR_PIN, !INVERT_X_DIR);
    step_wait();
    step_wait();
    step_wait();
    step_wait();
    step_wait();
  #endif  
  count_direction[X_AXIS]=1;
}

[Tommy-LSA]

It seems that the issue isn't a general issue of THB6128. I have tested the brand new RAPS128 (Pololu compatible THB6128) from here: http://max3dshop.org/index.php/default/elektronik/raps128.html?___SID=U This works perfectly without any changes in Marlin. X+Y 320 steps/mm on GT2 40teeth. So it seems that the optocoupler on the THB6128 Boards need an other timing or something like that. The RAPS128 hasn't couplers. If someone like to test this drivers - the ENA Pin have to be inverted in configuration.h for this Axis

See Video: https://www.youtube.com/watch?v=W7PykPQL2qs

[CONSULitAS]

@boelle @leseaw

Could #1385 be the cause for this issue? You should try the proposed changings and test. What do you think?

[thinkyhead]

Post a new issue if this is persisting with the latest Development branch. Preparing for a code freeze, perhaps…

[thinkyhead]

@Wurstnase I'd be curious to see if #2033 makes any difference. If so we can call it a bug fix.

[Wurstnase]

On the Due the standard trapezoid_generator_reset() need ~2,5µs. The AVR should need much more time. So I think we get here at minimum 5µs delay for a DIR setup.

[github-actions[bot]]

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.