@willson @Jonathon
I am new to dynamixel and am learning the system by playing with everything.
I notice that dynamixel can be set to have min and max limits when operating in joint mode, this is agreat feature as you can set limits to stop the dynamixel trying to turn past the joinitn limit of your robot.
I have noticed that if I try to set a goal position outside the limit value will cause the dynamixel to do nothing at all rather than moving towards the goal position but stopping at the limit by truncating the goal position to the limit.
This means in my program I have to be testing if the position is out side the limit and truncate it or the dynamixel doesn’t move which sort of makes the feature obsolete to a certain extent as I now still have to truncate it in my software anyway.
Can I put in a feature request for next dynamixel firmware that if a goal position is set out side the limit positions then the dynamixel will travel towards the goal position and just stop at the limit position??
So far I had not found the need to use the Multi-turn mode or formally the Extended Position Control Mode of the XL430 series:(XL430-W250-T). Would that suit your purpose?
@roboteer I was using the normal mode fro operating joints. reg 10 = 0 and reg 11 = 3
When using the face tracking in the demo program that I made it is possible for the kids to move their face or for the robot to think there is a face that makes it try to move to a position that can past the physical limit of what the joint so I set limits in reg 48 and reg 52.
If I set these limits and the face was past the limit, the program would set the dynamixel to this position outside the limit and the dynamixel would do nothing at all rather than move towards the face but stop at the limit. So I then had write in my code to check whether the position the face tracking was tying to set was out side the limit and if it was truncate it down to the limit which nearly makes setting the limit on the servos obsolete. The only advantage of setting the limits of the dynamixel will be as a backup safety if something goes wrong in my program.
In my opinion it would be an improvement to the dynamixel firmware to have a slight change to the behavior to: if a goal postion is set that is out side the position limit then the dynamixel will move towards the goal position but stop at the limit rather than do nothing at all.
@Out_of_the_BOTS
OK I think that I understand your situation better now, so your user limits were set within the “legal” limits [0-4095], let’s say 1000 and 3000, but if you set Goal Position to 900, the XL430 just does not move, instead of moving to 1000 and stop there? Right? Then I agree with you. The Registers 48 and 52 would not serve any real purpose. Except as a pre-move check for a GO or NO-GO procedure.
For my case, I had always implemented similar limits in software (before I used my Goal Position commands) so I did not run across this issue.
1 Like
@Out_of_the_BOTS
There are several controversial subjects and I think this is one of them.
In some cases, preventing the motion when out of range value is received is critical for safety reasons while your design can be enhanced with stopping at the min/max position feature.
DYNAMIXEL modules are widely used in various fields such as medical, aerospace applications so please understand our somewhat conservative stance about adopting a new feature.
However, DYNAMIXEL dev team keeps collecting feedback from customers and passionately discuss them for possible updates so I’ll make sure your voice heard.
Thank you very much!
1 Like
@willson
Ha Ha yer I am playing with the toy version. I ask for update and breaks everyone’s else’s professional machine 
After thinking about it I think I understand Robotis reasons for why the limit works in this way.
My request was for it to move towards the limit then stop at the limit because I wanted to be able to be lazy with my coding and not have to write code to check for limits.
In professional industry the developer will always write their own high level checks that should never request a position outside the limit so if the servo gets a request for a potion outside the limit then something obviously when very wrong and for the servo to do nothing at all is safer.
@Out_of_the_BOTS
You are right. High end systems are very well designed for fail safe.
DYNAMIXEL by default returns an error when a received value is out of predefined range, and changing this policy may unexpectedly affect other systems so we are very cautious about the aftermath of any changes of default behaviors.
Please don’t take my words wrong. What I meant wasn’t a rejection of your idea, but was a proposal toward our dev team as we have been improving DYNAMIXEL based on feedback from customers.
Thank you for your understanding.