John, The only change in the configuration between 2.2.8 and pre-2.3 is the addition of the NO_FORCE_HOME value in the ini file.
I know the timing is very tight, because just upping the debounce duration applied to the home input by a small amount resulted in running into the hard stop. That is back to the value used under 2.2.8 as well. I know how to adjust it out, I just wanted to make sure that there was no change to the homing sequence, since I don't believe I have changed the configuration. Thanks, Eric I'm about 99% sure the actual homing operation is the the same. The NO_FORCE_HOME flag has nothing at all to do with the actual homing operation, it is only used by GUI or userspace code, not by the motion controller. > Is there a parameter which controls this distance? When a home switch is tripped, the axis begins a max-decel ramp to zero speed. The only things that should affect the overshoot distance are the speed at which it hit the switch (HOME_SEARCH_VEL), and the axis accel limit (MAX_ACCELERATION). Are you sure both of those are the same for your 2.2.8 and pre-2.3 configurations? > Are the 2.3 changes to homing listed anywhere, such as the web site? I > did not find it if they are. Not in the kind of detail you are looking for. A while ago, homing code was moved out of src/emc/motion/control.c, into its own file as part of src/emc/motion/homing.c - according to the revision graph at http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/motion/control.c?gra ph=1 that change was after the 2.2.x series was branched off. However, there was no intentional change to homing as part of that change. You might want to look at the commit logs for those files (start at the URL above, and browse around - webCVS is really very nice for this). In the revision graphs, you can click on a box to see that version of the file, or on a line between boxes to see a diff between the versions, and the "Up to" path at the top right lets you navigate to other directories or files. Anything that affects axis acceleration in "free" mode (the motion controller mode that handle jogging, homing, and other non-coordinated motion) could result in what you are seeing. Can you quantify your results? How fast is it moving when it hits the switch? How far does it move before it stops? How fast does it decelerate? How much delay is there between the home switch tripping and the beginning of the decel? Halscope can tell you all of these things. Observe the position and/or velocity of the axis, and trigger on the home switch. You should probably observe the parameter "home-state" as well. Homing is controlled by a state machine, and the state values are an enum in src/emc/motion/motion.h called "home_state_t". The state names plus glancing at the code in homing.c (or the older version in control.c) should tell you what is going on at any given instant. I did see one change that happened after homing.c was spun off from control.c - Alex added the ability to specify the speed of the final move. But the problem you are describing happens before that move. ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
