[BUG] TB6600 linear shift layer on X and Y axis

[F4HTB]

Description

We built a homemade printer.
We use an A8 motherboard on which we take the command: motor driver enable, step and direction.
We use a stage of amplification to pass the signals of the card anet A8 towards the drivers.

We use cura 4.4 or 4.3 to slicer.

When we use marlin 1.1.8, the prints are good.

When we use marlin 1.1.9 or 2.0, we have the same problem.
When a layer is made, when returning to the original position for the next layer, it appears that one or more steps of the thickness of a layer are not performed.
This does not translate into a regularized layer shift.
See picture.

We reviewed most of the parameters around drivers and possible EMI problems etc ...

It seems that since version 1.1.9, a bug is introduced in the code.

On the reprap.org forum, I read several posts about this problem and it be never solved by another solution than to return to version 1.1.8

Attach the parameter files is not needed, we have try all parameters, we get We usually have the same result or worse.
But quite honestly, someone really needs to look at the TB6600 drivers to see why it works in 1.1.8 and not in 1.1.9, 1.1.X-bugfix or 2.0 ....

Big Thanks in advance.

[thisiskeithb]

Did you initialize your EEPROM after updating? Run M502, followed by M500 to perform a factory reset.

[F4HTB]

I am not but hard reset after flashing made this no?

[sjasonsmith]

This is probably related to other issues with missed steps on DRV8825 drivers. We're probably generating step pulses smaller than the minimum the TB6600 needs.

The TB6600 requires a 2.5 microsecond step pulse, and I suspect we are generating pulses that are sometimes only about 1.4 microseconds.

I suggest setting MINIMUM_STEPPER_PULSE in Configuration_adv.h to 4 or even 5, to see if that helps.

[thisiskeithb]

Jason is probably closer to the real answer with his reply, but running M502 & M500 after flashing firmware is good practice. Especially when moving through firmware versions while testing.

[F4HTB]

MINIMUM_STEPPER_PULSE Already tested with 2, 3, 4, 5 10, 30, MAXIMUM_STEPPER_RATE to MINIMUM_STEPPER_POST_DIR_DELAY etc...
No change...

[F4HTB]

Thank thisiskeithb, I would not fail to keep this in mind for nexts tests.

[F4HTB]

Same problem here for example:
https://reprap.org/forum/read.php?415,838766

[boelle]

Configurations, please
Please ZIP up your Configuration.h and Configuration_adv.h files (as
requested in the Issue template) and drop them into your next reply.
We'll check them over and see if anything is amiss.

[F4HTB]

Hi boelle,

Thanks for reply.

See attached differents tests in 1.1.x (1.1.9 bug fix).
Tell me if you want 2.0 versions but the changes are almost the same.

config tests.zip

[F4HTB]

See attached last test in 2.0
Last tests in Marlin 2.0 TB6600.zip

[F4HTB]

After some other research, i have unmount my driver and it seem to be some TB67S109AFTG.

https://datasheet.lcsc.com/szlcsc/1811151451_TOSHIBA-TB67S109AFTG_C92125.pdf

(TB6600 https://datasheet.lcsc.com/szlcsc/1809050226_TOSHIBA-TB6600HG_C66042.pdf)

But from what I read they go up to 200khz so that does not seem to be worse than a TB6600 ...
And that does not solve the problem of why in 1.1.8 it works but not in 1.1.9 and 2.0 ...

[boelle]

Tell me if you want 2.0 versions

1.1.9 and older are not updated anymore so you should always use 2.0.x

why in 1.1.8 it works but not in 1.1.9 and 2.0

maybe a mistake was made, and toshiba drivers are not used much so it takes a long time before mistakes and errors are discovered

[cjsoong]

@F4HTB
I use TB6600 in XYZ and it works fine.
This is my config for your reference
board type: MKS SGEN_L
marlin 2.0x
TB6600_config.zip

[boelle]

@F4HTB have you tried the config from @cjsoong ?

also remember marlin 2.0 was released yesterday

[F4HTB]

@boelle , yes i do.

I had to adapt some parameters like those of the end of races etc ... But always the same problem.
Also, our machine is a prototype and I do not always have it at hand.
To be certain of the problem, we will take a digital oscoloscope and record all the commands signals on one of the axes that does not work.
It will take time but at least we will know if the minimal time instruction of the steps is respected or not.
Also and at the same time, I will try to modify the controllers. They have 4n25 inputs and it is possible that they are limiting. So we will change that with a more efficient optocoupler.
I will share my advancements as soon as possible.
Thank you for leaving this post open until I have something new.