RE: New .ini entries, [AXIS_#] DEADBAND, MAX_VELOCITY

["Tim Goldstein" <tgoldste-at-mlh-services.com>]

I have been using the MAX_VELOCITY since the Feb. 25 release and it seems to
work great with limiting things in rapid moves. The only thing I would
mention is that it has no effect on jog moves or G1 moves. Meaning that if
you have 2 axis's that are good to 60 ipm and one only to 48 ipm you have to
limit your jog speed and G1 moves for the slow axis manually. I don't think
it is a problem, but I was a little surprised to find I could explicitly
drive the axis faster than the individual axis MAX_VELOCITY parameter
setting as long as it was under or equal to the global MAX_VELOCITY
parameter setting.

Regarding the problem with hunting, I have the deadband set to 0 and am
having no hunting.


Tim
[Denver, CO]

timg-at-ktmarketing.com <timg-at-ktmarketing.com>
http://www.ktmarketing.com



> -----Original Message-----
> From: emc-at-nist.gov [emc-at-nist.gov]On Behalf Of Fred Proctor
> Sent: Wednesday, March 01, 2000 7:03 AM
> To: Multiple recipients of list
> Subject: New .ini entries, [AXIS_#] DEADBAND, MAX_VELOCITY
>
>
>
> EMC users,
>
> The 29-Feb-2000 distribution introduces two new .ini file variables in
> the [AXIS_#] sections, DEADBAND and MAX_VELOCITY. You'll need to add
> these to your .ini file; see generic.ini for an example.
>
> 	[AXIS_#] DEADBAND = <non-negative float>
>
> sets the error tolerance between commanded and actual position, below
> which the error is set to zero. This is intended to prevent hunting
> about a pulse. The default is 0.0, meaning it has no effect and any
> error will drive the PID a bit.
>
> The EMC now generates positions rounded to the nearest input step,
> either encoder count or stepper motor count. So, hunting should not be a
> problem. It can kill small oscillations due to agressive servo
> parameters.
>
> The other .ini file addition,
>
> 	[AXIS_#] MAX_VELOCITY = <positive float>
>
> sets the rapid rate for each axis, independently. I tested this briefly
> and it worked for me, but please test this and report any problems. It's
> intended to allow you to set a smaller value for the rapid rate for your
> lowest-performing axes, so that if they are not moving during a rapid
> move the other axes can move at a faster rate.
>
> For example, if you have a Z axis that can only rapid at 20 ipm (=0.333
> inches per second), and your X and Y axes can rapid at 120 ipm (=2.0
> inches per second), you should do:
>
> [AXIS_0]
> MAX_VELOCITY = 2.0
>
> [AXIS_1]
> MAX_VELOCITY = 2.0
>
> [AXIS_2]
> MAX_VELOCITY = 0.333
>
> If X and Y move equal distances during a rapid, their rate will be 120
> ipm each, and the effective tool tip rate will be sqrt(120*120 +
> 120*120) ipm, or 168 ipm. If Y moves a shorter distance, it will be
> slowed to arrive when X arrives, but the overall time for the move is
> the same as if they both went at 120 ipm. At this point it's more
> difficult, believe it or not, to have them move independently at their
> rapid rates and arrive at different times.
>
> The way this is done is by computing the time each axis would take if it
> moved the prescribed distance at its own rapid rate, then taking the
> longest time, computing the equivalent tool tip rapid rate for the total
> tool tip distance for this time, and doing a linear move at that rate.
>
> The existing .ini parameter, [TRAJ] MAX_VELOCITY, is used to limit the
> overall tool tip velocity. Make it twice the max axis rapid and your
> axes will always run their fastest.
>
> --Fred