TMC5130A-TA BOB & ARDUINO UNO
Moderators: rjlittlefield, ChrisR, Chris S., Pau
Ah, of course! Forgot about the keypad and LCD display haha.Adalbert wrote:Hello Kaleun96,
Unfortunately only green marked pins are free
The remaining digital pins are used by the keypad-shield.
The pin 10 too, so that I have to use pin3 for SS / CSN.
BR, ADi
Have you thought about using a Mega instead? Most Uno breakout boards and shields are compatible with the Mega. I'm using one myself for a TFT display, stepper driver, joystick, camera shutter trigger, and light sensor.
I also concur with Mike about connecting the EN pin to a digital pin. I disable/enable the outputs on my driver all the time in my code, it is very useful to have that functionality.
I didn't know you could power the VIO pin via a digital pin as Mike suggested but that seems like a good option too. Though digital pins from an Arduino can only handle 20-40mA so hopefully that is enough for the driver.
Hello everybody,
Does anybody know if I can use the analog pins 1, 2, 3, 4, 5 as outputs if the analog pin 0 is already used as an input pin for the keypad-shield?
https://www.arduino.cc/en/Tutorial/AnalogInputPins
A0 = Pin 14
A1 = Pin 15
A2 = Pin 16
A3 = Pin 17
A4 = Pin 18
A5 = Pin 19
BR, ADi
Does anybody know if I can use the analog pins 1, 2, 3, 4, 5 as outputs if the analog pin 0 is already used as an input pin for the keypad-shield?
https://www.arduino.cc/en/Tutorial/AnalogInputPins
A0 = Pin 14
A1 = Pin 15
A2 = Pin 16
A3 = Pin 17
A4 = Pin 18
A5 = Pin 19
BR, ADi
Should be fine as you specify the pin mode on a per-pin basis. So it might be something line pinMode(15, OUTPUT);Adalbert wrote:Hello everybody,
Does anybody know if I can use the analog pins 1, 2, 3, 4, 5 as outputs if the analog pin 0 is already used as an input pin for the keypad-shield?
https://www.arduino.cc/en/Tutorial/AnalogInputPins
A0 = Pin 14
A1 = Pin 15
A2 = Pin 16
A3 = Pin 17
A4 = Pin 18
A5 = Pin 19
BR, ADi
Hello kaleun96,
I have just connected a diode (and 200 R) to the analog pin 1 and a piezo buzzer (and 100 R) to the analog pin 5.
pinMode(A1, OUTPUT);
pinMode(A5, OUTPUT);
for(int j=0; j<3; j++)
{
digitalWrite(A1, HIGH);
tone(A5, 1000); // Send 1KHz sound signal...
delay(1000); // 1 sec
digitalWrite(A1, LOW);
noTone(A5); // Stop sound...
delay(1000);
}
It works without any problem with the keypad-shield :-)
BTW, the digital pins 0 and 1 are connected to the relays.
During the programming they make some noise but sketch can be uploaded.
BR, ADi
I have just connected a diode (and 200 R) to the analog pin 1 and a piezo buzzer (and 100 R) to the analog pin 5.
pinMode(A1, OUTPUT);
pinMode(A5, OUTPUT);
for(int j=0; j<3; j++)
{
digitalWrite(A1, HIGH);
tone(A5, 1000); // Send 1KHz sound signal...
delay(1000); // 1 sec
digitalWrite(A1, LOW);
noTone(A5); // Stop sound...
delay(1000);
}
It works without any problem with the keypad-shield :-)
BTW, the digital pins 0 and 1 are connected to the relays.
During the programming they make some noise but sketch can be uploaded.
BR, ADi
Hello everybody,
I have moved the IR from the Pin2 to the A1 and used Pin2 for the DRV_ENN.
The first test with 256 micro-steps:
https://drive.google.com/open?id=1B5oN9 ... S3cORF35Fh
BR, ADi
I have moved the IR from the Pin2 to the A1 and used Pin2 for the DRV_ENN.
The first test with 256 micro-steps:
https://drive.google.com/open?id=1B5oN9 ... S3cORF35Fh
BR, ADi
Nice! I'm surprised you have it running so fast with 256 microsteps. If you try and stop it from turning, does it stall very easily or does it require a bit of force to stall the motor?Adalbert wrote:Hello everybody,
I have moved the IR from the Pin2 to the A1 and used Pin2 for the DRV_ENN.
The first test with 256 micro-steps:
https://drive.google.com/open?id=1B5oN9 ... S3cORF35Fh
BR, ADi
I'm running at only 4 microsteps on my TMC2130 and it's still not as fast as I would perhaps like. If I go use more microsteps I find the motor stalls easier and I have to recalibrate the parameters for StallGuard.
At the moment are you just using digitalWrite to the STEP and DIR pin to control the motor or are you controlling the motor current directly via SPI?
Hi Kaleun96,
Yes, SPI has been implemented and the following example used:
http://blog.trinamic.com/2017/04/05/how ... uino-mega/
I only changed the pins CSN=3 and DRV_ENN=2
and disabled the clockout, because pin9 is used by the keypad-shield.
BR, ADi
Yes, SPI has been implemented and the following example used:
http://blog.trinamic.com/2017/04/05/how ... uino-mega/
I only changed the pins CSN=3 and DRV_ENN=2
and disabled the clockout, because pin9 is used by the keypad-shield.
BR, ADi
kaleun96,
The TMC5130 internal micro-controller changes the microsteps on the fly based upon what the demand motor speed is. Speeds over 600rpm are capable with the good motor, light load, proper motor parameters and good power supply & decoupling. Check the videos I did on these, recall doing 1000 rotations in under 30 seconds.
Nice work ADi, your KR20 will love this controller
Sorry I haven't responded more, but tied up with a new Piezo Electric Stage Controller development, these stages are amazing.
Best,
The TMC5130 internal micro-controller changes the microsteps on the fly based upon what the demand motor speed is. Speeds over 600rpm are capable with the good motor, light load, proper motor parameters and good power supply & decoupling. Check the videos I did on these, recall doing 1000 rotations in under 30 seconds.
Nice work ADi, your KR20 will love this controller
Sorry I haven't responded more, but tied up with a new Piezo Electric Stage Controller development, these stages are amazing.
Best,
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike
~Mike
Hi Mike,
Thanks! OK, it works but I have to adapt my software to this driver :-)
I’m not sure if I really have to check the target position.
If I start the movement e.g. tmcSendData(0xAD,step); and call the next one without any delay then the previous one will not be executed to the end.
So, I could place a delay or check with tmcSendData(0x21,0x00000000); if the target position has already been reached.
OK, this is not a problem in my rail.
BR, ADi
Thanks! OK, it works but I have to adapt my software to this driver :-)
I’m not sure if I really have to check the target position.
If I start the movement e.g. tmcSendData(0xAD,step); and call the next one without any delay then the previous one will not be executed to the end.
So, I could place a delay or check with tmcSendData(0x21,0x00000000); if the target position has already been reached.
OK, this is not a problem in my rail.
BR, ADi
ADi,
You don't to worry about what goes on in between the start and end positions, the 5130 micro-controller will take care of that. It won't mis steps unless you do something to the motor, assuming you have the proper parameters. Just set all your motor parameters, then simply tell the 5130 to goto a particular position, it will manage with the profiles you've setup.
I have routines that move the motor and wait until the destination is achieved, and one that doesn't (so you can do stuff while the motor's running).
Best,
You don't to worry about what goes on in between the start and end positions, the 5130 micro-controller will take care of that. It won't mis steps unless you do something to the motor, assuming you have the proper parameters. Just set all your motor parameters, then simply tell the 5130 to goto a particular position, it will manage with the profiles you've setup.
I have routines that move the motor and wait until the destination is achieved, and one that doesn't (so you can do stuff while the motor's running).
Best,
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike
~Mike
I think the TMC2130 has this too but since I'm not relying on the driver to determine position, lost steps, steps travelled etc I think it would be very hard to make the auto-adjusting microsteps work with my script that uses another library for knowing those parameters (position, travel distance etc).mawyatt wrote:kaleun96,
The TMC5130 internal micro-controller changes the microsteps on the fly based upon what the demand motor speed is. Speeds over 600rpm are capable with the good motor, light load, proper motor parameters and good power supply & decoupling. Check the videos I did on these, recall doing 1000 rotations in under 30 seconds.
Knowing that these tests were via SPI it makes sense that they're much faster than I'm getting. Arduino's digitalWrite() function can top out at only 110kHz or so, port manipulation is about 20x faster at 2.6MHz, and SPI could theoretically be much faster but on a 16MHz controller it's probably going to be somewhere around 4 to 8MHz.
Changing to either port manipulation or SPI would require some changes to the AccelStepper library, maybe I'll fork it and give it as go at some point in the future!
Yes this is one of the many fundamental advantages of the RPi over the Arduino. You can let the micro-controller handle the motor details with tight control and the RPi can act as the master issuing higher level commands, plus do all the user interfaces.kaleun96 wrote:I think the TMC2130 has this too but since I'm not relying on the driver to determine position, lost steps, steps travelled etc I think it would be very hard to make the auto-adjusting microsteps work with my script that uses another library for knowing those parameters (position, travel distance etc).mawyatt wrote:kaleun96,
The TMC5130 internal micro-controller changes the microsteps on the fly based upon what the demand motor speed is. Speeds over 600rpm are capable with the good motor, light load, proper motor parameters and good power supply & decoupling. Check the videos I did on these, recall doing 1000 rotations in under 30 seconds.
Knowing that these tests were via SPI it makes sense that they're much faster than I'm getting. Arduino's digitalWrite() function can top out at only 110kHz or so, port manipulation is about 20x faster at 2.6MHz, and SPI could theoretically be much faster but on a 16MHz controller it's probably going to be somewhere around 4 to 8MHz.
Changing to either port manipulation or SPI would require some changes to the AccelStepper library, maybe I'll fork it and give it as go at some point in the future!
Best,
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike
~Mike