Homing takes about 2 minutes now.
After homing the mill, I felt adventurous and ran some G code from
All dry of course.
I tried drilling a bolt hole pattern. It kind of worked, but would
clearly break a drill bit if it was not a dry run. That's because I
used my own G01 and G00 codes for drilling, instead of a canned cycle,
and G00 was interpolated or whatever it is called. The mill combined
movement of "withdrawing the drill bit" and "moving to the next hole",
and that would end up with a broken drill bit.
So, one more proof that I should use canned cycles wherever they
It was fun and nothing broke physically.
On Thu, 22 Jul 2010 01:45:23 -0500, Ignoramus9140
Why????? At most..it should take maybe 15 seconds
Learn what the Gcode is for Dwell.....
It should be noted..that each command should be on its OWN line, rather
than on the same line.
Tends to work better than way in most cases. Tends to be far more gentle
on your drill bits too....<G>
On Thu, 22 Jul 2010 07:25:16 -0500, Ignoramus24043
Generally..there are two types of homing travel moves:
1. A rapid until a certain switch or location is hit then a sudden slow
2. A somewhat more sedate move to home where it hits a switch and stops.
But..I suspect you have your moves a bit ...slow.
My (EMC's the way I set it) homing routine is as follows:
1) Move fast to home switch
2) Stop when home switch is hit
3) Move away from home switch slowly until I get an index pulse
4) Quickly move table to zero position (so the middle of the table is
under the quill).
On Thu, 22 Jul 2010 07:54:05 -0500, Ignoramus24043
I can't comment on a lot of what you are doing, and I don't understand
the term "latch point" as used in your text. but there is certainly
some validity to coming "off" a point to make a more accurate set
point. That is, your running onto a homing switch ("break" from NO
to NC) at high speed, then backing off that switch slowly until it
"makes" again, and using that as the home point. That is the way, for
instance, that a Renishaw probe on a CMM works. It doesn't register a
data point as the probe touches, as that initial contact can cause
true bounce and "point bounce" inaccuracies, but does register the
data point as the probe comes OFF.
I hope that the "homing switches" referred to are not the limit
switches which would/should be following in close proximity and
preferably on a different cam, or better yet, no cam. Limit switches
to me are the "finals" and would cause an E-stop, versus the homing
switches just cause a directional stop.
I would also suggest that you think carefully about your "line" # 4).
I think that machine "Home" should be at (or very near) the limit of
X,Y,,Z. By your then making a continued automatic (programmed in the
operating system) move to some point other than the limits will bite
you in the ass someday. I'd make the table centering X0, Y0 move as
a separate move, either coded or in G mode. Besides, it's not quite
as useful a position as you might think it is in actual use. X0, Y0,
is more arbitrary, such as you wanting to do a bolt hole pattern,
which will rarely be "centred" on the table, but rather picked up 2
edges or from some point on the work.
Just my (far-far-less-than-expert) opinion. Sure sounds like fun
That's close, but not exactly true.
The mill runs into home switch at high speed.
It comes off home switch and keeps going away from it, slowly, until
the encoder on the motor hits an "index point", which is a signal sent
back to the computer. That means that, at this point, the position is
Yes, what makes me especially happy, is that I have home switches for
homing, and limit switches now cause ESTOP and are only used for estop
If I set my software limits correctly and use a proper homing routine,
and if servo drives and encoders work, my mill will never hit a limit
Now, if something does go wrong, like a servo drive loses tachometer
signal or encoder breaks, etc, and I hit a limit, the whole thing will
I found out today that I can home all axes simultaneously, and that is
what I will try to set up tonight.
The general EMC2 homing operation with encoder index sensing has 3
phases. First, it does a rapid search for the home switch. Then, it
backs off and does a slower approach. When the switch makes the second
time, it then has a number of options. It can back away from the switch
to find the index pulse, or continue farther toward the switch. Once it
has found the index pulse, it marks that location, but can set the final
home position to be some offset from that position. The offset is
required if you have a combined home/limit switch, as you will get an
error if it stops at home, and the limit switch is actuated.
So, this search for the index pulse is where a zero coordinate is
latched into the encoder counter when the index pulse is detected. This
is usually done in the encoder counter hardware, so that it is on the
exact encoder count where index was detected, and not delayed until the
computer next samples the encoder count.
Z home probably ought to be near full up. But, there's no reason X and
Y home need to be at one end. As long as the home switch will not be
damaged by overtravel (such as a roller switch which is set up to just
deflect and flip back after the cam passes it) having home in the center
is fine. Since most machining is near the center of travel, then this
may incur less thermal expansion from the home position from day to
day. (Not that the usual home shop machinist worries too much about
thermal expansion of his machines.) The home position is just a
repeatable reference for the machine limits and to re-establish a
precise offset from day to day.
Home in the center is hard to find, the mill does not know where to go
(in which direction) to find home. It would then run into a limit.
My home switches are very near limits.
I set my machine so that my home is outside of the soft limits, I made
sure to leave about 1/2 inches between X and Y soft limits and their
respective home and limit switches.
On Z I leave myself about 1/8" on top and 1/4" on the bottom.
I would rather be generous with that buffer space, than have some
On Thu, 22 Jul 2010 07:54:05 -0500, Ignoramus24043
A home switch is nothing more than a physical indicator of where the
table is actually At. Without one..its always guessing and hoping.
The OmniTurn CNC lathes I maintain, dont have a home switch on either
axis. There are lables on the axis covers..and when you home one..you
put the pointers anywhere between zero and 1..and then hit the home
switch..and it counts until it hits the Home Pluse in the servo.
Which means one can home the table at ANY location..which for some
jobs..works very well. For others..best run back to zero and rehome.
Ayup...a move from home to Zero....zero being a user defined location in
One of the biggest differences between a mill and a lathe..is that the
mill uses the center of the table (sometimes) as Zero and works +/- from
there. Lathes nearly always use Home for zero..or a user defined Zero
location different from T1 (tool 1) T2 etc etc.
Each tool has its own "home AND/OR zero" locations on a lathe..on
mills..each tool has its own Zero location. And in 3 axis, rather than
the normal 2 in lathes.
So why is it taking 2 minutes to home the mill?
You want to use G61.1 on all drilling programs, or anything else where
you don't want blending of sequential moves. By default, (G64) EMC
begins interpolating in the next move at the point where the
deceleration starts on the current move. If you have your machine
acceleration set low, this can occur over a pretty large distance.
What is the MAX_ACCEL in the [TRAJ] section, and in your individual axis
sections of the .ini file?
Here they are.
I have not yet started working with that, as I planned on doing this
when I begin fighting with following errors. Right now I have
essentially disabled following errors.
For some reason nothing displays in Halscope.
MAX_ACCELERATION = 1.5
MAX_ACCELERATION = 1
MAX_ACCELERATION = 1
MAX_ACCELERATION = 1
Oh, 1 inch/sec^2 is VERY slow acceleration. No wonder you see rounded
I have all these set to 3.0, and that is limited by my 3/8" wide timing
belts. If I turn it up to 5.0, it breaks belts.
HalScope takes a little while to get used to. You have to select HAL
signals to the channels, select a trigger source and then enable normal
trigger. You can click force trigger to see what is going on. Then you
can move the gain and offset sliders to amp up the signals you need so
you get some vertical change.
I have not quite figured it out. I can run it, but I do not have
enough room on my screen to have halscope and emc running together.
Plus I have not mastered triggering.
Here's what I want: watch axis.0.f-error and axis.0.commanded position
and axis.0.speed in one window, triggered ONCE when I submit a G code
command G01 Y1 F55
Yes, a 1024 x 768 screen makes all this easier, even bigger is better.
You can always drag a good screen from another computer while doing the
debugging and tuning, then revert to a low-res screen later. I can't
get the EMC GUI, HalScope and the calibration menu all on the screen at
the same time, either. So, I overlap them all, and have to click with
the mouse to foreground the window I want. With a bigger screen, I can
get 3/4 of HalScope to show off to the side of the EMC GUI. (I use
Axis, have you tried it yet? You just have to change one comment in the
[DISPLAY] section of the .ini file.) So, when tuning, I do this thing
where I change a setting in Calibration, do a jog on the Axis window and
then foreground HalScope to see how it looked, then repeat. A little
cumbersome, but you can actually do it pretty quick, better than one
cycle every 10 seconds.
Trigger off ppmc.0.encoder.00.delta, which is raw encoder delta-counts
per servo cycle.
This makes a real good signal to trigger HalScope on. You have a
trigger selector box in the lower right corner, and a polarity just
above it. Above that on the right edge is the trigger level, you want
it above zero for positive moves and below zero for negative moves.
Somewhere around 10 - 30 is a good trigger point, depending on the move
velocity and encoder resolution. The trigger pos slider moves where in
the horizontal trace the trigger is positioned, you can select to see
more time before the trigger or more time after.
Hmmm, axis.0 refers to the X axis, if you command a move on the Y, you
won't see anything. Y is axis #1. So, if you want to tune Y, bring up
these signals :
ppmc.0.encoder.01.delta (this is also trigger channel)
Axis.n.f-error may not be instantaneous following error, the integrator
manual doesn't say! I know pid.n.error works.
You want to bump up the vertical gain slider on the pid.1.error channel
to about 5m to start with, this will be .005 inch per vertical division.
The vertical gain slider for the delta should be at something like 10
(10 counts/servo cycle rate = 1 vertical division).
The Vertical gain and pos sliders apply to whichever channel is selected
from the colored boxes just below the display window.
If you move the cursor inside the display window, a field below the
window shows the X and Y coordinates of the selected trace matching your
X mouse position, and indicated by a dot on the trace, so you can read
absolute values off the trace.
Once you get triggering working, you can leave the trigger mode in
normal/normal, but you can use the force button to see what the signal
levels are at the moment. Stop freezes the trace for examination and
My Wiki page :
some sample traces that might be useful to compare to what you get there.
Since EMC is running on top of the X11 display engine (with your
choice of window manager on top of that), you should bear in mind that
X11 can happily talk to two or more monitors -- if you have an empty
slot for a second graphics card (probably called a "framebuffer" in the
X11 documentation). Even if you do not have one -- there are graphics
cards which will talk to two monitors at once, so you can gain a lot of
screen space -- if you have desktop/workbench space for the second
monitor. You can even drag an application window from one of the
screens to the other if you so desire.
Type "Xorg -help | less" to get a scrollable display of options
to Xorg -- and look for "xinerama"
===================================================================== +xinerama Enable XINERAMA extension
-xinerama Disable XINERAMA extension
Hmm ... the pipe to less needs to have standard error joined to standard
output for the above to work. And how to do it varies between shells.
If you are using csh or tcsh as your shell, the syntax would be:
Xorg -help >& | less
however -- for Bourne shell, bash, zsh, ksh, and possibly some others,
try this instead:
Xorg -help 2>&1 less
Anyway -- if I remember correctly, XINERAMA requires two
identical monitors to work -- at least two with the same resolution
frame rates and such.
You will have to find out where to add in the "+xinerama" option
to Xorg on your system.
Or -- you can simply let the second monitor show up and add the
"-display 1:0" (or perhaps "-display :1" to the command line which
starts EMC or HalScope).
I'm sort of tempted to do this on my Sun Blade 2000 (UltraSPARC
based system), since I have two identical framebuffers, and have recently
found a mount for dual LCD monitors on a single base. Just a matter of
affording another good monitor like the one which I am currently using. :-)
Now all I need is to figure out how to get to the DVD-burner
tray with two LCD monitors in front of it. :-)
I have a feeling that AXIS cannot do it due to use of OpenGL or some
such. But this is interesting. I have a 19 incher at home that I could
use temporarily. I also brought it from work (they threw it away after
someone dropped it and it cracked. But it works fine).
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.