TMC5130

Adalbert · Post by **Adalbert** » Sat Jul 27, 2019 3:11 am

Hello everybody,
During the programming of the TMC5130 I have noticed a strange behavior:
1.) Long step 102400 (full rotation), 2.) Short step 25600 ( ¼ rotation)
The short step starts with the small movement in the opposite direction!

Code: Select all

long Rail&#58;&#58;moveStep&#40;long targetPosition&#41;
&#123;  
   tmcSendData&#40;0xAD,targetPosition&#41;;    //XTARGET
   tmcSendData&#40;0x21,0x00000000&#41;;    
   delay&#40;100&#41;;
   tmcSendData&#40;0xA1,0x00000000&#41;;        //XACTUAL=0
&#125;

But no problem with:
1) Long step, 2.) Long step
1.) Short step, 2.) Short step
1.) Long step, 2.) -Long step
1.) Short step, 2.) –Short step
1.) Long step, 2.) –Short step

BTW, my controller looks as follows:
https://www.photomacrography.net/forum/ ... highlight=
BR, ADi

Chris S. · Post by **Chris S.** » Sat Jul 27, 2019 7:24 pm

ADI,

As an experiment, I would try using a much longer delay (perhaps 500), and see if the strange behavior goes away. If it does, then reduce the delay until the strange behavior returns, then increase it slightly such that the system behaves predictably.

My experience programming stepper motors has been with the TB6600 stepper motor driver, which is quite a different beast from your Trinamic TMC5130--so this may not help you. But when I first started, I was getting all sorts of unpredicted, non-deterministic behavior out of the motors. After several days of banging my head against the wall, I figured out that these issues went away if the delay between pulses was long enough. Also, I found it necessary to determine a new minimum delay every time I changed anything significant in the system: motor, power supply, current, microstep setting, etc. (One can, of course, use longer delays than the shortest one that works predictably, but this slows down the motor.)

This is the most important--and difficult--lesson I've found in working with stepper motors. I presume the issue is the time it takes for magnetic fields in the motor to form and collapse.

--Chris S.

mawyatt · Post by **mawyatt** » Sat Jul 27, 2019 9:29 pm

ADi,

I don't see any of that behavior with the 5130 on the RPi.

What Chris indicated is a good approach.

Best,

Adalbert · Post by **Adalbert** » Sun Jul 28, 2019 2:34 am

Hello Chris,
Many thanks for the hint!
I have already tested the behavior of the TMC5130 dependent on the delay.
So, the smaller the delay the shorter the movement in the opposite direction.

Now, I don’t have any delay :

Code: Select all

void Rail&#58;&#58;moveStep&#40;long targetPosition&#41;
&#123;  
   tmcSendData&#40;0xAD,targetPosition&#41;;    //XTARGET= targetPosition with micro step = 256
   tmcSendData&#40;0xA1,0x00000000&#41;;        //XACTUAL=0
&#125;

I would like to stress that this bug happens only if a short step follows a long step in the same direction.
In all other combinations TMC5130 works without any problem.
BR, ADi

Adalbert · Post by **Adalbert** » Sun Jul 28, 2019 2:47 am

Hello Mike,
I changed my procedure getEndPoint(), so that I can move the rail with the step, which is used by the stack() method.
The rail is moved by 10 * stacktStep by the buttons LEFT and RIGHT and by 1 * stackStep by the buttons UP and DOWN.
So, if I use UP/DOWN before stack is executed, the first step of the stack is the same as the last step of the getEndPoint.
In this way I manage the bug of TMC5130 :-)
I could image, that TMC reaches the target position but this “warm-up” is not really good for any rail with a backlash.
But it is not a big problem for me. I can ignore the first photo of the stack.
BR, ADi

mawyatt · Post by **mawyatt** » Sun Jul 28, 2019 5:40 am

ADi,

Since I don't see this with the RPi, I wouldn't necessarily qualify this as a "bug of the TMC5130", might be a bug with the Arduino and 5130 SPI interface, timing, or coding.

You could report this issue on the Trinamic blog and see what they say.

Best,

Adalbert · Post by **Adalbert** » Sun Jul 28, 2019 7:35 am

Hello Mike,

Since I don't see this with the RPi,

You only can notice that if you observe the motor.
So, first a long step, then short one in the same direction.
The motor makes a kind of a ”warm-up” in the opposite direction but reaches the target position.

Example of the behavior of the small step which follows a long one in the same direction
should be: 100 to the right
is: 20 to the left then 120 to the right

I have already tested all combinations of long/short/changed directions etc.
Everything works OK with one and only one exception.

I really don’t know if this is a bug or a feature.
I can manage this behavior therefore it is no problem for me.

BR, ADi

mawyatt · Post by **mawyatt** » Sun Jul 28, 2019 8:03 am

ADi,

I've watched the motor position on many occasions and had not noticed this behavior. I'm sure I would have noticed this when doing the positioning at effective 800X and doing the video (see video) to show the Trinamic 5130 performance with a KR20 and 0.9 degree motor.

