Hi tlemarec,
you might be right, this could be a wiring problem.
There is no specific a-priori way to determine the correct wiring. Here is the procedure we use to determine a good wiring setup:
Initially, you need to do is settle on one set of wiring for the three phases (choose at random). If it’s the correct wiring, the motor will work as expected. If it’s not the correct wiring, the motor will not rotate. In addition, it will lock on to certain angles when you try to rotate the motor by hand. In this case, switch any two connections of the three wires. This should resolve the problem.
Given that the motor heats up, this might be an indication that the motor is wired wrongly.
A word of warning: Do not switch the motor wires while the cards are powered on. This can damage the motor driver board.
Best,
Julian
Hi @jviereck,
I plugged another motor module (an even a third one) and I am getting the same behavior :
The encoder works fine but sending torque command does not work : the motor does not react and the read current values continues to be just noise.
Edit :
Still no success sending current command frame using the can bus or activating spring mode with the can bus. But activating spring mode in the firmware then flashing the launchpad works.
From this point :
enable the motor → the spring mode should kick in → test if the motor is wired correctly by rotating it by hand, if it is not wired correctly, the motor will lock onto certain angles, very easy to feel with the hand → to correct the wiring, just switch 2 cable and test again.
When trying to determine if the wiring is correct do you confirm that just switching 2 cables (one time) when the wiring is wrong should fix the issue ?
If I understand it correctly : The only problematic wirings are mixed phases like : A C B. All other permutation are correct as long as the circular order is respected?
Edit : Validated. One switch is enough. If the motor is still not behaving correctly, this is more than a wiring issue.
During the init phase, when rotating the motor by hand, it locks onto certain angles and no amount of cable switching seems to solve this issue. Is it a normal behavior for the init phase or is it likely the wiring is not correct ?
Edit : Yes, a correctly wired system will lock onto certain points during the init / calibration phase. Testing if the wiring is correct cannot be done during the init phase.
On a side note : It is indicated in the doc that the can timeout is deactivated by default. Can you confirm it ? Because if it is not, this might be the issue as I am only sending anecdotal current command frames !
Edit : this seems unlikely because in this case the status code sent from the board should indicate error 2 : CAN Receive Timeout, which is not the case.
I will install the blmdc c++ driver on a real time pc and test if I can send current command using it.
Cheers,
Titouan
Hi Titouan,
it looks like you figured out most of the problems yourself 
That’s great! Your edits make a lot of sense to me.
One thing: When flashing the firmware and running the code, make sure you have the right “dip” settings for the cards: open_robot_actuator_hardware/README.md at master · open-dynamic-robot-initiative/open_robot_actuator_hardware · GitHub
Testing the setup with the C++ code sounds good. Let me know how it goes.
Best,
Julian
1 Like