New start

[Nr1madman]

Okey.. now Im confused!

When running large 3d files I get ext e-stops.

The problem gets worse when the machine has been on for a longer period of time. (2-3h)

First I thought noise.. rerouted e stop cabeling.. no improvement.

Removed e stop pin in uccnc.. no improvement.
How can it trip ext e stop when it's not connected?
How do I change "debounce" in uccnc?

Is it my 5£ bob thats the culprit or maybe my computer?

Very annoying :)

Skickat från min SM-G955F via Tapatalk

[Palletlad]

my first thought as I presume you have your mach3 settings correct for the e stop is to check what's going on with the signal via a multimeter.

[Nr1madman]

my first thought as I presume you have your mach3 settings correct for the e stop is to check what's going on with the signal via a multimeter.

Well.. the signal goes from the bob to a relay and back to the bob.. the relay works otherwise power would be lost to the drives..

Well have a spare bob and spare relays.
Will try a little swap!
Relay first :)

Skickat från min SM-G955F via Tapatalk

[A_Camera]

Okey.. now Im confused!

When running large 3d files I get ext e-stops.

The problem gets worse when the machine has been on for a longer period of time. (2-3h)

First I thought noise.. rerouted e stop cabeling.. no improvement.

Removed e stop pin in uccnc.. no improvement.
How can it trip ext e stop when it's not connected?
How do I change "debounce" in uccnc?

Is it my 5£ bob thats the culprit or maybe my computer?

Very annoying :)

Skickat från min SM-G955F via Tapatalk

I don't think it is a debouncing issue. I assume you are using NC type connection for your e-Stop, so in normal case you have a permanent connection. When you push the button you break the line and bouncing would mean the switch will make several contacts, but that would not make a difference since you should expect that UCCNC already detected the first break. That is what you normally want from an e-Stop. You should not have a button which needs debouncing in NC connection because the debouncing will only delay the button push detection circuit, which is pointless and counter productive in an emergency situation. But... if you have a bad contact somewhere in your e-Stop circuit and you have NC circuit then it may trigger the e-Stop function, which again is a good thing and you don't normally want to hide that because it indicates an error which should be fixed and not hidden.

So, if I were you I would NOT try to add any debouncing but would start a fault finding activity, checking every wire and of course, also the BOB. As a matter of fact, I would also try to use a different port of the UCX00 board you are using, because in theory, even that can fail. If nothing is connected except the BOB then you MUST also remove the logical connection in UCCNC so that the input is not defined as e-Stop. You can do that in the Configuration, I/O setup tab. If you have done that and still get e-Stop then I am lost and suggest you contact CNC Drive support. I don't know which UCCNC version you are using, perhaps if it is a test version there is a bug, they can check that out.

[Doddy]

Problem sounds to be sporadic - unlikely to be something that can be diagnosed with a meter.

@Nr1: The things I'd look at:-

Sounds like you have potentially two problems - one of UCCNC registering an input when the input is inhibited?, that's my understanding from your description - and I'd try to resolve that first. If the e-stop, inhibited in UCCNC, is ignored from manual activation of the e-stop (i.e. it looks inhibited) but you're still getting random e-stops through, then I'd suspect the UCCNC software. Could you knock-up a Mach3 build and see if you get similar?
If, however, having inhibited e-stop in UCCNC, the e-stop control does work as you'd normally expect then clearly this is a configuration/software bug issue - try rebuilding your config etc (I've not used UCCNC outside of demo mode so don't know how easy this is?) - or, again, trial a Mach3 build to resolve if it's a software issue or not.

The other problem sounds like the sporadic triggering of the e-stop at an electrical level. Try to understand the software issue before you waste hours on the electrics...

You have two main signal paths: Control-to-the-BoB, and BoB-to-UCx00. The first path - it sounds like you've tried to address EMC/noise (though there can still be gotchas there - are you grounding the screen only at the control box side?, internally to the control box have you shielded that cable?). You could switch to 24V signalling by including a current-limiting resistor between the e-stop line and the BoB input - that would improve noise immunity, or put a (say) 1k resistor between the BoB input and ground to bleed any capacitive induced EM. I personally think this is unlikely to fix your issue.
What about the BoB-to-UCx00 - are you using the provided unshielded IDC cable (26w IDC connector, 25W D-Type IDC connector, 30cm of cable between)? - when I build up my control box I *will* be cutting this cable down to a minimal size to reduce the effect of cross-coupled signals from UCx00 outputs and UCx00 inputs. The UCx00 inputs are reasonably high-input impedance (though a 4k7 pull-up to 5V on board) - it's possible to get short pulses from the stepper outputs coupled to an e-stop input. Have you tried changing the e-stop input? - e.g. Input #13 on a port 2/3 is physically as far away from the stepper outputs on the IDC cable - cross talk should be minimised here. By grounding input #12 as well you're providing the best isolation for your e-stop as you practically can. Worth a shot to see.

Other ideas - try de-powering your spindle - and air-cut - see if that improves things - will indicate if your problem is EM related. Similarly, disconnect the outputs from the BoB to the Stepper Drivers to see if that affects it (causes: EM, or noise on the PSU lines).

[Nr1madman]

I don't think it is a debouncing issue. I assume you are using NC type connection for your e-Stop, so in normal case you have a permanent connection. When you push the button you break the line and bouncing would mean the switch will make several contacts, but that would not make a difference since you should expect that UCCNC already detected the first break. That is what you normally want from an e-Stop. You should not have a button which needs debouncing in NC connection because the debouncing will only delay the button push detection circuit, which is pointless and counter productive in an emergency situation. But... if you have a bad contact somewhere in your e-Stop circuit and you have NC circuit then it may trigger the e-Stop function, which again is a good thing and you don't normally want to hide that because it indicates an error which should be fixed and not hidden.

