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.

[nophead]

@leseaw how do you run Marlin on a DUE? Is there a port?

[oysteinkrog]

@nophead https://github.com/bobc/Marlin

[Tommy-LSA]

I checked the Controller with a microscope - my THB6128 from goodluckbuy has an Toshiba TLP109 on the STEP Pin. The Datasheet talks about tpLH = 0.8 μs (max) http://www.toshiba-components.com/docs/opto/TLP109_en_datasheet.pdf On DIR and ENA it have TLP291 with 4µS rise time and 7µS fall time https://www.toshiba.com/taec/components/Datasheet/TLP291.pdf

[Tommy-LSA]

I have tested now a 10µS delay behind the direction pins (rise and fall to respect the coupler switchtimes) and removed the delay on step pins. Result was the initial problem "print drifts"

[nophead]

Did you move the direction setting code as I described above so that it not executed every interrupt?

[Tommy-LSA]

No, that is to much for my understanding of this code

[MaikStohn]

Progress: After changing configuration for my setup (all signals / inversions as required, checked with scope) I started to make some tests with hand written gcode. It seems to confirm, that it has nothing to do with the THB driver itself (since other firmware can use it this was expected). It also looks like it has nothing to do with any driver timing, direction setup time or the specific motor attached.

http://stohn.de/3d/index.php/2014/09/08/marlin-firmware-problem-analysis-with-high-step-rates/

The video shows (actually you HEAR the problem when it performs the last moves) that when running the same moves (just added in between some extra commands) the machine behaves different. Since this "extra commands" might be temperature checks/reports to host, other axis moves, ... it is very common that they will happen during normal prints.

My first guess is, that the (special/emergency) handler for the serial input buffer (which seems to be called from interrupt directly in this case) is working as expected software wise but leads to an unusable result for printing...

This means Marlin just can not produce this high step rates right now. This affects 32/64/128/... micro steps (yes 1/32 micro step also, when used with very high speeds).

[Tommy-LSA]

The GCode I posted above does a retract before "hard jump" so it could confirm that. It makes no different whether I am connected to Repetier Host or not during print.

[nophead]

Is this the serial handler you are referring to?

#ifndef AT90USB
MSerial.checkRx(); // Check for serial chars.
#endif

In which case it will only affect some boards. Also the max step rate will depend on whether endstops are checked after homing and how many extruders there are, etc.

[MaikStohn]

@nophead Yes this is what I guess can be a problem. You say the serial check affects only "some" boards. As far as I know the majority of reprap boards is not based on AT90USB but on ATmega644/1280/2560...

@Tommy-LSA , @leseaw What is your hardware/electronics setup? I use Arduino2560 + Ramps 1.4 + 16x2 Display + Rotary Encoder + SD Card

@nophead Thanks for the heads up with endstop checks during print (they are enabled in my setup) and the amount of extruders (I have 2 configured).

After checking a bit the command flow it also might have something to do with the " st_synchronize();" function. When I use repetier host and issue the GCODEs by hand (one by one) I also get the problem without any extra gcodes in between and even when waiting several seconds between the moves.

[leseaw]

