Re: dispatcher function questions
garrett beaubien wrote:
> When I start EMC, and “home” the
> axis, the commanded position keeps increasing (even
> beyond the soft limit in the emc.ini file).
This is what should happen. The soft limits don't kick in until an axis
has been homed, since their values are relative to the home position. If
the axis hasn't been homed, their values are meaningless. We could
decelerate to the soft limit even if the axis hasn't been homed, but
you'd notice that the physical location of the axis wasn't anywhere near
where the soft limit normally stops it.
> I have
> narrowed this problem down to my extEncoderReadAll
> function. If I set the axis position to a constant
> value (ie *counts[0] =128.0; *counts[1] = 0;
> *counts[2] = 0;), I can home the axis.
Forcing the axis values to a constant, then commanding a move, will
cause the EMC to generate commands to the servos that follow the ideal
trajectory, and the servos will see no feedback (stationary axes), and
increase the output according to the P gain. If all you have is a P
gain, you'll see the motion speed up until the following error limit
kicks in. This is exactly what would happen if the encoders became
disconnected.
If you have a velocity feedforward gain ([AXIS_#] FF1), and the P gain
is small, then the output to the motors will depend mostly on the
computed velocity. This will make it seem like the machine is moving
fine, even with no (or forced constant) feedback.
> When I try and
> read the value from the actual hardware, (ie
> *counts[0] = inb(257); *counts[1] = 0; *counts[2] =
> 0;), the axis will not home. For both of these test
> compilations, the rest of the code is identical. I
> coded the function that reads the home switch to
> always return a 0. I guess I should mention I only
> have a single axis with hardware, but the emc.ini file
> has 3 axes.
What kind of encoder board do you have? Are you sure you can read valid
feedback from it? When you do this:
*counts[0] = inb(257);
this looks like you're trying to read a byte of data at I/O address 257.
One byte of data is quite small for position feedback. inb() also
returns an unsigned byte, so you'll get values in count[0] from 0.0 to
255.0, in 1.0 increments.
> How does EMC “home” an axis? I thought that it would
> just output a drive to the axis of interest, and keep
> polling the home switch, and would home (turn green)
> when the switch value was of the same polarity as that
> specified in the emc.ini file? Does EMC care about
> the encoder value counts during this operation? Could
> it be that there is a problem with my function, and my
> encoder values are constantly changing, making it
> impossible to home the axis?
Yes, absolutely. The EMC homes an axis not by outputing an open-loop
value to the DAC, but by planning an accel-cruise-decel move at the
homing velocity to a point outside the machine's limits. The point is
the initial position plus the entire range of the axis, so it's
guaranteed to be outside the range. If you have no encoder feedback,
you'll have at least two problems: the axis won't be controllable (it
will run away), and when you home, the invalid encoder value will be
used as the offset position. Your encoders have to work for anything
more to proceed.
> Would it be possible to insert an rtl_printf statement
> into these dispatcher functions? I think that I would
> have to substatially increase the scan times (or else
> rtl_printf may crash the system?), but then at least I
> could see what the encoder values actually are. I
> tried to insert this statement into the function, and
> put a #include<rtl.h> at the top of the file, but the
> compiler complained when I did a make PLAT-rtlinux_2_0
> all. Is there any way to print or log values?
I don't know about rtl_printf. You can try this. Even better would just
be to run the process as a normal Linux process and read the encoder. It
won't be real time but you can see if your numbers change when you turn
the shaft. The dro.c code in emc/src/emcmot does this for the DRO board.
--Fred
Date Index |
Thread Index |
Back to archive index |
Back to Mailing List Page
Problems or questions? Contact