I have been struggling to keep my motors energized and I can’t figure out which commands to use to keep them as such without interfering with other commands. For reference I am controlling 3 T500’s over i2c on a Pi 4b using the ticlib python package. I need my stepper motors to stay energized so they don’t get pushed off the buttons they are supposed to be holding down. I have tried many different things and I am getting very inconsistent results. I have tried sending energize and exit safe start commands on loop every second but it seems to interfere with the other commands I am sending and it appears that sending commands too quickly can confuse the drivers and cause them to behave erratically. Is there a setting I need to change to enable easier control or should I up the baud rate? My current code is frankly too long and uncommented to post in it’s entirety but I can post bits as best as I can if asked.
Hello.
Without more information, it is hard to say what is causing the Tics to de-energize. If you haven’t changed the default settings, my first guess would be that the command timeout is triggering. By default, the Tic’s command timeout error will happen if it does not receive certain commands periodically. You can find more specifics about it in the “Error handling” section of the Tic user’s guide. To avoid this, you could send a reset command timeout command every second, or you can adjust the command timeout length or disable it completely in the “Serial” box under the “Input and motor settings” tab of the Tic Control Center.
If that is not the cause of the problem, could you check if they are triggering an error when they de-energize (indicated by the red LED on the board)? If so, could you connect them to the Tic Control Center and see which errors have been triggered?
Brandon
I have the board that is giving me issues connected to a pc over usb for debugging while it is being driven over i2c and I even disabled command time out and it still is encountering a safe start violation. I am not sure why? I have even verified going line by line using python debugging that it will encounter a safe start violation even if no commands are given to it even though command command timeout is disabled?
While in “Serial/I2C/USB” control mode, the safe-start violation will generally trigger whenever the Tic is not in the normal operation state. Could you monitor the “Status” tab of the Tic Control Center while your program is running, then when the problem happens take a screenshot and post that here? Does the “Count” for any of the errors increase at all (are any of them non-zero other than safe start violation)? You can see the count in the “Errors” box under the “Status” tab.
Brandon
I appear to be getting a motor driver error I simply wasn’t noticing before. I thought I went out of my way to choose part explicitly capable of delivering the power I intended, but clearly I don’t know what I am doing. So let me just run through my settings so you can tell me if anything sticks out as clearly too much.
I am using a T500, current limit 1452 mA, 1/8 step, 16,000.0000 pulses/s max speed, 64,000.00 pulses/s max acceleration, open air testing currently, no heat sinks, 70F ambient air, plan to eventually put in raspberry pi enclosure with small fan to help circulate air.
Motor is McMaster-Carr
Two phase bipolar, 4 wire leads, connected as: A1- Green, A2-Green/white, B1- Red, B2-Red/white
Claimed:
Maximum Current per Phase =1.5 A
Resistance per Phase = 1.56 ohms
Inductance per Phase = 1.9 mh
Actual stepper motor is Hayden-Kerk 43H4B-2.33-920
Power supply: AC to DC 12V 25A capable, Single rail, 12AWG main wires split 9 ways to aluminum 22 awg wires going to the 9 individual T500s; however, only 3 are being powered during this debugging stage. VIN on TiC control center reads a quickly variable range centered on 12.4V: 12.0V-12.6V while running
Hello
I don’t see any obvious problems with that combination of components.
Are all 3 of the Tics in your system triggering motor driver errors? For the Tic T500, the motor driver error indicates an over-current, over-temperature, or over-voltage condition. As a test, you might try reducing the current limit to something much lower like 1A per phase to see if that changes anything.
Brandon
Yes it turned out all three were triggering the error, but they were being affected differently for some reason. So I ended up reducing the current limit to 1A in the control center and that fixed it. So I raised it and it continued to work so I raised it some more until I was back at 1452 and it still worked.
What I ended up figuring out was that in my code I wrote a loop during setup to ensure all my control boards had the right settings because I was swapping back and forth between a couple during my initial debug and wiring phase. It turns out I was trying to set the current limit to 1452mA and I thought the library I was using accepted it in mA like the settings file. Turns out it was just a convient i2c command directory library so basically I was accidentally setting the current limit to the absolute max when I should have been setting it to 13 and because auto error clearing was enabled I never noticed when I wrote the code and forgot to debug that part since it appeared to work.
Thank you for the help!