Re: [CAD_CAM_EDM_DRO] Re: Re: EMC Newbie
Posted by
Jon Elson
on 2000-06-09 21:40:18 UTC
Ray Henry wrote:
enough speed.
The stepper versions tax the CPU a bit, so this may not work without a
very
fast CPU, in the Pentium II class. I am using a Pentium classic, at 100
MHz,
but with servo motors. The servo update rate is 1 KHz. I increased the
rate at which the GUI services the keyboard, etc. and also raised the
rate
of the trajectory planning to 2 X the default, I believe. These made
the keyboard
seem much more responsive.
problem is the
guys at NIST are not machinists, and don't really use it to make
anything. In fact,
EMC is really a derivative of work they did on robot kinematics, and
once they had
done the hard stuff, making it move an orthogonal machine like a mill
was just a
side exercise. So, they are not in tune with the way these machines are
used, with
having to recover from a broken tool in the middle of a program, having
to back up
a few blocks and re-execute the program from there.
I must say the ability to start a program from the middle by reading the
program blocks
from the beginning so that all modes are set correctly, and offsets and
compensations
are the way they would be if the program was run from the beginning is
not too bad.
But, my 1978 Allen-Bradley 7320 control had the ability to stop any
program at
any particular block, switch to MDI and enter a few commands, or go to
manual
and move around as much as you like, and then resume the program from
where
you left off. You could also back up line by line and then resume from
there.
They even had a very sophisticated feature where you could interrupt a
complex
move in the middle, retract exactly one axis (like to change or check a
tool)
and then resume the move from the middle. It would bring that axis back
to the
point at which it was interrupted, and then continue the coordinated
move.
Very impressive! They did all this in 16 K bytes of memory, too!
The screen was updated 100 times a second, and the displayed feed rate
ramped
up and down at the beginning and end of moves. You could also see the
true
feed rate at all times, without having to compensate for the feed rate
override.
And, of course, the modal parameters in effect were always shown
correctly.
This was necessary, because if you backed up to a move like X1 Y2 that
was
expected to be a linear interpolated move (G01), but the line you
interrupted
was a G03 (circular arc move) then you'd get an error about no IJK
specified.
You'd look at the program and realize you needed to explicitly specify
G01
in MDI mode, and then it would take off.
The AB would let you get yourself in deeper trouble, I guess, but it was
faster and
more flexible when you wanted to go back and recut something. EMC
will not let you stop a program and do anything without resetting itself
to
the beginning of the program. The set run mark thing is pretty
cumbersome.
The display of modal parameters and feed rate from where the interpreter
is reading ahead rather than what is happening now is a REAL
shortcoming,
and one of the truly "ugly" things about EMC. It is a really schizoid
sort
of thing, that the position displays show where the machine is NOW, but
much of the other on-screen info pertains to what will happen at some
arbitrary time in the future. I think all the M stuff, such as spindle
on,
mist or flood coolant, etc. is also this way on the modal parameter
line,
so if your program has a stop spindle, coolant off at the end, then
these
modal parameters are displayed all through the run, as if the spindle
and
coolant were already off!
Well, enough of that rant, but this "feature" (read, bug) has been
"bugging" me for quite a while.
Jon
> ---------------------------But, you can improve the responsiveness quite a bit, if your CPU has
> KEYBOARD AND MOUSE COMMANDS
>
> >If I set the jog button increment to .100 and hit the + button five
> >times quickly, I would expect that the machine would advance, at the
> >axis speed, a half inch, but instead the indicator shows some
> >intermediate number. Can you explain what is going on.
>
> Tkemc updates and sends those commands on a more or less regular basis
> but
> they are not buffered so you can not expect them to be piled up and
> executed in the order and with the frequency that you entered them.
> EMC
> will do this but the restriction is in the gui, the keyboard, and
> mouse,
> and how those signals get processed as they move from one level to the
> next.
enough speed.
The stepper versions tax the CPU a bit, so this may not work without a
very
fast CPU, in the Pentium II class. I am using a Pentium classic, at 100
MHz,
but with servo motors. The servo update rate is 1 KHz. I increased the
rate at which the GUI services the keyboard, etc. and also raised the
rate
of the trajectory planning to 2 X the default, I believe. These made
the keyboard
seem much more responsive.
> -----------------------------Yes, this is a VERY poor part of EMC, probably the worst part. the
> THE LINE OF G-CODE THAT SHOWS
>
> That line is modal but it is the product of the look ahead feature of
> the
> interpreter. It shows the last set of values as far as it has read.
> It
> DOES NOT show the values in force for the currently executing line.
problem is the
guys at NIST are not machinists, and don't really use it to make
anything. In fact,
EMC is really a derivative of work they did on robot kinematics, and
once they had
done the hard stuff, making it move an orthogonal machine like a mill
was just a
side exercise. So, they are not in tune with the way these machines are
used, with
having to recover from a broken tool in the middle of a program, having
to back up
a few blocks and re-execute the program from there.
I must say the ability to start a program from the middle by reading the
program blocks
from the beginning so that all modes are set correctly, and offsets and
compensations
are the way they would be if the program was run from the beginning is
not too bad.
But, my 1978 Allen-Bradley 7320 control had the ability to stop any
program at
any particular block, switch to MDI and enter a few commands, or go to
manual
and move around as much as you like, and then resume the program from
where
you left off. You could also back up line by line and then resume from
there.
They even had a very sophisticated feature where you could interrupt a
complex
move in the middle, retract exactly one axis (like to change or check a
tool)
and then resume the move from the middle. It would bring that axis back
to the
point at which it was interrupted, and then continue the coordinated
move.
Very impressive! They did all this in 16 K bytes of memory, too!
The screen was updated 100 times a second, and the displayed feed rate
ramped
up and down at the beginning and end of moves. You could also see the
true
feed rate at all times, without having to compensate for the feed rate
override.
And, of course, the modal parameters in effect were always shown
correctly.
This was necessary, because if you backed up to a move like X1 Y2 that
was
expected to be a linear interpolated move (G01), but the line you
interrupted
was a G03 (circular arc move) then you'd get an error about no IJK
specified.
You'd look at the program and realize you needed to explicitly specify
G01
in MDI mode, and then it would take off.
The AB would let you get yourself in deeper trouble, I guess, but it was
faster and
more flexible when you wanted to go back and recut something. EMC
will not let you stop a program and do anything without resetting itself
to
the beginning of the program. The set run mark thing is pretty
cumbersome.
The display of modal parameters and feed rate from where the interpreter
is reading ahead rather than what is happening now is a REAL
shortcoming,
and one of the truly "ugly" things about EMC. It is a really schizoid
sort
of thing, that the position displays show where the machine is NOW, but
much of the other on-screen info pertains to what will happen at some
arbitrary time in the future. I think all the M stuff, such as spindle
on,
mist or flood coolant, etc. is also this way on the modal parameter
line,
so if your program has a stop spindle, coolant off at the end, then
these
modal parameters are displayed all through the run, as if the spindle
and
coolant were already off!
Well, enough of that rant, but this "feature" (read, bug) has been
"bugging" me for quite a while.
Jon