Menu

Topic-icon Closed loop posiiton behaviour has changed!

  • Gabriel_Isko
  • Gabriel_Isko's Avatar
1 year 9 months ago - 1 year 9 months ago #29533684 by Gabriel_Isko
Replied by Gabriel_Isko on topic Closed loop posiiton behaviour has changed!
I still have to do some more testing, however I think the major issue with your setup is that you have the acceleration for your motor output is extremely low.

The trajectory planning does seem to have changed in count position mode to make the motion more governed by PID. the new count position trajectory forgoes any motion planning and simply just tries to achieve the given counter value. At the low resolution of your system and with your extremely small acceleration/decceleration values, the controller cannot react to the sudden change in trajectory and overshoots.

Internally, we are discussing changes to be made to our motion planning implementation in our firmware. These changes will make our planning more transparent and accessible for users. However, we are currently focusing on features regarding motor auto calibration and setup for our next release. Motion planning will not be a development priority until at least after the release of 1.9.

For now, there are a few workarounds for your application:

1) Use Position Relative mode. Since the motion range of your system is bounded, this is the recommended mode of operation for your application. It will be much simpler to achieve the desired motion in this mode since it will complete the proper motion planning automatically.
2) Increase your Acceleration and Deceleration, and re-tune your PID. This is less recommended since it is technically not a "correct" solution, however you will certainly be able to get better performance with higher acceleration values.
3) Implement your own motion profile with feed-forward control using the !PX command in MicroBasic. This is technically the correct answer if you are dead set on using position count mode, but it will require a lot of work to implement.

Please Log in or Create an account to join the conversation.

More
1 year 9 months ago #29533685 by rfrancis
Thanks for this information. I will look into these workarounds.

I understand that the low acceleration is an issue, but given the low encoder resolution and the weight of the moving object (> 1 tonne) combined with the details of the power-transmission system, there is no alternative.

Today I have rechecked the motor, and as I stated earlier, there is no possibility to mount an encoder before the gearbox. This is a high-current, high-torque winch motor designed for semi-industrial use, and not for high-precision positioning.

thanks,
Richard

Please Log in or Create an account to join the conversation.

More
1 year 6 months ago #29533983 by rfrancis
Hi Gabriel,

sorry for the very long time responding, but I have had lots of jobs to do in the meantime.

I have decided to replace the encoder with a higher resolution one. The current one is 24 counts per revolution, and I can replace it with commercial units of up to 8000 counts per revolution.

You have said that my acceleration is very low, which it is, due to the low encoder resolution and the slow real acceleration of the system. What would be a typical acceleration for the controller (in terms of counts per second per second)?

thanks,
Richard

Please Log in or Create an account to join the conversation.

  • Gabriel_Isko
  • Gabriel_Isko's Avatar
1 year 6 months ago #29533984 by Gabriel_Isko
Replied by Gabriel_Isko on topic Closed loop posiiton behaviour has changed!
The recommended encoder PPR would be 1024 or ~1000. By default, our controllers are configured for a max acceleration 2000RPM/s, so that is a good starting point.

Please Log in or Create an account to join the conversation.

More
1 year 5 months ago #29533999 by rfrancis
Thanks for your quick reply Gabriel.

I followed your advice, but unfortunately made an error ;-(

I bought a US Digital encoder, and knowing the CPR/PPR relationship (CPR = PPR*4) I bought an encoder with 8192 CPR, to give me a PPR of 2048 (a bit higher than you recommended).

Unfortunately US Digital use a different terminology, so for them CPR is cycles per rev, so equal to the usual PPR. So now I have a Counts per Rev of 32768. In terms of my system that's not too bad (max speed 55 RPM) -- it's still a maximum count rate of just over 30k, so within the controllers capability.

However, the max value I can set PPR to in the controller is 32767.

I think a way out of this is to redefine everything in half revolutions (PPR, max speed, acceleration and operating speed). What do you think?

thanks,
Richard

Please Log in or Create an account to join the conversation.

  • Gabriel_Isko
  • Gabriel_Isko's Avatar
1 year 5 months ago #29534002 by Gabriel_Isko
Replied by Gabriel_Isko on topic Closed loop posiiton behaviour has changed!
Yes, you can try that. Just divide your PPR by two and cut all your RPM speed settings in half.

Please Log in or Create an account to join the conversation.

More
1 year 5 months ago #29534012 by rfrancis
Thanks Gabriel, but in fact there's no problem. I was a bit quick to raise the issue. A bit more thought showed that the PPR (what US Digital calls CPR) is 8192, so well within the limit.

cheers,
Richard

Please Log in or Create an account to join the conversation.

Moderators: tonysantoni
Time to create page: 0.110 seconds
Go to top