[HakBot]

Hello,

I have a Taig mill powered by a xylotex 3 axis board and turbocnc software. I have setup 6 limit switches according to the xylotex instructions. http://www.xylotex.com/images/xylotexlimits%5B1%5D.jpg

I am currently having a problem with false switch trips when running a gcode program. It usually reports 2-3 false positives per run. The limit switches do work so I believe I have it all setup correctly with a 10k ohm resistor installed. Does anyone have any ideas as to why turbo cnc reports the limit switches as tripped and how I can prevent it? Thanks!

[Bubba]

In a way, I am happy to see someone else have this problem. Maybe between us, we can find a solution.
I also run Turbocnc (V4.01) and at times, have had a similar situation where for unknown reasons, it would trip out and give an indication that a limit had tripped. A check of each of the limits would show that none was near tripping. In my case, I have 5 switches setup on my machine.

Because previous versions of Turbocnc had given the limit that was tripped, I did some tweaking of Turbocnc to put that function back in to tell me WHICH limit tripped.

Well imagine my surprise when I got a fault indicating "A limit switch has tripped"; HUH, that is not possible as it has to tell me which switch has tripped! To date, I cannot explain it and cannot find in the code HOW it can fault out with this message without giving me an indication of which axis has tripped.
I have also discussed this with Dave K and he has no idea either.

In your case, make sure that your lines are not close to power lines where they can pick up extraneous signals or that vibration is causing the problem.

[The Blight]

I have had the same problem for a while now, and this only happens on my 2nd parallel port (PCI card type). Are you running TCNC on a laptop?

[fretsman]

Are your cables shielded? They can pick up stray signals/noise if they're not.

Dave

[HakBot]

I am running on a desktop pc. The parallel port is built into the motherboard.

Hey Bubba, how were you able to get turbocnc to tell you what switch was tripped? What version of turbocnc was this? I am curious to see if it is a different switch or the same on that is always giving the false trigger.

The cable I am using is something I picked up from Mouser. Multi-Conductor Cable SHIELD 4C 24AWG. http://www.mouser.com/Search/Product...ey566-9534-100
Seems like good wire to me.

[Bubba]

I run mine on a desktop (port on the motherboard) and have a solid state drive. There is not other software on this machine. The only add in drivers are for usb to allow use of a thumb drive to transfer files.

[Bubba]

HakBot,
I went into the source code and made some changes (based on MY machine paramaters) and then recompiled it. Whenever I manually trip one of the axis, it give the appropriate message such as "X Limit Tripped".

To do it, I had to violate an admonition from Tony G not to mess with motion.pas, but I did to see if there was a pattern to the problem.

[Stepper Monkey]

Could likely be interference if it isn't actually a software problem. Shielding and proper routing of wiring is key, but a sloppy and fast way to check it is to simply reverse your active high/active low settings so that in the non-tripped state it is constantly high, and tripped it goes low.
Not a great replacement for proper shielding, but it does keep false positives from happening if it is indeed a shielding issue, as if low is the default state interference can make it go high and give a false trip, interference obviously can't happen as easily the other way round and force a pin to go low.

[HakBot]

When you talk of shielding are you talking about shielding from the spindle motor/cnc control power wires or are you referring to the positive line running to the limit switches?

Good idea with the active high/low reversal.

[Bubba]

Stepper Monkey,
With all due respect, HUH! by doing this without a complete wiring change, it will always be in a tripped state. I can't speak for the other guys, but in my case this is an intermittent problem.
I may go a couple of months before a trip may occur. I also note no particular pattern to this happening!

[Clot]

I get fauls tripping too but only on my Z axis. Its driving me mad! I resort to upluginh my Z once its ready to run to ensure that program is not interupted. Blimmin annoying...

[Stepper Monkey]

Bubba - don't know how yours are wired exactly, but it shouldn't need much if any rewiring at all. Number of ways to do it, but basically you can make tripping the switch act to sink an input as readily as bring it high. You can make a resistor in a circuit act to pull-up or pull-down just as easily if that helps any.

[epineh]

I was having trouble with this sort of thing on my machine, so I decided to use 24Volt (my motor supply) for my limit switches and the problem vanished, same cabling.

I had to make a little circuit to optoisolate the motor supply from the 5V logic but it was very basic, and I breadboarded it, if you want details let me know.

The only time I get trips now is when I lean over the machine while watching it work and accidently bump a limit switch, I don't think they make a circuit to stop that from happening (chair)

Cheers.

Russell.

[Bubba]

