Re: [CAD_CAM_EDM_DRO] Re: EMC stg2mod.o and problem with homing
Posted by
Jon Elson
on 2003-10-12 17:52:32 UTC
Asim Khan wrote:
It seems to
show that the difference between commanded position and actual position
is 0.0167 user units. In Inches, this is horrible. Actual position
will ALWAYS
be different than commanded. But, this is a lot of error, as you have
the .ini
file user units are set to inches. The only other
possibility is that there is an offset in the .var file that is putting
in this
offset from your last use of the system. This is the correct behavior of
the system. After homing, you should not look at machine position, you
should look a RELATIVE position. (I think you switch between these
with the @ key.) Relative is the coordinate reference system the machine
moves to when axis movement commands are given, such as X 1.234
If you check the relative actual position, I think you will find it is
within a couple encoder counts of zero after the home operation.
(But, once you have set a work coordinate system, it should from then on
use that offset from the home position, as recorded in the .var file, as
your relative position.) You do this by right clicking on the axis to
be set, and entering a particular value, based on measurements from
a fixture. Many people set the corner of a vise jaw as their reference
position. This is done with tools such as an edge finder.
So, some random difference between machine and relative coordinate
systems is no surprise. Machinists have no use for the machine position,
they want to set the zero point at something relative to the part to be
cut, not relative to the machine.
called. They have nothjing to do with tuning or servo performance, only
the difference between commanded and actual that will result in a following
error and the machine going into estop-reset mode. The value is NOT in
inches, unless you have declared your user units in the ini file to be
inches.
of the output scale as well. But, you are obviously past that.
When they
do, it will never have the same offset again, as it is remembered in the
.var file. But, the whole point of this is that the machinist needs to set
the work coordinates to be relative to the part, not relative to the
machine.
Jon
>Hi Jon, Les, Paul, Ray and all other group members!What this seems to indicate is slightly low gain on the servo drives.
>
>I had checked the var file which is being loaded by my emc setup. It
>has all variables set to zero except 5220 variable which is set to 1
>and i am still unable to figure it out whats wrong is happenging with
>my emc system?
>
>Folowing is the condition of GUI setting before i home:
>Actual position display is selected
>Machine Cordinates is selected
>Default Units: mm
>
>When i press home button for any axis the axis goes to touch home
>switch, touches it, then moves in opposite direction to search for
>index pulse (i know this all is normal), when index signal is found it
>stops, turns the position counter of the axis homed to 0.0167 (or any
>other value if i have closed the software and re-launched the program)
>These offset values are always something under .1 mm.
>Now when i selected the "Commanded" position display setting then
>i could see the axis home position to exact 0.0000 mm
>these offset values getting added in the actual position display are
>different for each axis. and are different when program is re-launched
>
>
It seems to
show that the difference between commanded position and actual position
is 0.0167 user units. In Inches, this is horrible. Actual position
will ALWAYS
be different than commanded. But, this is a lot of error, as you have
the .ini
file user units are set to inches. The only other
possibility is that there is an offset in the .var file that is putting
in this
offset from your last use of the system. This is the correct behavior of
the system. After homing, you should not look at machine position, you
should look a RELATIVE position. (I think you switch between these
with the @ key.) Relative is the coordinate reference system the machine
moves to when axis movement commands are given, such as X 1.234
If you check the relative actual position, I think you will find it is
within a couple encoder counts of zero after the home operation.
(But, once you have set a work coordinate system, it should from then on
use that offset from the home position, as recorded in the .var file, as
your relative position.) You do this by right clicking on the axis to
be set, and entering a particular value, based on measurements from
a fixture. Many people set the corner of a vise jaw as their reference
position. This is done with tools such as an edge finder.
So, some random difference between machine and relative coordinate
systems is no surprise. Machinists have no use for the machine position,
they want to set the zero point at something relative to the part to be
cut, not relative to the machine.
>I've already tuned all the three axes. All the three axes jog uptoNo. The ferror parameters set a limit at which a following error will be
>300ipm without any following error and without any much big noise.
>my min_ferror value was 0.005
>
>Do you think i should set min_ferror to some very small value?
>i know this value is in inches. what should be the value for
>min_ferror for input_scale value of 250000 (10000CPR x 2.5 pitch)
>my previous ecperience tells me if we lower min_ferror value then the
>tuning gets much difficult, axis speed reduces and we get following
>errors.
>
>
called. They have nothjing to do with tuning or servo performance, only
the difference between commanded and actual that will result in a following
error and the machine going into estop-reset mode. The value is NOT in
inches, unless you have declared your user units in the ini file to be
inches.
>I was having my position counters counting in reverse so i had put aAbsolutely OK. If the servos run away, then you have to change the sign
>negative sign (-) for my input_scale values. is it permisible to do
>that? otherwise i had to swap my encoder A and B channels, so i
>preffered the changes in ini.
>
>
of the output scale as well. But, you are obviously past that.
>One more thing i observed was this fact that when i commanded in mdiWell, that's because no one ever set the axes on that other machine.
>mode to do G01 X5.000 the same offset that was found in home position
>was added and i saw the target position as X5.0167 (relative, actual
>display)
>
>As i already told I have another machine with the same emc, stg2
>model -II but with 800 CPR encoders and INPUT_SCALE = 4000, but i
>never saw the offset value getting added in the actual position
>display. i have min_ferror (0.005) for this machine same as on this
>problematic machine.
>
>
When they
do, it will never have the same offset again, as it is remembered in the
.var file. But, the whole point of this is that the machinist needs to set
the work coordinates to be relative to the part, not relative to the
machine.
Jon
Discussion Thread
Asim Khan
2003-09-15 06:07:54 UTC
EMC stg2mod.o and problem with homing
Jon Elson
2003-09-15 09:50:57 UTC
Re: [CAD_CAM_EDM_DRO] EMC stg2mod.o and problem with homing
Leslie M. Watts
2003-09-15 10:52:41 UTC
RE: [CAD_CAM_EDM_DRO] EMC stg2mod.o and problem with homing
Asim Khan
2003-09-16 07:54:12 UTC
Re: EMC stg2mod.o and problem with homing
Jon Elson
2003-09-16 10:05:58 UTC
Re: [CAD_CAM_EDM_DRO] Re: EMC stg2mod.o and problem with homing
Leslie M. Watts
2003-09-17 05:39:59 UTC
RE: [CAD_CAM_EDM_DRO] Re: EMC stg2mod.o and problem with homing
Asim Khan
2003-09-22 08:21:19 UTC
Re: EMC stg2mod.o and problem with homing
Jon Elson
2003-09-22 11:08:04 UTC
Re: [CAD_CAM_EDM_DRO] Re: EMC stg2mod.o and problem with homing
Leslie M. Watts
2003-09-22 13:11:18 UTC
RE: [CAD_CAM_EDM_DRO] Re: EMC stg2mod.o and problem with homing
Paul
2003-09-22 14:55:33 UTC
Re: [CAD_CAM_EDM_DRO] Re: EMC stg2mod.o and problem with homing
Asim Khan
2003-09-24 05:16:25 UTC
Re: EMC stg2mod.o and problem with homing
Asim Khan
2003-09-24 06:17:30 UTC
Re: EMC stg2mod.o and problem with homing
Asim Khan
2003-09-24 10:26:30 UTC
Re: EMC stg2mod.o and problem with homing
Paul
2003-09-24 12:57:42 UTC
Re: [CAD_CAM_EDM_DRO] Re: EMC stg2mod.o and problem with homing
Asim Khan
2003-09-25 00:32:33 UTC
Re: EMC stg2mod.o and problem with homing
Jon Elson
2003-09-25 10:03:52 UTC
Re: [CAD_CAM_EDM_DRO] Re: EMC stg2mod.o and problem with homing
Asim Khan
2003-09-25 22:37:04 UTC
Re: EMC stg2mod.o and problem with homing
Asim Khan
2003-09-25 22:41:57 UTC
Re: EMC stg2mod.o and problem with homing
Asim Khan
2003-10-03 02:45:34 UTC
Re: EMC stg2mod.o and problem with homing
Ray Henry
2003-10-03 05:25:05 UTC
Re: Re: EMC stg2mod.o and problem with homing
Paul
2003-10-03 10:16:02 UTC
Re: [CAD_CAM_EDM_DRO] Re: EMC stg2mod.o and problem with homing
Jon Elson
2003-10-03 10:50:13 UTC
Re: [CAD_CAM_EDM_DRO] Re: EMC stg2mod.o and problem with homing
Asim Khan
2003-10-05 22:33:15 UTC
Re: EMC stg2mod.o and problem with homing
Jon Elson
2003-10-05 23:07:01 UTC
Re: [CAD_CAM_EDM_DRO] Re: EMC stg2mod.o and problem with homing
Asim Khan
2003-10-12 08:34:30 UTC
Re: EMC stg2mod.o and problem with homing
Jon Elson
2003-10-12 17:52:32 UTC
Re: [CAD_CAM_EDM_DRO] Re: EMC stg2mod.o and problem with homing
Asim Khan
2003-10-13 23:42:53 UTC
Fanuc 11M system, Drip Feed/DNC mode Configuration help needed
Asim Khan
2003-10-16 08:13:01 UTC
Re: EMC stg2mod.o and problem with homing
Leslie M. Watts
2003-10-16 16:02:31 UTC
RE: [CAD_CAM_EDM_DRO] Re: EMC stg2mod.o and problem with homing
Asim Khan
2003-10-18 09:24:56 UTC
Re: EMC stg2mod.o and problem with homing