2023-07-08 03:56 PM
I am using the p-nucleo-ihm03 package but with a different motor and a quadrature encoder (AMT-103).
The motor runs perfectly fine in sensorless mode but I need a way to switch the direction very fast which does not work with sensorless as there is at least a 500ms delay between running a speed ramp, stopping the motor and reversing the direction.
Well, I had the bright idea maybe a closed loop control with an encoder might help but the motor does not move. It does move, but MAYBE once for whatever reason and is otherwise locked the entire time. While it's locked it's pretty noisy so there is current flowing in I guess. Changing PID gains just changes how loud the noises are so I have absolutely ZERO clue why the motor is not moving. I really need a way to switch directions as fast as possible and I can't seem to get the encoder work.
I did not find anything in the documentation. Can someone help here? I am also limited with the tech here as I don't have an oscilloscope at home (just a broke student here). I tried another encoder and read both values out and the encoder seems to work perfectly fine.
2023-07-10 06:15 AM
Hello UmutU,
First of all, the idea to use the encoder to solve your primary issue should be working fine. The use of the encoder should be enough to switch from positive to negative speed quite easily.
As I lack information to help you entirely, I would like to ask you a few preliminary questions :
- Which version of the MCSDK are you using to run your motor ?
- Have you enabled the Encoder mode via Workbench before generating the project ?
- If it is working in sensorless mode, I suppose your motor is correctly profiled with a .json file corresponding. Is it the case ?
Concerning the encoder, while waiting for your answer, please make sure the encoder is correctly plugged. You can check your motor specifications as well as the layout of the IHM16 board to know if this is the case.
Hoping this will help,
Gaël A.
2023-07-11 01:13 PM - edited 2023-07-11 02:06 PM
Motor Control Workbench is 5.4.8
STM32CubeIDEVersion: 1.11.0
Yes, I profiled with the motor profiler. The motor does not have a datasheet, at the very least I didn't find anything online (nor anyone else who used it). The encoder mode is set via Workbench and it also shows values accordingly when rotating the encoder with the motor by hand. Values go up to 359 degrees so that should be fine I guess? Not sure to be honest.
As an Encoder I use the AMT103 if that helps. I am not sure if the start up/drive parameters are good enough for encoder
2023-07-12 12:42 AM
Hello UmutU,
You are using a quite old version of the MCSDK, would you consider upgrading to version 6.1.2 (except if you are using Windows 7, which is not supported anymore) and generating a new project ?
Otherwise, if the encoder is correctly set and powered, I don't see why the system is not working. Have you made any change to your code ?
Regards,
Gaël A.
2023-07-12 09:53 AM
I would consider, if it wouldn't be so unstable. This might sound stupid but maybe the pins I have chosen on the IHM16M1 are wrong? If there would be some kind of tutorial for interfacing that thing (ihm16m1) with encoders or halls it would make it a lot easier as a beginner kit to be honest. Is there a chance that ANYONE could post a picture of a quadrature encoder interfaced with the expansion board and showing which encoder parameters are chosen in the motor control workbench?
2023-07-13 06:54 AM
Hello UmutU,
You will find attached a few pictures that (I hope) will help you understand a bit better how to enable the encoder via Workbench, and how to plug the encoder to the right pins of the IHM16 powerboard. The two last screenshots come from the IHM16 User Manual that can be found here pages 5 and 9.
How to enable Encoder mode via Workbench. Current sensing does not need to be changed.
The location of the 5 pins used for Encoder (and Hall Sensors) on IHM16M1.
Table of what should be plugged to each pin. Keep in mind that the order is important.
Hope this will help,
Gaël A.
2023-07-13 01:01 PM
Thanks for these pictures! I have it exactly like that, so the issues might lay here: Either my motor parameters are not good enough or the encoder parameters are wrong or both. I guess I have to keep trying...
2023-07-13 01:28 PM
I found out, if I move the encoder (rotate it on the motor) the motor starts moving. So it seems the software expects encoder values to move the motor but stops when I stop moving the encoder. I don't know what that means to be honest..