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.

[oysteinkrog]

Have you done any debugging at all? Try various speeds in your slicer, try to reduce acceleration, feedrate and jerk in marlin.

[leseaw]

Yes do all :( Extruder works fine, better as with drv8825. Z also works good. only y and x. are on facebook a guy means his friend has the same problem and he fix it in marlin. i hope he post the code. i dont want to dry repetier :(

[oysteinkrog]

I ported/rewrote some old patches I found that are supposed to help with this by extending the stepper timing pulse. Please test this commit on top of your code/config and let me know if it works. https://github.com/oysteinkrog/Marlin/commit/36ba79f3697bfd1234c2ecb4bd0ab41939fd6286 Please excuse the horrible formatting/indenting in this commit. I'm running this now with 1 usec delay and DRV8825 drives and it seems to work fine, but someone with troublesome drivers need to confirm. What is the required pulse width for your THB6128 drivers?

[leseaw]

i have tested this and its dont work for me :( The same on all layers :( i can send one to you if you want to test. The layers are perfect only moving is wrong.

[oysteinkrog]

What did you set the delay define to? What microstep level are you using? I don't really know this for sure but I have read that the arduino may not be able to keep up with very high step rates. I am not interested in testing the chip myself, sorry. I am really quite happy with DRV8825.

[leseaw]

so next test. repetierfirmware out of the box run all fine. its a marlin problem.

And DRV is a bad driver against THB6128 Driver. perfect layer, more speed and silence from the stepper.

[trilitheum]

Hi oysteinkrog, I was discussing this same problem in issue #975
I have problematic DRV8825's that do not work with the current Marlin release. If I get some time in the next couple days or so I will swap them back in with your fork and see if they work.

[Tommy-LSA]

I see the same here. I have bought two THB6128 from goodluckbuy (http://www.goodluckbuy.com/thb6128-stepper-motor-driver-module-for-2a-28-39-42-57-stepper-motor.html) . With an Pololu adaptor connected to the controller of my Vellemann K8200 X+Y Axis. The movement works totally silent, fast and without vibrations. There are no lost steps. But Layer by Layer is reproducable moved by some 1/10mm in Positive X and Y direction. With this controller only on X Axis the move is also only on X. I have posted it also in reprap forum under http://forums.reprap.org/read.php?336,230366,399839#msg-399839 in case you want to see a foto. If you need additional info / fotos / tests - I would be glad to help.

BTW: I have seen a similar, more intensive effect when I tried to use an M8 Spindle on X Axis with 1/16 (A lot more XStep than the 514 I use actually for 1/128). So it also could be, that it depends on the XSteps /YSteps Setting (as higher Xstep as more move on X Layer by layer) Maybe a wrong math or rounding somewhere?!

[bkubicek]

I just had an idea, that might just work. How about: In the step generation, the step pin is just inverted from its previous state. So in one go it turns on, then the next ISR, it turns off, and so on. Then, you set the double steps/mm and you will probably? get a nice up_down with equal period lenghts? Might this do the job?

Bernhard

On Fri, Aug 29, 2014 at 2:35 AM, Tommy-LSA notifications@github.com wrote:

I see the same here. I have bought two THB6128 from goodluckbuy ( http://www.goodluckbuy.com/thb6128-stepper-motor-driver-module-for-2a-28-39-42-57-stepper-motor.html) . With an Pololu adaptor connected to the controller of my Vellemann K8200 X+Y Axis. The movement works totally silent, fast and without vibrations. There are no lost steps. But Layer by Layer is reproducable moved by some 1/10mm in Positive X and Y direction. With this controller only on X Axis the move is also only on X. I have posted it also in reprap forum under http://forums.reprap.org/read.php?336,230366,399839#msg-399839 in case you want to see a foto. If you need additional info / fotos / tests - I would be glad to help.

BTW: I have seen a similar, more intensive effect when I tried to use an M8 Spindle on X Axis with 1/16 (A lot more XStep than the 514 I use actually for 1/128). So it also could be, that it depends on the XSteps /YSteps Setting (as higher Xstep as more move on X Layer by layer) Maybe a wrong math or rounding somewhere?!

— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/1041#issuecomment-53824760.

[Tommy-LSA]

I don't think that the Step Timing is the problem here. Extending the microseconds between high/low has no influence. I have tested it up to 25 microseconds. The result is absolutely unchanged. I think there is something wrong in an algorithm which add one step/move/whatever per Layer. I havn't tested by myselve, because the repetier FW doesn't run out of the box on my K8200, but people say that the drivers run fine on repetier FW without any change of pulse timings.

[nophead]

There can't be a problem with the algorithm because it works with the drivers it is intended for.

Most likely there is not enough setup time for the direction signal. Or the step signal is the wrong polarity. Either can give one step errors per line.

[Tommy-LSA]

But if a direction change is failed totally printing wouldn't work at all. If steps would be lost after a direction change, we would get an minus X on each layer (each layer get shorter than the layer before). The total of XSteps per layer is okay. Each layer has the correct length but the X starting point seems to move per layer.

[bkubicek]

[my previous message was intended for a different thread, were the reacitivation of delays in the stepper ISR was discussed. Sorry, my bad. The idea was to not have delays, but just run the ISR twize as often..]

Bernhard

On Wed, Sep 3, 2014 at 10:58 AM, Tommy-LSA notifications@github.com wrote:

But if a direction change is failed totally printing wouldn't work at all. If steps would be lost after a direction change, we would get an minus X on each layer (each layer get shorter than the layer before). The total of XSteps per layer is okay. Each layer has the correct length but the X starting point seems to move per layer.

— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/1041#issuecomment-54269121.

[nophead]

Well I have written my own firmware in the past and accidentally inverted the step signal on a slow driver and got sloping objects where each layer was shifted over by a small amount.

The reason is that there is a minimum time between changing the direction signal and the leading edge of the step signal (called setup time). If you violate that then the first step could be missing, or backwards but subsequent steps will be OK.

[bkubicek]

http://www.leadshine.com/UploadFile/Down/DM422Cm.pdf figure 10

Bernhard

On Wed, Sep 3, 2014 at 11:44 AM, Chris notifications@github.com wrote:

Well I have written my own firmware in the past and accidentally inverted the step signal on a slow driver and got sloping objects where each layer was shifted over by a small amount.

The reason is that there is a minimum time between changing the direction signal and the leading edge of the step signal (called setup time). If you violate that then the first step could be missing, or backwards but subsequent steps will be OK.

— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/1041#issuecomment-54273726.

[Tommy-LSA]

so it should give a visible change on adding 5µs in stepper.cpp around line 353ff after the WRITE(X_DIR_PIN.... I'll give that a try this evening

[Tommy-LSA]

Well, I have added delayMicroseconds(5) after each WRITE to DIR Pins in stepper.cpp. The result: no change. I have made a short video from print https://www.youtube.com/watch?v=RU0yuUFwgzk

[nophead]

Try inverting the step signal. If you have connected it directly it will be active low.

[Tommy-LSA]

@leseaw has tested this already without effort.

[nophead]

Have you tried it in x16 mode or x32 mode? Most people don't go any higher than x32 so it could be bug with higher step rates.

0.1mm is a large number of micro steps. Maybe it skips a full motor step on long travel moves but slower extrusion moves are OK.

[Tommy-LSA]

I'm on it's maximum 1/128! These are in my case 512 Steps/mm. As you can see in the video it works fine and absolutely silent. I wouldn't buy the THB6128 and use it then with 1/32

[bkubicek]

could you please try with a "sane" microstep setting, if you have the similar problem? because, if not, its an indication that the problem that has nothing to do with delays at all, but probably with high step rates, which are treated quite complexly in the stepper ISR...

Bernhard

On Thu, Sep 4, 2014 at 4:34 PM, Tommy-LSA notifications@github.com wrote:

I'm on it's maximum 1/128! These are in my case 512 Steps/mm. As you can see in the video it works fine and absolutely silent. I wouldn't buy the THB6128 and use it then with 1/32

— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/1041#issuecomment-54485906.

[leseaw]

its also with 1/32 and THB6128. 1/128 Steps are not the problem. i will check with 1/16

[Tommy-LSA]

I can confirm the same behavior on 1/32 with this driver. I have it tested longer time ago. 1/32 with DRV8825 is okay

[Tommy-LSA]

I have implemented 4 lines with wait commands on X&Y Step generation. It seems that the wait is only needed in the first loop. The function step_wait() is extended by a delay STEPPER_DELAY_MIKROSECONDS. I have tested several values and from 4 onwards the print is ok. 4 means in this case a delay of 5x4=20 microseconds. I don't know how the code works in detail but maybe a developer can use this information as base for further investigatins. The print is a bit stuttering on small movements and fine on longer moves. What I not have tested is whether the High->LOW change can be smaller then 20 microseconds

The wait function: void step_wait(){ for(int8_t i=0; i < 6; i++){ delayMicroseconds(STEPPER_DELAY_MIKROSECONDS); } }

The changed codepart

    if (counter_x > 0) {
    #ifdef DUAL_X_CARRIAGE
      if (extruder_duplication_enabled){
        WRITE(X_STEP_PIN, !INVERT_X_STEP_PIN);
        WRITE(X2_STEP_PIN, !INVERT_X_STEP_PIN);
      }
      else {
        if (current_block->active_extruder != 0)
          WRITE(X2_STEP_PIN, !INVERT_X_STEP_PIN);
        else
          WRITE(X_STEP_PIN, !INVERT_X_STEP_PIN);
      }
    #else
      WRITE(X_STEP_PIN, !INVERT_X_STEP_PIN);
    #endif  
    if(i==0) step_wait();      
      counter_x -= current_block->step_event_count;
      count_position[X_AXIS]+=count_direction[X_AXIS];   
    #ifdef DUAL_X_CARRIAGE
      if (extruder_duplication_enabled){
        WRITE(X_STEP_PIN, INVERT_X_STEP_PIN);
        WRITE(X2_STEP_PIN, INVERT_X_STEP_PIN);
      }
      else {
        if (current_block->active_extruder != 0)
          WRITE(X2_STEP_PIN, INVERT_X_STEP_PIN);
        else
          WRITE(X_STEP_PIN, INVERT_X_STEP_PIN);
      }
    #else
      WRITE(X_STEP_PIN, INVERT_X_STEP_PIN);
    #endif
    if(i==0) step_wait();
    }

    counter_y += current_block->steps_y;
    if (counter_y > 0) {
      WRITE(Y_STEP_PIN, !INVERT_Y_STEP_PIN);

      #ifdef Y_DUAL_STEPPER_DRIVERS
        WRITE(Y2_STEP_PIN, !INVERT_Y_STEP_PIN);
      #endif

      counter_y -= current_block->step_event_count;
      count_position[Y_AXIS]+=count_direction[Y_AXIS];
      if(i==0) step_wait();
      WRITE(Y_STEP_PIN, INVERT_Y_STEP_PIN);

      #ifdef Y_DUAL_STEPPER_DRIVERS
        WRITE(Y2_STEP_PIN, INVERT_Y_STEP_PIN);
      #endif
      if(i==0) step_wait();
    }

[Tommy-LSA]

I have made some tests again. The 2nd wait is not needed. Only the first WRITE for each axis have to followed by a 20µS Delay. What I see is that on traveling the move is shortly interupted very hardly, near to loosing a step noises (gcode travelspeed 100, eprom accel 600)

[nophead]

I notice the datasheet says the maximum step frequency is 75kHz, so you need at least 13us between steps. If you are using x128 then your maximum motor speed will be 75000/(128 * 200) = 2.9 rev/s. With typical Reprap pulleys that will be only 117mm/s.

For 100mm/s with say 40mm per rev pulleys you need 2.5revs/s. That is a step frequency of 64kHz. Marlin will be trying to output 4 step pulses per interrupt with an interrupt rate of 16kHz. I.e. every 62.5us. Since the maximum step frequency of the driver dictates the four pulses need to be 13us apart that would mean the interrupt using at least 52uS every 62.5us, which would not leave much time for anything else.

For accurate stepping at those frequencies you should look at an ARM based solution to get the best out of your stepper drivers, or simply reduce the microstep settings. The data sheet says it will give smooth stepping with even low resolution step rates. I.e. I think it interpolates and works more like a servo system.

[leseaw]

with arm board the same. i use RADDS Board with an DUE, the same on all layers. Its in the firmware. With repetier runs out of the box.

[Tommy-LSA]

Well, I have tried it now with 1/64 with means 256 X/YSteps. The print is the same. Also with this config it seems that the printer try to "jump" on small travels (5-10mm travel) Larger travel are smooth. So between 1/128 and 1/64 is no different on this very hard travels. Except of this, which results partially in lost steps, it runs very smooth also in higher speeds. What could be the reason for getting short travels so hard/fast?

[Tommy-LSA]

Next test: 1/64 all delays removed. The print is smooth again and the hard jump on short travel is gone but the initial issue Layer by layer +X occours again. So we see these hard jumps only with a delay of 20µS after first WRITE(X_STEP_PIN, !INVERT_X_STEP_PIN);. It seems that it the Stepper try to jump all the microsteps which should be done in the delay time at once, in one large step. If this could be fixed by somebody with knowledge of the whole code the THB6128 would be work fine with 1/64 and 1/128

[oysteinkrog]

With DRV8825 and 1/32 microstepping I have found that I am limited to single axis moves of ~250mm/s, and e.g. diagonal X/Y moves of ~125mm/s. If I exceed these speeds I get really bad stutters. See full analysis here: https://plus.google.com/113252364984901542714/posts/XCTdGGBbjvd

I think it is due to the limited CPU power available (Marlin stepper freq of 40 kHz). With 1/64 microstepping and a 20-tooth pulley on X (160 steps/mm) you can not exceed 125 mm/s, with 1/128 you can not exceed 62.5mm/s. For diagonal moves the max would be 1/2 of that again, which means that anything beyond 1/32 microstepping seems very limiting for most kinds of printing. As it is I am considering going back to 1/16 just so I can do travel moves > 125mm/s.

[nophead]

I assumed the datasheet @bkubicek posted was for this driver but it appears to be nothing to do with it, so please ignore all my comments about timing. The driver on that datasheet is opto coupled, so will be much slower than a direct coupled chip.

I can't find a datasheet for THB6128 with any timing information on it. This seems to be the case for chips designed in China.

I can imagine why a 20us delay in the interrupt handler would screw things up when the step rate demands faster steps than that. Marlin can't handle an interrupt per step at high step rates so it does up to four steps in each interrupt as fast as it can. When you put a delay when i = 0 it means the first step out of each block of four gets that delay.

Marlin sets the direction signals on every interrupt, which is very wasteful. It would appear from the symptoms that you need a delay between setting the direction the first time and the first step. That would require some re-structuring.

It looks to me that the code that sets the direction signals could be moved to the start of the interrupt where it gets a new block, on line 329. That way it could have a delay after it which is only once per trapezoid, or it could do what it does for late z enable and set the timer and return to avoid a delay in the interrupt.

[Tommy-LSA]

I have retested it with 1/32 (which is 128 X/YSteps on my printer) AND delay. The hard jump on short travels is gone on the same Testjob. So this setup works. In this case the THB6128 wouldn't make sense except the smooth move through manageable decay. 1/32 is not smooth as 1/128. I don't know whether the code could be optimized. The only sheet I know for THB6128 is http://www.buildlog.net/forum/download/file.php?id=2169&sid=954bb26c2fe706fa7b4c9a5060490afc but it's not really related to timings.

[oysteinkrog]

@nophead You mention that Marlin will do up to 4 steps in each interrupt.. Could this logic be the reason for the "stutters" I am seeing? When I exceed the max theoretical travel speed of 250 mm/s on e.g. my X axis the stutters are really bad. 40 kHz stepping frequency / 160mm/s mechanics(1/32 microstepping) = 250mm/s max right? I am not missing steps, but is looks really quite violent, which means that the logic of combining steps does not seem to work very well for my setup.

IMO it seems like there is a lot of room for improvement here, instead of having Marlin combine steps I think it would be better to throttle speed, that way one could always utilize the maximum speed that the CPU could handle. When the CPU is the weakest link this kind of strategy would help a lot.

Now.. it might be silly to do all that just to save a few buck with a cheap arduino:P Perhaps it really is time to start looking at that port to the arduino due.

[MaikStohn]

@nophead: Which data sheet shows 75kHz for THB6128 as maximum step frequency? Out of curiosity I made some tests how fast it can go and what timing the driver requires: http://stohn.de/3d/index.php/2014/09/06/thb-6128-driver-speed-test/ The video shows 750 kHz, later I tried higher frequencies and even 1500 kHz was working fine. When I used more than 2 MHz the driver got damaged.

---

I also mounted the drivers to X/Y of my printer and configured Marlin (all signals are inverted ==> changed INVERT_X_DIR and INVERT_Y_DIR, set X_ENABLE_ON 1 and Y_ENABLE_ON 1).

Like some users in this thread I also saw the "JUMP" (very fast move) during some travel moves. (If I remember correctly, I noticed the same problem long time ago with another driver. It happened when Marlin was supposed to generate very high stepping frequencies (>60kHz). I tracked it down to the double/triple/quad step calculation which might have an overflow for very high frequencies - not to mention the very ugly stepping output when using this modes: Instead of regular appearing pulses like "s s s s s s" it generates a pattern like this: "s s s s . . . . . . s s s s . . . . . . s s s s".)

One other very reasonable explanation comes from nophead (not enough setup time when direction changes). I will do some experiments to check how much time is required electrically and physically (maybe inverting direction while motor is still moving in old direction and applying the first "reversed" step is causing problems...)

Could someone here help to track down the sequence of GCodes which causing the "JUMP" / crazy move? (several GCodes before and after the JUMP are required).

[Tommy-LSA]

@MaikStohn I have a gcode from my testprint here https://www.dropbox.com/s/swnnv3cigqa6s7e/Testkoerper.gcode?dl=0 The Jump occurs in the Layers with Infill. Would say from Layer 10 onwards you can pick one layer. The jump is, relative to the print from ~X10Y3 to X0Y0 (from Circle to left edge of this triangle.)

It is sliced with cura and I have added a g29 manually on top. With this Print I have made all tests 1/128, 1/64, 1/32

[MaikStohn]

Update:

I just found a mistake in my setup. I forgot to change the STEP PIN inverting:

In "configuration_adv.h" I forgot to set INVERT_X_STEP_PIN and INVERT_Y_STEP_PIN to "true".

@Tommy-LSA, @leseaw Have you changed all 3 values for each axis (INVERT_X_DIR=..., X_ENABLE_ON 1, INVERT_X_STEP_PIN=true)?

[nophead]

@MaikStohn my comments were eroneously based on the datasheet posted by @bkubicek but that is for a completely different driver (which I failed to notice) so I don't know why he posted it.

Bunching the pulses together is roughly the same as switching to lower micro stepping modes when travelling fast. It should allow higher speeds but no loss of accuracy at the endpoints, so I suppose it is better than capping the speed. You can always elect to do that by setting the firmware speed limits such that they don't exceed 10kHz so you have the choice.

[leseaw]

@maikstohn you usw the rrp driver?

[Tommy-LSA]

@MaikStohn: No I havn't inverted because it seem to run on positive pulses. Also I havn't seen any hint that the driver needs inverted pulses http://www.buildlog.net/forum/download/file.php?id=2168&sid=954bb26c2fe706fa7b4c9a5060490afc

[leseaw]

i think @maikstohn use the rrd driver, this driver need this. the normal thb6128 dont.

[nophead]

The chip uses positive logic but the board shown here: http://www.goodluckbuy.com/thb6128-stepper-motor-driver-module-for-2a-28-39-42-57-stepper-motor.html and the one shown here: http://www.dx.com/p/thb6128-driver-for-24-28-39-42-stepper-motor-265110#.VAsOjfmwJcQ both look like they have opto coupled inputs. In which case they are likely to be inverted and much slower than the raw chip.

[Tommy-LSA]

If it would be needed to invert e.g. the DIR the Printer would run in the wrong direction right now, isn't it? If it would be needed to invert ENA the drucker would stuck right now, isn't it? I don't assume, that they build different couplers on the board. 2 non inverting for DIR and ENA and one inverted for STEP

I have tried to invert the ENA some time ago because somebody in RepRap forum brought that up. When I had inverted the ENA pin the X + Y Axis stucks immeadately on Power on and moving over the Display isn't possible.

[nophead]

It's the step input that can cause one step errors when it is inverted giving exactly the same symptom as the first step being too close to the change in the direction signal.

If you have a board with optocouplers (small chips near the input connector) then it will be slow like the datasheet @bkubicek posted as they typically take a few micro seconds to transfer the signal.

I think the layer alignment problem is probably due to the direction signal changing too close to the first step and the lumpy stepping is when the step rate is too high for the Marlin. Repetier is better written, so can probably get higher step rates and may allow more dir setup time but it still resorts to bunching steps above a certain rate.

[Tommy-LSA]

Do you mean if I would bypass the couplers, by soldering a bridge, the Problem would be solved?

[nophead]

Yes quite likely, people have done that before for reprap firmware. Opto couplers do have the benefit that they prevent noise due to ground bounce though. With a direct connection you have to ensure the ground between the controller and the driver is solid. I.e. short and thick wire.

[MaikStohn]

I use the reprapdiscount.com driver which uses an opto coupler which inverts all 3 signals (ENABLE, DIR, STEP). The opto coupler used by RRD can do a very fast switching (>2 MHz).

@Tommy-LSA It depends what opto coupler is used on your hardware. Maybe you need to invert maybe not, maybe it is fast enough maybe not. Best would be to identify the chip (follow the PCB traces of the signal lines to the first chip and read its marking) and find a data sheet for it.

[nophead]

I can't find one on the rrd site. Can you post a link please.

[leseaw]

use repetierfirmware and all is fine :( and i know the autoleveling in repetier is crap are the stepperdriver works correctly.

And the thb can also 2MHz, its a bug in the firmware not with the driver. @maikstohn i think you have the same problem, i test with rrd driver,also the same thing. Travel or next layer always 1mm to endstop direction, with arduino 2560 or RADDS/DUE.Hvae you print small pieces?

[scotty1024]

Is it possible this thread has passed the invisible barrier and become more appropriate for a dedicated reprap forum thread? Not that it isn't chock full of goodness in each and every email but...

Scotty

On Sep 6, 2014, at 6:48 AM, Chris notifications@github.com wrote:

The chip uses positive logic but the board shown here: http://www.goodluckbuy.com/thb6128-stepper-motor-driver-module-for-2a-28-39-42-57-stepper-motor.html and the one shown here: http://www.dx.com/p/thb6128-driver-for-24-28-39-42-stepper-motor-265110#.VAsOjfmwJcQ both look like they have opto coupled inputs. In which case they are likely to be inverted and much slower than the raw chip.

— Reply to this email directly or view it on GitHub.