As the tittle states I am looking to have a way to control with precision about 100 stepper motors. I understand this seems like a lot but I am open to ideas as long as they can all work at the same time and are individually addressable. I was originally looking to use a stepper driver for each individual motor and still am open to it but I am not sure what system I can use to control each one from a Raspberry PI (model doesn’t matter I will buy whatever is best for this if my existing 3b doesn’t cut it). Does anyone have any suggestions or ideas? I am looking to feed direction data from my PC → RPi → stepper driver → stepper motor
Hello.
Your title mentions servos, but since you referred to stepper motors multiple times in your post, I suspect that was just a typo.
To independently control multiple stepper motors, you would need to use a separate driver or controller for each. Generating the STEP and DIR signals to control that many drivers from a Raspberry Pi would be difficult, and require some additional hardware. Instead, you might consider our Tic Stepper Motor Controllers, which offer higher level interfaces such as I2C. Using the I2C interface, you could configure each Tic to have a unique address so you can control them all from a single I2C bus. You can find more information about this in the “Setting up I2C control” section of the Tic user’s guide. Additionally, you can find some example code (including some written in Python) in the “Writing PC software to control the Tic” section.
Brandon
Yes it was a typo, glad you knew what I was talking about. So I hadn’t considered a I2C connection and I have not used it but I know it has a ton of potential. I think this would be a good idea but what about signal integrity from using 100 devices connected would that be an issue? another concern is bandwidth, does a I2C bus have enough bandwidth to control each motor simultaneously with independent controls?
With 100 devices on the bus, signal integrity is definitely a concern. For starters, I recommend keeping wire lengths as short as possible, and adding the Tics one a time to make sure you don’t have any problems. One consideration is that by default each I2C pin is pulled-up on the Tic, so when connecting 100 of them together, they will all be in parallel, making the pull-up very strong. So, you will probably need to disable the pull-up resistors on a number of the Tics, which you can do from the “Advanced settings” tab of the Tic Control Center.
The communication speed will depend in part on the signal integrity. For example, if your wires are long and the signal does not have enough time to rise between transitions, you might need to slow down the communication speed for it to function properly. Also, the Tic uses clock stretching, which could slow down the maximum rate you can send commands. Additionally, the Raspberry Pi boards have a known I2C clock-stretching bug, which you can find information about and a workaround for in the “Example I2C code for Linux in C” section of the Tic user’s guide.
The clock-stretching would not be an issue with the TTL Serial interface. So, if you do not need to read data back from the Tics, then TTL serial might be more practical. However, you would still need to worry about signal integrity, and the Tic’s serial interface is not guaranteed to work with 3.3V signals. In our tests, 3.3V signals worked anyway, but you might need some logic level shifters to ensure reliable communication. If you do need to receive data back from the Tics, the TTL serial interface would require external AND gates, as described in the “Setting up serial control” section of the Tic user’s guide.
Brandon