Help
I have a couple MOTM_2 Motionmind motor controllers hooked up to some gear motors with a 500cpr encoders. The controller are missing counts and the motors are over shooting the desired real world positions.
I have the encoder and motors wires pretty short, about 5 inches. Are there any other things I can do to improving encoder performance?
Thanks,
Daniel
Page 1 of 1
Controller Missing Counts
#2
- Advanced Member
-
- Group: Root Admin
- Posts: 640
- Joined: 03-March 04
Posted 05 June 2009 - 05:18 AM
Daniel,
There could be a number of things to look at. You should tell us more about what mode you;re operating in and how you're determining that counts are being missed. Here are some things to consider...
1) If operating in a mode where the control signal is analog, the controller has only 1024 discrete steps. This limits resolution and can cause discrete position errors to be noticable.
2) Mechanical slippage could causes errors in the load's position over time. Abrupt starts and stops could contribute to this, and you might be able to eliminate this problem with velocity limits and/or increasing your derivative gain. If mechanical slippage is the problem, then you need some method of homing the controller on a regular basis. Not knowing your system it's hard to recommend a method.
3) Make sure the controller is actually reaching the desired endpoint. If the integral gain is too low, or the controller is not allowed enough time to adjust into the final position, then it may not be able to reach a specific point before a new move command is given. This could appear as an error as you watch the load move.
4) Verify that your encoder is good. The easiest way to do this is try to use a different encoder of the same make/model to see if the issue continues.
5) There could be a firmware issue in the MOTM2. However, the firmware has been stable for a couple of years with no reported errors in position reported by customers. We test the system by connecting a separate encoder to the shaft of a motor under control. We then verify that position counts read on the control encoder match the motor under test. I'll run this test again next week on some units we have on the shelf.
6). There could be a hardware issue. If you're having this problem on two MOTM2 units and two encoders then it is unlikely that there is a single manufacturing or hardware fault that is contributing to the problem. But there could be an issue with the encoder to MOTM2 interface. Some encoders have open collector outputs on channels A,B, or index. These need to be pulled to 5V by external resistors. We have 100K ohm resistors on the PCB that pull up the encoder lines (page 10 of datasheet). Verify that your encoder does not need stiffer pull-ups (like 4.7K) if it is open collector.
Lon
There could be a number of things to look at. You should tell us more about what mode you;re operating in and how you're determining that counts are being missed. Here are some things to consider...
1) If operating in a mode where the control signal is analog, the controller has only 1024 discrete steps. This limits resolution and can cause discrete position errors to be noticable.
2) Mechanical slippage could causes errors in the load's position over time. Abrupt starts and stops could contribute to this, and you might be able to eliminate this problem with velocity limits and/or increasing your derivative gain. If mechanical slippage is the problem, then you need some method of homing the controller on a regular basis. Not knowing your system it's hard to recommend a method.
3) Make sure the controller is actually reaching the desired endpoint. If the integral gain is too low, or the controller is not allowed enough time to adjust into the final position, then it may not be able to reach a specific point before a new move command is given. This could appear as an error as you watch the load move.
4) Verify that your encoder is good. The easiest way to do this is try to use a different encoder of the same make/model to see if the issue continues.
5) There could be a firmware issue in the MOTM2. However, the firmware has been stable for a couple of years with no reported errors in position reported by customers. We test the system by connecting a separate encoder to the shaft of a motor under control. We then verify that position counts read on the control encoder match the motor under test. I'll run this test again next week on some units we have on the shelf.
6). There could be a hardware issue. If you're having this problem on two MOTM2 units and two encoders then it is unlikely that there is a single manufacturing or hardware fault that is contributing to the problem. But there could be an issue with the encoder to MOTM2 interface. Some encoders have open collector outputs on channels A,B, or index. These need to be pulled to 5V by external resistors. We have 100K ohm resistors on the PCB that pull up the encoder lines (page 10 of datasheet). Verify that your encoder does not need stiffer pull-ups (like 4.7K) if it is open collector.
Lon
#3
- Starting Member
-
- Group: Members
- Posts: 1
- Joined: 04-December 09
Posted 14 December 2009 - 12:57 PM
dosteen, on Jun 4 2009, 10:20 PM, said:
I have a couple MOTM_2 Motionmind motor controllers hooked up to some gear motors with a 500cpr encoders. The controller are missing counts and the motors are over shooting the desired real world positions.
I have the encoder and motors wires pretty short, about 5 inches. Are there any other things I can do to improving encoder performance?
Thanks,
Daniel
I have the encoder and motors wires pretty short, about 5 inches. Are there any other things I can do to improving encoder performance?
Thanks,
Daniel
I am seeing similar problems on the MOTM3 using a 2000 cpr encoder at 3 revs per second. When we slow down, it gradually gets better. The datasheet shows a max encoder frequency of 1.75 MHz. What is the practical limit in Serial PID mode?
#4
- Advanced Member
-
- Group: Root Admin
- Posts: 640
- Joined: 03-March 04
Posted 17 December 2009 - 08:58 AM
I apologize, I thought I responded to this on Monday (14th) but just noticed that it didn't post.
A 2000CPR encoder rotating 3x per second is only 6000Hz. That should not reach any limit of the MOTM3's ability to cathc pulses. The hardware decoder is specified for 1.75MHz, the microcontroller's limit would be 65535 counts in 5ms. I'm sure there are timing limits that could kick in on the microcontroller side, I'm also sure that they would be much higher than 6000Hz.
Is your motor geared? If so you would have to multiply the gear ratio by the CPR to get counts per revolution, and if you're using 4x mode you'd have to account for that as well.
You should also take a look at the hardware connecting to the encoder on the MOTM3 (page 10 figure 3). If your encoder is open collector you might need smaller pull up resistors to accomodate faster rise times of the CHA and CHB signals.
Can you give me a rough estimate of the kind of errors you're seeing, and have you tried to validate your hardware in any way? We connect a test encoder to the output shaft of our motors under test. This allows us to move to a specific position and check to see how well the test encoder tracks the movement. Even our system which is a simple shaft-to-shaft coupling has some error in it, but it is typically very small.
Lon
A 2000CPR encoder rotating 3x per second is only 6000Hz. That should not reach any limit of the MOTM3's ability to cathc pulses. The hardware decoder is specified for 1.75MHz, the microcontroller's limit would be 65535 counts in 5ms. I'm sure there are timing limits that could kick in on the microcontroller side, I'm also sure that they would be much higher than 6000Hz.
Is your motor geared? If so you would have to multiply the gear ratio by the CPR to get counts per revolution, and if you're using 4x mode you'd have to account for that as well.
You should also take a look at the hardware connecting to the encoder on the MOTM3 (page 10 figure 3). If your encoder is open collector you might need smaller pull up resistors to accomodate faster rise times of the CHA and CHB signals.
Can you give me a rough estimate of the kind of errors you're seeing, and have you tried to validate your hardware in any way? We connect a test encoder to the output shaft of our motors under test. This allows us to move to a specific position and check to see how well the test encoder tracks the movement. Even our system which is a simple shaft-to-shaft coupling has some error in it, but it is typically very small.
Lon
Share this topic:
Page 1 of 1