Yahnis Chris wrote: > Hi All, > > I experienced some homing problem on a home switch + encoder index > configuration. > The install was simple. After the initial timing issues and a subsequent > motherboard change the machine runs fine and quite stable, timing is good, > except emc does not reset the axis position at the index signal. After the > home switch release the .index-enable goes on. When the encoder index "Z" > signal is "on" instead of resetting the internal position counter to > HOME_OFFSET (0.0) value and move to HOME (0.0) the axis travels back at > rapid speed to the original axis "zero" position and the axis is "homed". > This "zero" position is exactly the same position, where emc was first > turned on. Homing is sequential XYZ all do the same way. Polarity and index > is properly connected at least I think so. Phase-Z is traceable on the > HALscope for encoder.n, axis.n, and parport.n.pin. > > HAL config (only for X Index section) > > net X-index encoder.0.index-enable axis.0.index-enable > newsig X-phaseZ bit > linksp X-phaseZ <= parport.1.pin-08-in-not > linksp X-phaseZ => encoder.0.phase-Z > net Xhome parport.1.pin-13-in-not axis.0.home-sw-in > > Home switch is stable proximity switch and works fine. > Encoder is counting the same way as stepgen so all pins should be correct. > > The homing section of the ini: > HOME_USE_INDEX = YES > HOME_OFFSET = 0.0 > HOME_SEARCH_VEL = -5.0 > HOME_LATCH_VEL = 1.50000 > #HOME_FINAL_VEL = 5.0 > HOME_SEQUENCE = 0 > HOME_IGNORE_LIMITS = NO > > EMC2 2.2.2 and 2.2.5 versions were tested with same result on the 2.2.2 > the HOME_FINAL_VEL was commented. >
Thanks for providing good details. Everything you are doing looks correct. You don't show the HAL lines, but I assume that you are connecting the A and B phases of the encoder as well. I'm away from my Linux computer, so I can't test anything right now. However there are a couple of simple tests that you can run to try to isolate the problem. You say that signal X-index (pin axis.0.index-enable) goes on when you come off the home switch - that is good. Does it turn off again when the index pulse arrives? If not, the software encoder counter is missing the index. If X-index does turn off, what happens to encoder.0.counts and encoder.0.position? Both should become zero on the falling edge of index-enable. Hmmm - you say "encoder is counting the same way as stepgen". Does that mean you are running a stepper machine with encoders? If so, are you taking the position feedback from the stepgen module or from the encoder module? Whatever is connected to axis.0.motor-pos-fb is the feedback source for that axis. If you are talking feedback from stepgen, then the encoder data is being ignored. I think that could give the result you are seeing. This is a complex situation - EMC assumes that something (either a stepgen module or a PID loop) will drive the feedback to equal the command. If you are sending the position command to a PID loop, and getting the position from an encoder, the PID loop will drive the feedback to equal the command. This is the standard servo setup. In that case, when you hit the index pulse during homing, the encoder position jumps from whatever it was to zero. EMC expects this, and it makes a matching jump in the command, which keeps the PID loop happy. If you are sending the command to a stepgen and taking the feedback from that stepgen, the stepgen drives the feedback to equal the command. EMC is happy, but it has no idea that you have an encoder and cannot use the encoder data for homing. I suspect that is what you are doing right now. If you are sending the command to a stepgen and taking the feedback from an encoder, there is nothing to drive the feedback to equal the command. If the scales are right and both encoder and stepgen start at zero, it will work "open loop" like all stepper systems, and you won't get a following error unless you lose steps. When you home and the index pulse arrives, the feedback from the encoder will jump to zero. But the stepgen will not know about that jump. You will wind up with a difference between the stepgen position and the encoder position, and you will get a following error. Even worse, I suspect the machine will start chasing its tail each time you enable it, trying to make that difference go away. I don't have time right now to dig deeper. Do the encoder test I suggested above - look for index-enable going false and counts and position resetting to zero. Then see if my theory fits. Are you taking feedback from the encoder or the stepgen? If my theory of the problem is correct, I know of one definite but inconvenient fix. You can switch the stepgen from position mode to velocity mode, add a PID loop, and treat the system as a true servo system. Then homing and everything else will work as designed. However, you will have to tune the PID loop yourself, rather than using stepgen's convenient built-in position loop. There is probably second solution - a way to use HAL to allow you to home to an index while still using the stepgen position loop and no PID. But figuring that out will take more time than I can spend right now. I'll think about it and reply later (maybe tomorrow). Regards, John Kasunich ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
