Eric H. Johnson wrote: > Hi all, > > I have a strange problem which looks like it is related to the position > feedback, but I also suspect I may be looking in entirely the wrong place. I > have a three axis configuration where the Z axis is mapped to a PWM for a > laser. The hardware is the Mesa m5i20 controller with the hostmot2 firmware. > Z is directly fed to the laser, the feedback settings are just to prevent > following errors. I have tried several ways of connecting the Z command and > position feedback, but this is the way that so far works the best (X and Y > are shown just for completeness): > > net Xpos-cmd axis.0.motor-pos-cmd => hm2_5i20.0.stepgen.00.position-cmd > net Ypos-cmd axis.1.motor-pos-cmd => hm2_5i20.0.stepgen.01.position-cmd > net Zpos-cmd axis.2.motor-pos-cmd => axis.2.motor-pos-fb > > net Xpos-fb hm2_5i20.0.stepgen.00.position-fb => axis.0.motor-pos-fb > net Ypos-fb hm2_5i20.0.stepgen.01.position-fb => axis.1.motor-pos-fb > net Zpos-cmd => hm2_5i20.0.pwmgen.00.value > > setp hm2_5i20.0.stepgen.00.position-scale [AXIS_0]SCALE > setp hm2_5i20.0.stepgen.01.position-scale [AXIS_1]SCALE > setp hm2_5i20.0.pwmgen.00.scale 1.0 > > Now here is the strange part, if scale in the last line is set to 1.0, > everything seems to work fine (except as below). If scale is set to > something less that 1.0 it runs gcode for some length of time until the > system e-stops, but no error message is generated. The length of time > (number of lines of gcode) is dependent on several factors, among them: > > 1> Increasing FERROR (in the ini file) causes it to run longer to a point. > 2> Decreasing scale decreases the amount of time before e-stop > 3> Increasing the period of the servo thread increases how long the gcode > runs before encountering an estop, at least to a point. > 3> Changing the axis type from linear to angular usually increases the > number of lines of g-code executed, however when scale is 1.0 only angular > eventually results in the error, if it would occur with the axis as linear, > I do not have a g-code file long enough (3000+ lines) to encounter it. > > For example, FERROR of 10.0, servo period of 1000000, and scale of 0.1 will > execute about 1000 lines of my test program. Decreasing scale to 0.01 > decreases the number of lines executed to about 200. > > I am directly feeding the commanded position back to the feedback position, > so I do not see how scale can affect the feedback loop, or really anything > else. It isn't connected to anything except the PWM output itself. The scale > in the ini file is set to 1.0, and directly set in the hal file. > > It may be something else entirely, but I do not see it. I checked for an > over temp condition on the laser for example, because as scale decreases, > laser power increases, but it is not faulting, and would only shut down the > laser if it did. As a stepper system, basically everything runs open loop, > so there really aren't any conditions which would cause it to shut down. > > I have another box, which I can upgrade to the same version of Linux and > EMC, and see if it generates the same error when completely disconnected > from the hardware. I just need to force the NC limit switches. > > Any other ideas or speculations appreciated. >
You need to start observing specific signals at the moment of the fault. Your troubleshooting so far has been good and detailed, but personally I'd stop changing things and look for the root cause. You say you are getting an estop without any messages. Following errors usually result in a message, but this is weird enough that I'd try to rule them out first. You need to dig out HalScope, and trigger it on the estop. Sample in the servo thread, at least at the start. Read "man motion" for a list of the pins and parameters that can give you an idea as to what is going on inside EMC when it shuts down. The HAL pin axis.N.amp-enable-out turns on when the machine goes on, and off when it estops. So trigger halscope on the falling edge of that signal. First, look at the axis.N.f-errored pins. These are bits that go true (for one servo period) when EMC trips on a following error. If you find that one (or more) is going true. Then look closer at that axis, perhaps at axis.N.f-error, the actual value of the following error. If you see it creeping up before the trip, you are onto something. Assuming this isn't a following error situation, look at the command and feedback values for all three axes, again, just as the machine shuts down on the mystery estop. I can't tell you much more - this kind of troubleshooting is usually based on "hey, that looks funny", and then progresses as you investigate the "funny". Don't hesitate to tell us what you see, or post halscope screenshots on imagebin or elsewhere. Regards, John Kasunich ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
