CAD CAM EDM DRO - Yahoo Group Archive

Re: MAX-VELOCITY global = bad

Posted by Jon Elson
on 1999-12-02 09:41:24 UTC
Clint Bach wrote:

> From: Clint Bach <clintbach@...>
>
> Ouch!!!
>
> MAX_VELOCITY not being on a per axis basis can be severely limiting. On
> my machine X and Y are cable drives and Z is a lead screw drive with a
> completely different motor and everything. Z will never be as fast as X
> and Y without a complete rebuild... If I were to add the planned rotary
> table it may (or may not!) even be as fast as the z axis is now. This
> could drag the machine down to a crawl for no good reason. My AHHA
> control has individual maximum velocity settings on each axis so it
> isn't a problem normally. It just slows down when needed.
>
> In my opinion per axis MAX_VELOCITY settings should be on the very top
> of the "What do we want" list! I guess that with a little creativity a
> work around could be done. In my case I could set the max_velocity to
> the speed limit of the X and Y axes and use a feed rate command whenever
> I move Z at maximum rate. It wsould work but what a pain.

I really want to second this opinion. On my machine right now, it is not
a problem, mostly because all my axes are pretty fast. But, I'm planning
on adding a rotary axis, which means apples and oranges are being referred
to by the same limit. Having to set velocity in degrees and inches per minute
sounds bizarre!

The one (or two) odd things is how to set the jog speed. Let's say the
linear axes handle 120 IPM, but the rotary can only do 60 degrees/min.
If you set the jog speed to 100 (units), and jog the rotary axis, what do you
do? I think the most sensible is to just act as if the jog speed were set to
the maximum for the axis currently being jogged (if the commanded speed
exceeds the max for that axis) and continue normally. This, of course,
leads to a screen display that is not accurately showing what is happening.
But, maybe that is good enough, as long as everybody knows that is the
behavior designed into the system.

My antique Allen-Bradley controller always showed actual instantaneous
velocity, so you actually saw the numbers ramp up and down during the
accel/decel ramps. This also showed the actual velocity produced when you
were using a feed rate override. Kind of neat. It also had a distance to
go display mode for the current block, and an instantaneous following
error display. (This last is not too important, as the logging feature and
a graphing program gives much more useful data.)

One other thing I might mention, while I'm writing, is that adjusting the jog
rate with the < and > keys is somewhat of a pain. I go to a high rate
to get close to an edge, then slow down, eventually going to .1 IPM
when zeroing in with the edge finder. I thought that 3 preset velocities,
accessible from 3 single keystrokes, would be a nice addition. You could
define the 3 jog rates you wanted as something like Jog_Low, Jog_Medium
and Jog_high in the .ini file, and then preset to them with the L M and H
keys, which I think are unassigned in manual and auto mode.

I'm kind of still fretting over losing all connection to the EMC program
when I change X windows to edit a program or whatever. All I have
left is the E-stop button, which is kind of drastic. (I don't have any
great solution for this, other than a separate control panel.)

Jon

Discussion Thread

Clint Bach 1999-12-02 05:06:33 UTC MAX-VELOCITY global = bad Harrison, Doug 1999-12-02 08:47:26 UTC RE: MAX-VELOCITY global = bad Tim Goldstein 1999-12-02 09:12:41 UTC Re: MAX-VELOCITY global = bad Robert Bachman 1999-12-02 09:17:29 UTC Re: MAX-VELOCITY global = bad Jon Elson 1999-12-02 09:41:24 UTC Re: MAX-VELOCITY global = bad