Jon Elson wrote: > Jon Elson wrote: >>> Gentlemen, >>>> The screenshots are on imagebin.org under stustev. They are >>>> representative of the previously presented scenario of homing >>>> attempts. aligned, .030, and .060. > I do homing with both velocities in the same direction, and I > might have seen it glitch once, but it might have been a sticky > indicator. I then changed it so it did the final search for the > index pulse in the opposite direction, and the home position is > set to +0.1, just like Stuart's file, and I got very erratic > home positions.
To simplify troubleshooting, make HOME and HOME_OFFSET the same. That will tell EMC to go exactly to the index pulse position after homing. Eliminating the post-homing move will make it easier to see what is going on. Then confirm once again that you still have the problem. Next, figure out and mark exactly where the index pulses are on your machine. Turn the screw slowly by hand while observing the index pulse signal either thru HAL or better yet with a real scope or meter. When you get an index pulse, mark the table. Keep turning and mark it again at the next one. I assume on a Bridgeport that the marks will be 0.200 apart, but that might not be true if you have belts or such between motor and screw, with something other than a 1:1 ratio. Once you have marked the table positions for several index pulses in the vicinity of your home switch, try homing and see where it stops compared to the marks. On my system, it seemed to home in .020" > quanta. This quantized offset thing is pretty curious. There's > nothing in the driver or PPMC hardware that cares a whit about > units of .020" in my case, which works out to 400 encoder > counts. I can't say absolutely, every time, it is off by a > multiple of .020", but it sure looks like it in a dozen or so > tries. Does 400 encoder counts, or .020", or 0.5mm ring any > bells for anybody? Nope. I would be shocked and astonished if EMC is doing anything besides homing to the position that it reads on the falling edge of "index-enable". In your shoes, I would attempt to arrange for a couple of LEDs, one driven (thru a digital output) from index-enable, and another driven directly by the index pulse. Hold both LEDs close to the marks on the table, and home with a very slow latch velocity. LATCH_VEL = O.01 would mean 20 seconds to travel 0.200", so it would be easy to see if index-enable is switching off between index marks. > So, I decided to update my Bridgeport to the current CVS, and I > got a HAL error "setp requires 2 arguments, 3 given" > This was a collection of configs files that worked before. I > can't find this 3rd argument, even looked for non-printing chars > on the line. Any ideas? Jeff has already explained that. Using three arguments for a setp command has always been wrong, but HAL used to silently ignore the error (and drop the trailing argument). Now it calls your attention to the error so you can fix it. Note that HAL error messages are usually preceded by HAL:<linenumber>, so it's not that hard to trace them down. The ini file substitution means that mistakes might not be in the HAL file itself. > Anyway, I can confirm that at least when homing in the plus > direction, and then searching for the index pulse in the - > direction, this error does show up with the late April version > of the driver. I am hoping that the latest driver will fix this > problem. WHAT!? Late April? Why the hell are you reporting a "bug" when you aren't using the latest version of the driver? I rewrote the indexing code BECAUSE IT WAS BUGGY! and committed my changes on May 1st. Those changes were backported to the 2.1 branch and released as version 2.1.5. You fixed an index polarity issue on May 7, that was backported and released as 2.1.6. Since then you made additional changes in June at the CNC workshop. Those changes were backported, and will be released as part of 2.1.7. http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/drivers/hal_ppmc.c?graph=1 OF COURSE there are bugs in the April version! To be very blunt: reporting a "bug" when you are using an old version of the driver is going to get you ignored or flamed. Users will get some slack, but Jon, you should know better, you are the one who made the June fixes. Test the LATEST driver. If you find problems there, report them and I'll try to help. I don't want to hear about bugs that either you or I may have already fixed. On a more positive note: the upcoming 2.1.7 contains indexing fixes for the Vital systems Motenc card, the Mesa 5i20, and the PPMC card. The motenc was tested at the CNC workshop, and I've tested the 5i20 at home. Let's try to get the PPMC fixed and tested, so that 2.1.7 can be the final 2.1 release. There's nothing more annoying than doing a "final" release and then having someone commit a significant bugfix a day or two later. Regards, John Kasunich ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