So, if I were you I would NOT try to add any debouncing but would start a fault finding activity, checking every wire and of course, also the BOB. As a matter of fact, I would also try to use a different port of the UCX00 board you are using, because in theory, even that can fail. If nothing is connected except the BOB then you MUST also remove the logical connection in UCCNC so that the input is not defined as e-Stop. You can do that in the Configuration, I/O setup tab. If you have done that and still get e-Stop then I am lost and suggest you contact CNC Drive support. I don't know which UCCNC version you are using, perhaps if it is a test version there is a bug, they can check that out.

Thanks!

That's exactly what's confusing me.
Even when I reset the e-stops port and pin to 0/0 instead of pin 12 port 3 (in my case) I still get ext e stop.. weird!

Skickat från min SM-G955F via Tapatalk

[A_Camera]

Thanks!

That's exactly what's confusing me.
Even when I reset the e-stops port and pin to 0/0 instead of pin 12 port 3 (in my case) I still get ext e stop.. weird!

Skickat från min SM-G955F via Tapatalk

Are you using a formal release or a test release? If you are using a test release I'd install a formal one and/or contact CNC Drive because if you have disabled hardware e-Stop then it really sounds like some invisible configuration issue or a software bug. I think you should send them a mail or post this on the CNC Drive forum. I am pretty sure you would quickly get an answer there and Balazs would quickly start debugging and solve the issue.

In any case, debouncing is not the right way to go, the problem must be caused by something else. If the e-Stop port and pin is defined as 0/0 then it should not be caused by the hardware.

[Nr1madman]

Problem sounds to be sporadic - unlikely to be something that can be diagnosed with a meter.

@Nr1: The things I'd look at:-

Sounds like you have potentially two problems - one of UCCNC registering an input when the input is inhibited?, that's my understanding from your description - and I'd try to resolve that first. If the e-stop, inhibited in UCCNC, is ignored from manual activation of the e-stop (i.e. it looks inhibited) but you're still getting random e-stops through, then I'd suspect the UCCNC software. Could you knock-up a Mach3 build and see if you get similar?
If, however, having inhibited e-stop in UCCNC, the e-stop control does work as you'd normally expect then clearly this is a configuration/software bug issue - try rebuilding your config etc (I've not used UCCNC outside of demo mode so don't know how easy this is?) - or, again, trial a Mach3 build to resolve if it's a software issue or not.

The other problem sounds like the sporadic triggering of the e-stop at an electrical level. Try to understand the software issue before you waste hours on the electrics...

You have two main signal paths: Control-to-the-BoB, and BoB-to-UCx00. The first path - it sounds like you've tried to address EMC/noise (though there can still be gotchas there - are you grounding the screen only at the control box side?, internally to the control box have you shielded that cable?). You could switch to 24V signalling by including a current-limiting resistor between the e-stop line and the BoB input - that would improve noise immunity, or put a (say) 1k resistor between the BoB input and ground to bleed any capacitive induced EM. I personally think this is unlikely to fix your issue.
What about the BoB-to-UCx00 - are you using the provided unshielded IDC cable (26w IDC connector, 25W D-Type IDC connector, 30cm of cable between)? - when I build up my control box I *will* be cutting this cable down to a minimal size to reduce the effect of cross-coupled signals from UCx00 outputs and UCx00 inputs. The UCx00 inputs are reasonably high-input impedance (though a 4k7 pull-up to 5V on board) - it's possible to get short pulses from the stepper outputs coupled to an e-stop input. Have you tried changing the e-stop input? - e.g. Input #13 on a port 2/3 is physically as far away from the stepper outputs on the IDC cable - cross talk should be minimised here. By grounding input #12 as well you're providing the best isolation for your e-stop as you practically can. Worth a shot to see.

Other ideas - try de-powering your spindle - and air-cut - see if that improves things - will indicate if your problem is EM related. Similarly, disconnect the outputs from the BoB to the Stepper Drivers to see if that affects it (causes: EM, or noise on the PSU lines).

Thanks for the input, loots of things to try :D

Im already using 24v system for limits and e stop. So it should be alright unless the bob is shit..
Am using unshielded ribbon cable and can try with another one.
But if there is faulty hardware then the problem should disappear when I disable the e stop port and pin.. strange!

Skickat från min SM-G955F via Tapatalk

[Nr1madman]

Are you using a formal release or a test release? If you are using a test release I'd install a formal one and/or contact CNC Drive because if you have disabled hardware e-Stop then it really sounds like some invisible configuration issue or a software bug. I think you should send them a mail or post this on the CNC Drive forum. I am pretty sure you would quickly get an answer there and Balazs would quickly start debugging and solve the issue.

In any case, debouncing is not the right way to go, the problem must be caused by something else. If the e-Stop port and pin is defined as 0/0 then it should not be caused by the hardware.

Exactly!

I am using 1.2047, latest stable release according to cncdrive..
Have emailed balazs, hope he has a solution ;)

Skickat från min SM-G955F via Tapatalk

[JAZZCNC]

Don't know if you are using USB version or not but I'd check your PC settings because could be energy saving shutting down the USB ports when thinks Pc is idle.? This would have the same affect as E-stop to the controller because lost connection with PC which would explain why still get E-stop message when not connected.!

Could even be a program working in the background which try's to check ports etc causing blip just long enough to trick controller it's lost connection.