joint 0 limit error

I get this error and have no idea why. I thought joint 0 would be "X", but it doesn't seem to be. I get no indication that X or any other axis has hit a limit. I am checking this several ways:
No arrow pointing to an axis in the display window
no signal on any home/limit switches in hal config - watch

So I am having trouble figuring out what to look for to find the source of this error. Of course the drives drop out when this happens.

Any Ideas?

btvpimill wrote:

I get this error and have no idea why. I thought joint 0 would be "X", but it doesn't seem to be. I get no indication that X or any other axis has hit a limit. I am checking this several ways:
No arrow pointing to an axis in the display window
no signal on any home/limit switches in hal config - watch

So I am having trouble figuring out what to look for to find the source of this error. Of course the drives drop out when this happens.

Any Ideas?

Did you home the axis? If not, then EMC has no idea where the axis is in relation to its physical limits.
Homing sets the machine position to a known value at the home position, then physical travel limits
can be calculated from that position, and EMC will obey the parameters "MAX_LIMIT" and "MIN_LIMIT"
for each axis, as specified in the .ini file. When you load a G-code program, it is immediately checked
against the machine limits and your workpiece coordinate offset to determine if the program stays within
the machine's limits of travel. There's nothing like machining a part for a while and then finding out that
it exceeds the travel limits and the work has to be repositioned on the table.

The above refers to a soft limits error, maybe you are having a limit switch condition. Do you have limit switches wired up? If not, then the hal files may be accepting input on the parallel port from an unused pin, and there may be electrical noise on that pin. If you don't intend to have limit switches, then I'd remove
any lines that connect inputs to "axis.0.neg-lim-sw-in" and "axis.0.pos-lim-sw-in" which are the inputs
to EMC for limit switch sensing.

If you DO have limit switches, then there may be a problem in pull-up resistors or some similar scheme to
establish correct logic levels when the switch is in the "OK" position.

Jon

I have limit switches wired up. I can't home really because before the machine can finish, or even start, it will trip out on joint 0 limit error. Now watching all my limit inputs in hal config watch window, none indicate a switch has been pressed. Also while watching, i can press all my switches and they seem to work as they should.

seperate inputs. Are you suggesting maybe its an instantious input that I can't see? Hmmm, didn't think of that.

So "joint 0 limit error" has to be a limit on "X" - is this true? I can disable that input to check. something to try!

Ok, heres an update. I guess I have a short somewhere because when I disconnect the wires for the X-limits in hardware, everything works fine.

Thanks John, and Jon - thats kinda funny

btvpimill wrote:

Ok, heres an update. I guess I have a short somewhere because when I disconnect the wires for the X-limits in hardware, everything works fine.

No, it probably is NOT a "short", it is most likely electrical noise. I am assuming you
have the limit switches set up as normally open, ie. open contacts when not at
the limit. That allows electrical noise from spindle and stepper drives to couple to the wires.
You may need a pull-up resistor, or to change the value if you have one already, to
deliver enough current to the line so that ONLY the switch can pull it low enough
to be sensed as a limit condition.

Jon

According to halscope, you are correct Jon. there are random spikes which sometimes lineup I guess to trip it on limit error. Currently yes the switches are snap action micro's, when hit pulls the line to ground. I do have pull-ups on the line, can't remember the value right now, but prolly 1K on a 5V system. I should note, this is NOT connected directly to the paraport. It goes though a uP which just multiplexes the switch's so I have enough I/O. I suppose this could be my uP screwing up, but I really doubt that since removing the switches removes the problem.

Would I be better to connect them to the NC side and have them always closed?