I tend to agree with Russell on the voltage situation. The designer of my BOB and I have had discussions along this line. However to simply change the existing design on the working board is not quite that simple. First off, the resistors for the optos are of the sim type and quite small. (to small for this old man and his eyes) and would require other circuit changes (voltage supply is on board).

However, I still believe there is a coding problem as the anomaly gives a generic "a limit has tripped" message. This is not "A axis has tripped" as that is neither encoded nor is there a limit for the A axis. Somehow, the error routine is called giving this message from some other point. I could well be a valid trip for some reason, but it is not giving the proper message.

I also know there is now a problem with the voltage on the machine side of the BOB also. The 5V for this side is derived by use of a DC-DC converter and recently, I found I could not enable the 4 Gecko drives. After a quick trip to my handy dandy Fluke, I found the output voltage of the 5V converter was around 3V!!!! Well, doing some temp rigging with a 5V wall wort with a higher power rating, I found the problem seems to be one of the Geckos as can get 3 of the 4 to enable. The one that won't is an original version of a 340. So I suspect this may be a problem for some reason. Now I just have to dig in the control cabinet to replace it with a spare that I have. Of course as Murphy would have it, it is the one in the most congested space and being of the original type, does not have the removable terminal block:{(

[epineh]

Yeah I guess you have a point, simply hacking into a commercial BOB could be dangerous, my stuff is all homebrew so there is plenty of room for hammer and chisel

Russell.

[Bubba]

Russell,
My board "was" intended to be commercial, but I have the one and only prototype ever soldered up(nuts). You might say that I am the beta (alpha) tester. And other than this one problem which may or may not be because of the board, I am willing to live with it and worry about my next design. This one has some good ideas on it and I understand how it works. I have plans to cnc my lathe so will need another BOB and intended to design one based on the principles I have in this one as well as some from your threads and others

[HakBot]

my case this is an intermittent problem.
I may go a couple of months before a trip may occur. I also note no particular pattern to this happening!

Mine occurs much more often. Maybe 3 times when milling a small 2"x3" part.

[cadmonkey]

I came across this and don't really have any answers or suggestions but in reading I wanted to make a comment about Stepper Monkey's suggestion.

Safe machine building practice suggests that controls intended to stop operation be logic LOW when in the tripped status. If your BOB doesn't support this then there are possibly some work arounds I'll mention at the end.

The underlying theory of the tripped state being a logic LOW state is that if a wire is cut, broken or shorts out to the machine (which 99.9% of the time is going to be ground - though whether referenced to logic ground or not making a difference could be debated with all the EMI generated by the movement of the machine but that's a larger and more complex debate) or if a power source separate from the controller fails - in my setup a charge pump switches power to everything other than the computer and the opto isolator dedicated to the charge pump so if that or anything after it fails there is no voltage at the limits, the drives, the spindle, anything - the control software - in my case EMC - see's a wholesale lack of "SAFE" signals since they are all expected to be HIGH under normal operating conditions.

Not trying to be a burr under anyones saddle, just trying to save a few fingers if I can.

The work arounds for the limits, if your BOB doesn't have the flexibility to let you run a switches as a high condition as the normal good to go condition, would be to utilize the PC 5V power supply (fused of course) and wire it through each switch using the normally closed terminals so that if the switch isn't activated the logic 5V of the PC is run back to the parallel port as the limit signal. If your software doesn't let you look for them as high being the go state then you're stuck with that limitation (and then I'd suggest looking at using EMC or Mach if that makes you more comfortable).

I hope I didn't offend anyone and everyone had the patience to read through this whole post, and that at least the concept makes sense. I would hate to see someone's part, or worst case scenario a finger, hand, etc. ruined because a wall wort died and there was no 5V signal to be seen so everything kept running because the software saw no 5V signal to tell it to stop doing what it was doing.

My .02 - and I hope your mileage doesn't vary If you have definitive reasons not to wire it as such I'd love to hear them, but in my years servicing, rebuilding and a few design tasks on a lot of equipment of many different types, any mechanical limit or interlock was HIGH in the safe to run state and LOW in the stop everything state.

HTH

[Stepper Monkey]

Very good point there cadmonkey.

I never looked at setting up the pin logic for the limit switches from a fail soft or fail safe perspective before. It is an excellent point.

I have always set my systems with the limits active high simply for convenience and interference reasons, but I never did give a thought to how that behaved for safety reasons. Kind of stupid of me now I look back on it. Especially using optocouplers on everything it is even more important as there is an extra potential point-of-failure added. Only sheer luck I won't have to go back and rewire now!

Makes a lot of sense. Best practice would definitely call for active high.