Maybe some others will report on this, but you should bring this up with the Trinamic folks to see what they have to say. Please report what they say back to us folks using the 5130.

Best,

Chris S. · Post by **Chris S.** » Mon Jul 29, 2019 12:21 am

ADI,

I agree with Mike that what you're describing sounds like an issue in software at some level.

Do I understand correctly that: You are converting your code to work with the Trinamic stepper motor driver, from earlier code used to drive a stepper motor in some other way?

Do I also understand that your new code loads Trinamic libraries, and references functions from these libraries?

If this is the case, are you using the AccelStepper library at all? While AccelStepper is the go-to recommendation for stepper motor control among the Arduino community, I found AccelStepper buggy in the extreme--perfectly capable of causing weird behaviors such as you describe. After trying AccelStepper for a few days, and getting unexpected behaviors from my motors, I gave up on it. A key to this decision was finding posts by experienced AccelStepper users who also found it buggy and unpredictable. My response was to write my own procedures for ramping the motor speed up and down (the two capabilities I'd desired from AccelStepper). My own code might not be better than AccelStepper, but since I wrote it, I understand what it does, how to work with it, and what to change if something goes wrong.*

The code snippets you posted appear to invoke Trinamic libraries, and I have no experience with either Trinamic's software or hardware. But if AccelStepper libraries are loaded and referenced anywhere in your code, you might consider removing them.

Cheers,

--Chris S.

*Am happy to share this code, if anyone wants it. But my sense is that it's more productive to share insights, rather than code alone; shared insights let the recipient write code that he or she understands and can troubleshoot.

Adalbert · Post by **Adalbert** » Mon Jul 29, 2019 1:12 am

Hi Mike,

but you should bring this up with the Trinamic folks to see what they have to say

I have already asked this question.
BR, ADi

Adalbert · Post by **Adalbert** » Mon Jul 29, 2019 1:21 am

Hi Chris,
I don’t use any libraries and only adapted the example of Trinamic:
https://blog.trinamic.com/2017/04/05/ho ... uino-mega/
This code works correctly in all cases except LONG_STEP->SHORT_STEP IN THE SAME DIRECTION.
BR, ADi

Adalbert · Post by **Adalbert** » Mon Jul 29, 2019 1:26 pm

Hello everybody,
The reason of this strange behavior was the command: tmcSendData(0xA1,0x00000000); //XACTUAL=0 in my moveStep().
During the normal motion of the motor (e.g. during the stacking) this command MUST NOT be used!

“Writing to XACTUAL already will trigger a new motion, because a mismatch of XTARGET and XACTUAL occurs at that time.”

So, I have changed the code, so that the every target-position is calculated absolutely and the current position no more set to 0 after the execution of the each step.
Everything is perfect now :-)
BTW, the support of Trinamic is excellent.
BR, ADi

kaleun96 · Post by **kaleun96** » Tue Jul 30, 2019 9:48 am

Chris S. wrote: If this is the case, are you using the AccelStepper library at all? While AccelStepper is the go-to recommendation for stepper motor control among the Arduino community, I found AccelStepper buggy in the extreme--perfectly capable of causing weird behaviors such as you describe. After trying AccelStepper for a few days, and getting unexpected behaviors from my motors, I gave up on it. A key to this decision was finding posts by experienced AccelStepper users who also found it buggy and unpredictable. My response was to write my own procedures for ramping the motor speed up and down (the two capabilities I'd desired from AccelStepper)..

Don't mean to hijack this thread but am curious what kind of weird behaviours you've encountered with AccelStepper.

I've come across a few myself but have solved them all from what I can tell. I'm working at 1.25μm per microstep and haven't noticed any funny behaviour since getting everything to near-completion. Most of the tricky stuff with AccelStepper was getting the steppers to promptly stop and then accelerate in the opposite direction (e.g. after hitting end stops). Playing around with a combination of of setting speed to 0, calling stop(), disabling motors, etc got it to work for me.

But considering I only accelerate for homing the rail and I've already written a basic acceleration procedure for when using a joystick (where AccelStepper's acceleration code can't help) to prevent jerk, I probably could do away with the library.

Adalbert · Post by **Adalbert** » Wed Jul 31, 2019 1:27 am

Hi Chris, hi kaleun96,
Does the AccelStepper support the TMC5130 & SPI ?
BR, ADi

kaleun96 · Post by **kaleun96** » Wed Jul 31, 2019 1:31 am

Adalbert wrote:Hi Chris, hi kaleun96,
Does the AccelStepper support the TMC5130 & SPI ?
BR, ADi

It doesn't support stepping via SPI but it can work with it using STEP/DIR pins. I did look at what it would take to change the library so it supports SPI or port manipulation and I don't think it would be a lot of work. There's really only one function (or maybe two) that sends STEP and DIR instructions to the motor.

TMC5130

TMC5130

Re: TMC5130