On 14 April 2010 13:14, Slavko Kocjancic <esla...@gmail.com> wrote: > Here are HAL and INI. > ... seems that this is problem with AXIS handling longer files.
net enLatchA or2.0.in0 or2.0.out and2.0.in0 net enLatchB or2.0.in1 motion.motion-enabled net chPumpA and2.0.in1 charge-pump.out net chPumpQ and2.0.out parport.0.pin-09-out http://www.linuxcnc.org/docview/devel/html//man/man9/axis.9.html says that motion.motion-enabled is an input. If this is true then the or2.0.in1 and motion.motion-enabled pins are unconnected to a signal source. motion.motion-enable is new to me, as it seems to only exist in the development branch of the docs. Of course, if motion.motion-enabled is a mis-documented output, once the or2.0.out pin goes high, it stays high regardless of other signals, sending the charge-pump to the drive regardless of the state of motion.motion-enabled. From the comment that is your intention. At least, that is how it looks to me from my sketch of the logic wiring. I assume that "ESC" kills the trajectory planner, as it leaves the Amp-Enable lines active and you have the stepgen-enable lines connected to amp-enable (just like the sample configs I have just looked at). I see you are using a user-specified step type, and presumably a development branch of EMC2? I wonder if this is related to the problem? -- atp ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
