Hi
I don't know anything about the inner workings of EMC. I do know a bit
about control systems. I think I understand the question raised here.
If you want to combine the measured joint position and use this
information to figure out what the motor needs to do to maintain control
of the joint in the presence of backlash and hystersis, you need more
that a couple of PID controllers. This assumes you are seeking maximum
performance.
The way to do this is to model the relationship between the joint and
the motor. The model is then used to predict what the motor has to do
in order to get the joint to where it is supposed to be. The model is
compared to the measured position and feedback is used to make
corrections to the model (to stop it drifting away from reality).
Predicting where the joint will be depends on it's current position,
velocity, acceleration, position in the hystersis loop etc. Arriving
at a control solution (ie figuring out what command needs to go to the
motor) is an iterative problem. For this reason, this approach
requires a lot more computational horse power than PID loops.
To do a really good job also requires including the load in the model.
I light cut on a tool (low load) will place the joint in a different
part of the hystersis loop compared the same path with a heavy cut (high
load).
There will be statistical errors (noise) in the measurement of the joint
position, the load and the control system. In the presence of noise,
the Kalman filter provides an optimal estimate of the joint position.
Maximising the value of the available information requires good quality
modeling of the system and some heavy duty maths to match.
I don't know if EMC can include this type of control loop. Even if it
does, it would not be a trivial task to tune.
Regards
Darren Conway
Brian wrote:
Ok, I think I may have a perspective that will be clearer.
In the HAL component axis, joint position and motor position are
thought of as separate concepts. Joint position is related to motor
position through the compensation logic, but otherwise they are their
own entities. This is good design, because in reality, joint position
and motor position are truly two different measurements. There is not
always a 1:1 relationship between motor position and actual joint
position. Besides lash and screw wear, you can have belt stretch, and
machine deflection among other things that can affect the actual joint
position. Up until now, joint position has simply been inferred based
on the motor position plus any known amount of compensation. This is
a good estimate of joint position when no other feedback is available.
Because axis already separates the concepts of motor position vs.
joint position, it would seem natural to have a provision for reading
actual joint position if available, otherwise, simply substitute the
inferred value based on motor position. This would more closely model
reality in a machine.
Does this make more sense?
Brian
On Sun, Aug 8, 2010 at 12:51 AM, Brian <[email protected]> wrote:
Jon,
If I had encoders on the screws, the method described on the wiki
would work. This is basically what Dave suggested a few replies back,
and what my config already does to some degree. This method will also
work with steppers, until the motors are disabled, and you move the
machine by hand. Then the wiki method no longer holds water. Trust
me, I have tried lots of different things to come up with a usable
solution without modifying anything. I have thought this problem up
and down, to no avail.
With respect to backlash being a significant hindrance to my CNC
system, it is a problem, but with a full screw map, it really isn't a
huge deal. It is plenty accurate surprisingly so as a matter of fact.
Because I still use the machine manually, I am not planning on
changing over to ball screws. Moreover, the fact that I use a machine
that has acme screws with lash is not a good reason not to allow EMC2
to correctly utilize the data available to it.
Why is there so much resistance to this? I must not be effectively
explaining the situation. I suspect in person, I could better
describe the benefits to making it work the way I propose. Over email
however, it just doesn't seem to be hitting home with anyone. Heck, I
would take this on myself and submit it, but I don't have the time to
learn EMC internals just to implement this. Especially when I know
there are people who already know EMC inside, and could probably
implement such a change without a lot of trouble.
Brian
On Sat, Aug 7, 2010 at 11:11 PM, Jon Elson <[email protected]> wrote:
Brian wrote:
I may give that a shot as a band-aid to the problem. I suspect that
when reversing direction, the backlash is going to drive the PID nuts
and cause the table to jerk.
If you have sizable backlash in your machine, then it becomes very hard
for any CNC system to work right, either open- or closed-loop.
The problem is the motor can't get from one side of the backlash to the
other instantly, so it always leaves the axis uncontrolled for a
moment. There is just no way to get around that fact.
I appreciate everyone's interest to find a workable solution for me,
but what I would like to focus on more is making EMC2 a more logical
and 'unified' system. Specifically adding the option to use a direct
reading scale for joint-pos-fb, instead of inferring this from the
motor position minus the screw comp. Lots of robots and machines use
a direct reading scale for measuring joint position, in addition to
having a scale on the actual servo motor. I really think there should
be a provision to utilize it, the way it was intended to be used.
Honestly, looking at the architecture of the axis HAL pins, I am
surprised that it hasn't been implemented already.
This has already been done, and is well documented on the Wiki. You can
start
here :
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Combining_Two_Feedback_Devices_On_One_Axis
Stuart Stevenson may also have some info on his web pages, he has the
first machine done that way.
Here's one link to that project, from the Linuxcnc.org links area :
http://jmkasunich.com/cgi-bin/blosxom/shoptask/wichita-trip-02-20-08.html
Jon
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.851 / Virus Database: 271.1.1/3057 - Release Date: 08/08/10 06:12:00
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