I testet with ramps/rumba/radds its all time the same :( the problem only with x/y z and extruder works fine

[MaikStohn]

@leseaw So you say it is exact the same on 8bit ATmega and 32bit ATSAM3? This let's me think serial transmission and interrupt timing might not be responsible...

[nophead]

I think AT90USB is only defined on boards that have USB built into the CPU rather than a separate chip and a UART.

[Tommy-LSA]

@MaikStohn : I use Arduino2560 on a 3drag board. http://reprap.org/wiki/3Drag_controller Display is a 4x20 with clickable encoder and SD

Edit: 1 Extruder

[leseaw]

@MaikStohn Yes the same :( Display or Computerprinting Changing driver to DRV same Gcode all fine.

[oysteinkrog]

@MaikStohn I have seen similar behavior as in your video with DRV8825 and 1/32 microstepping when I lowered the Marlin stepper frequency interrupt to 30 kHz (from the normal 40 kHz). Reducing maximum velocity "fixed" the problem. What is your X/Y vmax?

[leseaw]

Are not to fast for DUE/RADDS? Or? The code are to slow?

[Tommy-LSA]

I have reduced my vmax on X/Y to 200 longer time ago (and during all tests on the different steppings).

[oysteinkrog]

@Tommy-LSA With 1/64 you need to go way slower I think. It depends on your mechanical setup, but if you have a normal 20-tooth gt2 pulley and use 1/64 microstepping, your steps/mm will be 240. 40 000 / 240 ~= 166.67 vmax, and in my experience doing e.g. a diagonal XY move will require 1/2 of that again for vmax (in order to prevent bad stuttering). Try with a vmax of e.g. 150 for movement in just one axis, and a vmax of 75 for diagonal moves.

For the record; I am not saying that this behavior is good/OK, it just seems to be how Marlin works right now. If repetier et al. really does so much better it would certainly be good to port that code to Marlin. Does anyone know how repetier handles this scenario, where speed exceeds the stepper interrupt frequency? Does it also do step combining or does it throttle velocity?

Here is a video of the stuttering I get when I set Marlin to use the absolute vmax (for me max is 250mm/s for a single axis): https://plus.google.com/113252364984901542714/posts/FPpTKnrfE27 It is fairly random but disappears as soon as I drop the vmax just a few percentage points.

[leseaw]

no thats not right :( i print with drv8825 the same speed without problems. and my raddsd/due has more MHz as the 2560. Its the firmware not the hardware. if i print with repetierfirmware i can print with 400mm/s without problems. and i use not an pulley i have fast lead screws. so with 1/32 i have 256 stepps

[oysteinkrog]

@lesaw, did you increase the stepper interrupt timer frequency when running on the due? With that kind of setup you are almost certainly either not getting 400mm/s OR the steps are being combined. Even with a smoothieboard at 100kHz! the theoretical vmax for individual steps is: 100 000 / 256 = 390.625 mm/s Repetier firmware also advertises a 40kHz stepper frequency, which means that they are clearly doing something different. Perhaps there is a bug in Marlin related to the steps being combined? . BTW: I would really love for someone to explain if (and how) my understand of things and calculations are incorrect.

[nophead]

In Marlin the max step rate is capped to MAX_STEP_FREQUENCY, set to 40000 in configuration_adv.h. The max interrupt frequency is then capped at 10KHz by bunching steps in twos or fours.

During acceleration and deceleration it might change its mind about how many steps to bunch. Perhaps that is when it goes wrong.

Also I am suspicious that the loop that bunches steps can cause some of the deceleration to be skipped when the constant speed part does not divide evenly by four. Say the constant speed part is 5 steps. If it was running slow enough to not bunch then it would do five steps at the full speed and then decelerate on the sixth. If it was going fast enough to bunch in fours then I think it will do eight and then start decelerating.

[Tommy-LSA]

have anyone a workaround in the meantime?

[diver197]

我遇到过这个问题，我已经处理了，我想你是添加了光耦隔离输入的，由于6128的输入脉冲是与8825是相反的，只要你改变脉冲方向就可以了 I have encountered this problem , I've dealt with , I think you are adding a opto isolated inputs , the input pulse is due to 6128 and 8825 is the opposite, as long as you change the direction of the pulse can be a Not English, robot translation

[Tommy-LSA]

So which config parameter you suggest to change for this Driver on X and Y?

[Tommy-LSA]

Well, have found the Settings for inverting Step Pins in configuration_adv.h. Nice that it works on your end but my result I have recorded here :-/ https://www.youtube.com/watch?v=NoMIsG6EOQg The noises you hear are only from Hotend fan. Moving Axis is noiseless on 1/128

1/128, x/ysteps 512. Yo see no lost steps an very smooth print. But Tower of Pisa. Result should be a cube 20x20x20mm.

One different I see: On enabling printer i get a short noise from Steppers and the two red LED from X/Y Pololu sockets are permanently ON while the printer is in standby (no Job is running)

[diver197]

你出的问题与我遇见的是一样的，不知道你是否使用了光电耦合器，如果使用了，就在输入那里改变输入方向就可以的，如果不清楚，可以发你6128模块板的图片到我邮箱 You are out of the question and I met is the same , do not know whether you use optocouplers , if used , on the input where you can change the input direction , and if you are unsure , you can send your pictures to the 6128 module board my mailbox

[Tommy-LSA]

I already wrote in this thread which optocouplers are used https://github.com/ErikZalm/Marlin/issues/1041#issuecomment-54722500 Also I posted the source of the boards which is here http://www.goodluckbuy.com/thb6128-stepper-motor-driver-module-for-2a-28-39-42-57-stepper-motor.html If it helps I'll make pictures again and send it wherever you want. Tell me whether Front- or Backside or needed Detail. But pleas check the thread above whether the information not allready posted.

Here 3 actual images: https://www.dropbox.com/sh/h4qgs85y4qni6ed/AAD0c7_A6L5BxMhFB0bhDScPa?dl=0

[diver197]

你将pul- dir- en-连接gnd，pul+ dir+ en+连接2560引脚，这样就不用其他的设置了 You will pul- dir- en- connect gnd, pul + dir + en + pin connection 2560, so you do not set the other

[Tommy-LSA]

Yes, I have connected the + connectors to Pololu socket and the - connectors to GND of controller. Is that wrong?

[diver197]

是的，这样就会被光耦合器把信号脉冲的方向改变，每次就会延后90度 yes，This will change the direction of the optical coupler of the signal pulses , will be delayed by 90 degrees every

[Tommy-LSA]

What is your suggestion? Should I connect the Step pin from Pololu socket to PUL- and PUL+ to GND then? Please note that on the Board are different kinds of coupler. The Coupler for PUL is different (faster) than couplers from DIR and ENA.

[diver197]

Can not send pictures , you just point my head, email me now

[Tommy-LSA]

After some mails force and back - no results. The wiring is correct and the problem isn't solved. Inverting step pins in configuration_adv.h has no effect to the problem.

[Rustbucket]

@Tommy-LSA I've recently changed my cnc running from grbl to repetier host - but now it also seemingly suffers from the lost step issue. Configuration: Arduino Mega 2560 running repetier 1.0.6 Modified Ramps 1.3 board Three DQ542MA drivers, on 24V supply 5mm pitch lead screws on all axis & Nema 23 motors

Check out: http://www.repetier.com/documentation/repetier-firmware/rf-installation/ where they explain the Bresenham algorithm. After tinkering a few days with settings and rewiring, it seems that changing "#define MAX_HALFSTEP_INTERVAL 16000000" in the configuration.h file solved the problem. ~ basically just disabling their fancy algorithm. I'll be doing test prints during the next week to fine tune the rest of my setup.

[Tommy-LSA]

But we are on Marlin here?!

[Rustbucket]

They both use the Bresenham algorithm as a movement planner. Therefore I thought you might be able to simply disable it in your code and see if it solves your problem.

[nophead]

That isn't part of the standard Bresenham algorithm. It is somebody's idea of an enhancement. There is no MAX_HALFSTEP_INTERVAL in Marlin as far as I can see.

[bkubicek]

for debugging purposes, one could add checks in the planner to see if there would be numeric overflows in the bresenham algorithm.

Bernhard

On Sat, Oct 25, 2014 at 10:17 AM, Chris notifications@github.com wrote:

That isn't part of the standard Bresenham algorithm. It is somebodies idea of an enhancement. There is no MAX_HALFSTEP_INTERVAL in Marlin as far as I can see.

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

[bkubicek]

daid once made a marlin compile for an avr simulator, this sounds like a topic best done with that.

Bernhard

On Sat, Oct 25, 2014 at 10:56 AM, Bernhard Kubicek < bernhard.kubicek@gmail.com> wrote:

for debugging purposes, one could add checks in the planner to see if there would be numeric overflows in the bresenham algorithm.

Bernhard

On Sat, Oct 25, 2014 at 10:17 AM, Chris notifications@github.com wrote:

That isn't part of the standard Bresenham algorithm. It is somebodies idea of an enhancement. There is no MAX_HALFSTEP_INTERVAL in Marlin as far as I can see.

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

[Tommy-LSA]

If you tell me exactly how to implement debug output lines I can make tests and provide results. I have the drivers here and can receive Log over Repetier host console.

[nophead]

I would look at the bunching up steps code, as I pointed out on Sept 8th, that looks like a bug to me.

[bkubicek]

its not ok to output debug from the ISR, if you want to continue printing. What you can do there is to set volatille ints or booleans, that you then can output on the uart, e.g. as a response from a polling gcode. Sendind UART directly from the ISR is a no go, because it will disrupt the ISR call thereafter, as sending takes longer than the call-frequency of the ISR.

Bernhard

On Sat, Oct 25, 2014 at 12:32 PM, Chris notifications@github.com wrote:

I would look at the bunching up steps code, as I pointed out on Sept 8th, that looks like a bug to me.

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

[Tommy-LSA]

Is there any progress? Is there nobody else who try to use a THB6128 with Marlin?

[boelle]

how many had this issue? if more than a few we can mark this as a verified bug

[Tommy-LSA]

I count 3 in this Ticket. It is confirmed, that it is a Marlin issue because it works on the same board with Repetier FW

[boelle]

then the next thing is if the problem have been solved with the recent changes...

[nophead]

I haven't seen any pull request that would fix it. It may be the same issue as #975. I think when you have more than x 16 drivers and run high speeds it goes wrong.

[Tommy-LSA]

no, it fails on low speeds also above 1/32 with this driver. The attempts to fix that with a delay causes other problems (step loss, noisy operation) I think it's number type to small or a wrong math round somewhere in the code when it comes to calculation with/off higer number of steps. The print with 1/128 looks absolutly perfect but the layers are not stacked vertically but like a tower of Pisa in on the axis the driver is used. If you use the driver on X only, you get the issue only on X. So it cannot be, that the total number of steps cannot be to high. The issue stays also if you reduce all axis to 1/16 but use one THB driver with above 1/32. I don't know whether other drivers on the market for 1/64 or above. With such driver we could try to duplicate the issue and exclude the driver itself but the calculation.

[boelle]

@Tommy-LSA have you tried with the latest copy in the bug fixing branch?