Ignore limits while torch fires?

[neomadic]

Is there any way to tell grbl to ignore the limit switch and probe inputs for a predetermined time during plasma torch firing? (Edit: I actually need to disable the ABRT input and the probe input while the torch fires.)

I'm really fighting EMI in my probe/anti collision sensor setup whenever the plasma torch doesn't get the fastest/perfect arc start Other than building custom hardware debouncing circuits, I've done everything recommended as far as shielding/routing/grounding goes, and I don't want to desensitize the probe circuit too much during regular operation. It would be really cool if I could just tell grbl to ignore those inputs for a second after an M03 command.

As far as hardware debouncing goes, my proximity and anti collision sensors are NPN NC 24v 200ma, running to trigger relays that then close a circuit between 5v ground and the probe and abrt inputs on my breakout board. The probe switch being triggered at any time other than during a g38.2 cycle doesn't seem to do anything, but when I issue an M03 to fire the torch, if the ground isn't perfect and it hunts for a split second before establishing the arc, the probe sensor light flickers and grbl either stops in it's tracks with no errors, or sets an alarm for ABRT. I'm thinking that I need to debounce the outputs of the sensors, before the relays, with a cap and resistor. If anyone has any advice about circuits and values to use, I'd really appreciate it. I've researched it a bit and got a little overwhelmed. I'm thinking that it's probably a "this can't be this simple" kind of thing that's tripping me up but sometimes I just need some encouragement/direction.

[chamnit]

Outside of altering the source code itself, there's no software way to temporarily disable them at this time, other than altering the settings constantly, which isn't recommended due to excessive EEPROM cycles. But, you could try using one of the aux outputs like coolant control commands to control the wire connections. Not sure what the circuit for something like would look like though. Probably a suite of relays.

[neomadic]

I have a friend that's pretty good at coding. Do you think that altering the source code would be super time consuming? It really would be a nice feature for people with noisy torches and spindles.

The bypass relays were my fall back idea. I have two relays left so I can diode isolate the collision sensor outputs and break that with one relay and use the other to break the probe output. I thought about using the torch on(M03) command to trigger the circuit breaker relays but I'd like the anti collision sensors to keep working while the torch is on. M08/09 are busy doing THC on/off. Looks like I need a third M-code output, or will need to use another relay to bypass the collision sensor bypass relay trigger with the thc on signal....

Just typing this out here in case others need the info in the future: Workflow: M03 (Fire Torch/trigger probe and collision sensor bypass relays-possibly hardware delay signal on torch fire if simultaneous triggering doesn't work) G04 P1.0 (pause for pierce delay) G01 Z0.115 (drop to cut height) M08 (Turn on THC/trigger relay to cut signal to collision sensor bypass relay G01/02/03 (run cut) M09 (turn off THC/collision sensors return to bypassed) M05 (turn off torch/turn off both bypass relays)

Other than possibly needing to design a circuit to slightly delay the M03 output where it splits to the torch on relay, this actually looks like it will be pretty easy.

I'll try it tomorrow!

Thanks again for your help!

[langwadt]

the quick software hack would be to add a disable of the limits in the beginning of spindle_set_state() and reenable the limits at the end of mc_dwell(), that way a M3/G4 and M5/G4 would do all the work

[neomadic]

Great idea to tack the re-enable onto the end of the dwell. That definitely hadn't occurred to me.

I'll see if I can figure it out. First step, find out how similar optimized C is to C, and try and remember computer class from 1992.. lol.. I'm sensing another leg day on the learning curve hill...

[neomadic]

I swear I've opened and searched every .h and .c file and I can only find "set_spindle_state" mentioned three times, and none of those places look right.
I also didn't find "ABRT" mentioned anywhere.

Is there any way to search all of the files for phrases at once?

Better yet, is it bad form to offer up a few bucks in BTC in exchange for help?

[langwadt]

set_spindle_state() is in spindle_control.c, mc_dwell() is in motion_control.c

limits_disable() and limits_init() ought to disable and enable limits

[neomadic]

I found this in motion control.c

// Execute dwell in seconds. void mc_dwell(float seconds) { if (sys.state == STATE_CHECK_MODE) { return; } protocol_buffer_synchronize(); delay_sec(seconds, DELAY_MODE_DWELL); }

I also found a command that appears to enable/disable limits so if I change the output of the collision sensors to z limit instead of the abrt input, that should work for ignoring the limits.

limits_disable(); // Disable hard limits pin change register for cycle duration

I found this little nugget that looks like it could be somehow used to turn the probe off:

sys_probe_state = PROBE_OFF; // Ensure probe state monitor is disabled.

Am I getting warm? :)

[chamnit]

Make sure you put the limits disable after the buffer sync line. Also why do you need to disable the probe pin? It doesn’t read anything unless it’s in a probe cycle.

[neomadic]

The syntax of this is going to be the tricky part for me. I don't even know what a buffer sync line is right now but I will by the end of the night.

I saw in the code where the probe input gets disabled after a probe cycle but the probe sensor was the main one that was flickering when the torch fired and causing me problems today. I could be dealing with emi from the relay coil bouncing though so I'm definitely going to physically disconnect that one with a relay tomorrow. I just have to make two short jumpers and maybe diode isolate my spindle output to split it.

@langwadt For some reason, your post just showed up. Thanks again for the pointers.

[JamieAKing]

I know you are looking for a software fix, but I have had limit switch problems ever since I built my machine 18 months ago. While everything would work well during a homing cycle, as soon as the spindle activated a limit switch would trigger. So hard limits had to be disabled. I am happy to say this weekend I finally got round to fixing the problem. I installed a £5 opto isolator in between the switches and the Arduino. Problem completely solved. I see you have relays to separate the 24v and 5v systems but they do not have the same noise isolation as an opto. There are relays that include opto-iso. available for high current switching but that is over kill in your situation. If this is an option you would like to pursue I would be happy to elaborate more

[neomadic]

I fought the thing all day today. First, I set up two opto trigger relays to disconnect the power to the probe/collision switches and their relays. I tied onto the M3 output to break the connection, then reconnected it along with turning on the THC, with M08. Just powering and unpowering the relays was enough to set the limit switch alarm so that didn't work.

Next, I used the relays to disconnect the collision sensor relay output. This allows the torch to fire and it generally cuts pretty well but I'm still getting random z limit triggers while cutting, due to EMI. I'm wrapping foil around the sensors and their wires and grounding it tomorrow to see if that helps. I also saw something about limit switch debouncing in the grbl compile options stuff so I'm looking into that too.

The 5v relays that I use to switch the divided arc current to the THC and turn the torch on and off are opto isolated but the 24v relays aren't. They do have diodes and led's installed in them but no debouncing circuit. Since the prox sensors are 24v, I'd need opto isolators that could handle that, then more to condition the 5v switched ground coming out of the relays.

I'll be researching all of that tonight. It sure would be nice if there was a way to put a software 250ms delay on the z limit input!

[cri-s]

probably you already use ENABLE_SOFTWARE_DEBOUNCE If you like, you can increase the time, but it is for all timing. Changing WDTCSR = (1<<WDP0); // Set time-out at ~32msec. to this inside limits.c WDTCSR = (1<<WDP2); // Set time-out at ~250msec.

The simplest solution is to send down $21=0 or $21=1 to disable and enable the limit switch just before and after the thc firing, no software change needed. Altrought enabling software_debounce is suggested on thc systems.

2018-06-21 0:23 GMT+02:00, neomadic notifications@github.com:

I fought the thing all day today. First, I set up two opto trigger relays to disconnect the power to the probe/collision switches and their relays. I tied onto the M3 output to break the connection, then reconnected it along with turning on the THC, with M08. Just powering and unpowering the relays was enough to set the limit switch alarm so that didn't work.

Next, I used the relays to disconnect the collision sensor relay output. This allows the torch to fire and it generally cuts pretty well but I'm still getting random z limit triggers while cutting, due to EMI. I'm wrapping foil around the sensors and their wires and grounding it tomorrow to see if that helps. I also saw something about limit switch debouncing in the grbl compile options stuff so I'm looking into that too.

The 5v relays that I use to switch the divided arc current to the THC and turn the torch on and off are opto isolated but the 24v relays aren't. They do have diodes and led's installed in them but no debouncing circuit. Since the prox sensors are 24v, I'd need opto isolators that could handle that, then more to condition the 5v switched ground coming out of the relays.

I'll be researching all of that tonight. It sure would be nice if there was a way to put a software 250ms delay on the z limit input!

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/gnea/grbl/issues/478#issuecomment-398916784

[terjeio]

@neomadic : I suppose you have tried using NC contacts on the relay to reduce EMI sensitivity already - IMO a must, especially if there is a long cable run to the MCU . Another remedy that might help is to use twisted cable, best is shielded and shield grounded at one end only.

[neomadic]

@cri-s Debounce is enabled but randomly, while the torch is on, I see the little led on the probe proximity sensor flicker so it needs a lot more time than the default setting. I haven't been able to see the anti collision sensors flicker but that's the circuit that's getting triggered. I figure that at 70ipm, if I program in a 250msec debounce, that's only enough time for a 1/16-1/8" of travel past the switch, and there's at least 3/8" of sprung travel in the anti collision floating head. Thanks for the tip on adjusting the debounce time. I saw that in there but couldn't figure out how to change it.

Does sending the $21 command write to the eeprom? I didn't know that those changes could be made through gcode, or on the fly.

@terjeio I'm not sure what you mean by "using NC contacts". If the coil of the 24v to 5v relay is triggering due to emi picked up at the sensor body itself, wouldn't the limit triggers be the same whether the relays are setup using the NO or NC connections?

As far as grounding goes, everything is connected using hacked USB cables, and is grounded at the mcu side pre recommendations. Components are star grounded. I drove 6' of copper into the ground and ran separate ground wires from the controller and table. I even wrapped foil around the relays and hooked it up to case ground.

The more I research this, the more I come to the conclusion that I need to run a dedicated ground wire up the gantry, to a shielding ring around the base of the torch holder. This also eliminates the possibility of specs of flying dross shorting the mechanical z upper limit switch.

I need an oscilloscope in my life so bad right now.... :)

[cri-s]

Yes $21 store inside eeprom, and at the same time it changes the setting instantly. Eeprom have 100000 time granted writes, average is 1mio. If you consider only 100k, it is 50000 time you fire the THC. If you fire it 20 times a day and work 20 day/month the arduino last over 10 year.

[terjeio]

@neomadic : are you sure the relay is triggered by EMI? That implies some "serious" current spike through the coil. Some what if questions/scenarios to test: Is the relay close to the MCU or the sensor? Could it be that the EMI is picked up on the MCU side and not by the relay coil? Is the sensor and relay powered from the same supply as the MCU? If so, or perhaps regardless, try powering the sensor side with battery and leave it floating? Add a capacitor across the relay coil? A resistor too? - this to increase the load on the sensor, may be helpful if the relay has a relatively high coil resistance, check the sensor spec for max current allowed and calculate the load resistance from that. EMI is not likely to affect low impedance circuits.

Edit: forgot one thing, your sensor is NC, right? Then the coil is normally energized, an EMI pulse is then needed to counter the current through the coil to switch it off... If the EMI is really doing that you may also try adding a diode across the coil, anode to ground.

[JamieAKing]

in all honestly @terjeio seems to know an awful lot more about this than me, but I what I do know is what worked for me. I shall try to lay out how I solved my limit switching, please bear with me as I may get the terminology muddled. I foolishly ran the 3phase power for a 2kw spindle in unshielded cable alongside the limit switch wiring and here started the problem. being cheap I did not want to spring for the appropriate cable as the extra girth of the shielded equivalent would not fit in the cable chains etc etc. In order to eliminate the false triggering of the limits I have wired the switches in a normally closed configuration to a 12v supply. an individual live wire runs from the supply to a pair of limit switches on each axis. The normally closed switch sends the 12v into the anode side of a opto isolator and the cathodes tied to a common rail and back to the 12v supply. the mcu is then tied to the output of the opto,. During normal operation the input pin on the mcu is pulled to ground though the opto. when the switch is tripped the opto shuts off and the pin voltage of mcu goes high. in order to use this, config limit pin invert needs to be $5=1 it is worth noting that the mcu is powered by a dc to dc buck convertor powered by the same 12v limit supply. I'm sure this is bad practise but it does not seem to have a detrimental effect on the operation. the machine ran flawlessly for 6 hrs continuously last night with the spindle at max rpm. something that certainly would not have happened before the introduction of the opto.

nb one other proof of the robustness of this system is that the probe is also run in the same way but is just an open circuit. the 12v hot is soldered directly to the casing of the spindle (which is has continuity through to the collet) The spindle is isolated from the rest of the machine. to probe tool height I simply call a g30 to move to an aluminium plate in on the machine bed, which is in turn connected to the anode of an opto. G38.1 to send the tool down to touch the plate and zero is set. its worth noting the the spindle is not in operation during this, I have not tried this but it may cause a problem

[neomadic]

are you sure the relay is triggered by EMI?

I don't have an oscilloscope but sometimes when the torch fires, and sometimes when cutting, I see the light flicker on the probe sensor. GRBL is supposed to be ignoring the probe circuit but the anti-collision sensors are the same kind, within a few inches, and are set up to trigger the Z limit input. I can hear the relay coil flutter when the light flickers too.

Is the relay close to the MCU or the sensor?

It's about six inches away, wrapped in foil and grounded.

Could it be that the EMI is picked up on the MCU side and not by the relay coil?

I installed the rPi and protoneer in an old computer case, that's about ten feet away from the plasma cutter box itself and six feet from the gantry/torch. All the power wires in the case are twisted and never cross signal wires. Components that use more power are mounted near each other. Wires are short as can be and insulated.

Is the sensor and relay powered from the same supply as the MCU?

The sensors and relay coils are powered from the 24v power supply that runs the stepper drivers and THC unit. They use their NO connection to bridge a connection between 5v ground on the protoneer board and the probe and z limit inputs.

If so, or perhaps regardless, try powering the sensor side with battery and leave it floating? Add a capacitor across the relay coil? A resistor too?

The sensors are capable of 300ma and the relay coils are 1va/1w so at 24v, they should be pulling 42ma. I'll check this with my meter. https://datasheet.octopart.com/HH52P-DC24V-Fuji-Electric-datasheet-13119728.pdf

Edit: forgot one thing, your sensor is NC, right? They're these: https://www.amazon.com/uxcell-LJ18A3-8-Z-Tubular-Inductive-Proximity/dp/B008ID9J3U

In normal operation, they're sensing metal so aren't putting out any low signal. When the torch holder separates from its base, they move away from the base, which causes them to ground the relay coils. I didn't get time to try to change the debounce settings and recompile grbl today but I'm really hoping that fixes the issue.

I really appreciate your input.

[neomadic]

@JamieAKing

I like your solution. The opto-isolators seem like a good idea but what confuses me is that if my sensor led is flickering due to EMI, wouldn't the opto output flicker as well? I just can't see how they can debounce and filter. I thought they were for electrical isolation. Also, if $5=1 is set, the input pin is pulled low. Wouldn't inducted noise be more likely to pull a low wire high than pull a high wire low?

I really don't want to rewire the entire machine to go to NC limits, and am a little confused about whether the internal pull ups in the arduino need to be disabled when I do so. Then, I think there are noise filter circuits built into the protoneer board that may not work in reverse as well. I'm probably over thinking it but with all of the shielding I've done and the fact that the switches and wiring are so far away from high voltage sources, the NO setup should be fine.

I'm powering my Protoneer and rPi off of a 5v wall wart power supply and the stepper drivers and THC run off of a separate 24v supply. I thought that maybe the grounds should be tied together but there's 5v differential between them so I left them isolated. I've been building and repairing electronics for 20 years but there's definitely still some magic pixie stuff to me and it's usually the simplest stuff that trips me up.

[neomadic]

@JamieAKing Also, I made a pivot arm that suspends the torch cable out over the table so it doesn't have to ride in the cable track. The limit wires and stepper wires are the only things in the track and all are in insulated cables that are grounded at the MCU end.

I really like your probing solution too. If I can ever get this dang plasma dialed, I can get back to working on my mill/router/waterjet/plasma combo machine. When I do, I'll check back on this and attempt to replicate what you did. I love the simplicity.

[neomadic]

@cri-s This machine is actually going to be used in a light industrial environment so I want to be as nice to the MCU as possible. It could easily do 200-300 torch fires in a day and will hopefully be running all the time so that could require a new arduino once a year or more. I also noticed when setting things up that the communication between bCNC and grbl settings is about a 95% reliable operation so, to me, relying on it during a machining process doesn't seem like the best thing to do.

[cri-s]

My advice. Test it out if it works. If it's works, it is no problem to make a new command or setting that don't write to eeprom.

2018-06-22 0:50 GMT+02:00, neomadic notifications@github.com:

@cri-s This machine is actually going to be used in a light industrial environment so I want to be as nice to the MCU as possible. It could easily do 200-300 torch fires in a day and will hopefully be running all the time so that could require a new arduino once a year or more. I also noticed when setting things up that the communication between bCNC and grbl settings is about a 95% reliable operation so, to me, relying on it during a machining process doesn't seem like the best thing to do.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/gnea/grbl/issues/478#issuecomment-399267419

[neomadic]

@cri-s I will give it a try. At least then I'll know if it's a legitimate z switch trigger or EMI freaking the MCU itself out. Thanks again for your help.

[terjeio]

@neomadic : You wrote: " I can hear the relay coil flutter when the light flickers too." Then try to a add a 220 ohm (100 ohm is the minimum E12 value you can safely use) resistor across the coil to reduce the chance for EMI triggering the relay. A diode may also help, perhaps also needed to protect the sensor - or is it designed to be able to switch inductive loads? The relay should be close to the MCU and wired for NC contacts, reconfigure grbl for that. Since you have the relay in the circuit adding an optocoupler is IMO a waste of time and money, the relay does the same job - and it also acts as a low-pass filter.

[JamieAKing]

Quote "I just can't see how they can debounce and filter. I thought they were for electrical isolation. Also, if $5=1 is set, the input pin is pulled low. Wouldn't inducted noise be more likely to pull a low wire high than pull a high wire low?"

It's my understanding (which could easily be wrong) that the noise is not being created in near the MCU but along the length of the cables and at the motors. By having the opto close to the MCU there is no chance for the input pin to see the the noise. On the machine side of the opto, noise will be seen as a high signal. By wiring the switches closed we are sending a high signal to it and looking for a low signal to trigger, therefore making it immune to noise spikes. @neomadic I'm not sure that relays offer the same noise isolation as optos. They are capable of switching larger currents but trade noise isolation. Otherwise there would not be any reason to produce relay boards with opto isolators in circuit. I could of course be total wrong

[neomadic]

@JamieAKing The NC switch thing has been unusually confusing for me. I understand the reasoning behind being safer but am a little foggy on the logic behind the noise resistance thing. Is the reason for the noise reduction difference with the NC switch setup that the switches holding the signal high are holding it high "harder" than the pull up resistor does in an NO setup?

If I send +5v to my limit switches, and wire them in an NC fashion, wouldn't I just need to change the pull up resistors on the Protoneer board to pull downs, but leave the input setting on the Protoneer board set to active low? @Protoneer Any input here would be greatly appreciated. Sorry if these are stupid questions.

@terjeio Thank you for the advice on relay debouncing. I'm going to try some resistors and diodes across the relay coils today.

[terjeio]

@neomadic : Using NC configured switches provides two benefits:

1. A contact or cabling failure results in triggering the signal, ie. it is safer than NO that does not detect such failures. Sure, there are failure modes that is not detected when using NC configuration, but they are not as common as when using NO. It is important that NC configured switches are connected to ground in combination with pull-ups, if connected in series with the input (to 5v) they provide no benefit EMI wise!

2. Any EMI sees a lower impedance as NC shorts (in DC terms) the MCU input to ground, thus proving it more noise immune. When using a NO switch the impedance seen by any EMI is the value of the pullup resistor (50K or thereabouts?) plus the impedance of the cabling - not much load. A lower impedance means more current needs to be induced in the cabling in order to trigger the input.

IMO it is a pity that NC configuration is not the default configuration, I believe an oversight by the developers that is hard to correct now without causing a lot of problems for existing users.

[neomadic]

Just when it started to make sense, I am now more confused. I'm going to set debounce really high for now and just run with what I've got.

[JamieAKing]

Again this is only my very inexperienced understanding of electronics, but a pull up, pull down resistor is only there to stop the input from floating. If the input was allowed to float then any and all noise spikes would be seen as a trigger. Now with the resistor in place the input is held at zero with any spike being “eaten” by the resistor. There is however a threshold at which the input is triggered. I believe in an Arduino that was around 2v but this is from memory 18months ago. I’m sure google could tell you the exact voltage. So now any noise spike below 2v is being filtered. A large spike however is not. In the NC layout the pin is held high at 5v by the internal supply. Now the same noise spike has to be negative (which is rare) and strong enough to cancel out the 5v down to the low trigger threshold (again unsure of the numbers). The problematic high noise spikes that were causing the triggering in the NO format now have no effect. Couple this with the fact that in your scenario we would be on the 24v side there would have to be crazy amounts of noise to dull the opto LED enough to trigger the MCU. Hope this helps. If I’m wrong please someone chime in as I did struggle with limit switch’s in my machine for a long time

[chamnit]

Not sure if anyone mentioned it, but an unstable ground and power source (wall power) can lead to weird behavior as well. I've seen people put stupid large capacitors around the DC power pins to keep things stable. Don't know much about stabilizing AC power however.

[neomadic]

@JamieAKing I definitely appreciate the help but I just can't see how this is any different than what I've got now. The input line is pulled high in an active low, NO setup. It gets grounded when a sensor is triggered. It should be resting at +5v, needing the EMI to pull it low to trigger a false alarm, which is highly unlikely. I really need a scope.

@chamnit The power supply issue is something I've suspected all along but I put my meter on it and can't catch it doing anything weird. I think a power conditioner will be the next step if I can't figure this out today. Thanks for the input!

[JamieAKing]

I admit my explanation seems completely flawed. One more attempt and I shall back out gracefully before making a complete fool of myself. When the opto sees a closed switch on the trigger side it lights an led. This in turns allows a path to ground on the MCU side. Any induced voltage in the trigger wiring on the opto side of the switch will be seen as a closed switch and make the internal led flicker. In an NC set up the led is lit constantly and cannot therefore flicker and give a false trigger.

[langwadt]

@terjeio hopefully the pullup isn't 50K, ten times smaller is a good starting point

[neomadic]

@JamieAKing I really do appreciate your attempts. I can almost guarantee that I'm over thinking all of this.

I think my confusion has been because NO and NC switch wiring can be setup as high or low trigger, and after reading everything, I'm really not even sure what the actual primary recommendation is. The information seems to conflict. Then throw into the mix the NPN NC proximity sensors, at rest in a triggered position, running 24v, using relays to switch 5v ground to the MCU, and everything in my head just jumbles up.

I had an idea though. I accidentally ordered a relay board with optoisolated inputs but couldn't use it because it used 12v relays and I needed 5v. I just removed the relays and added resistors to simulate the coils. Now, no matter what switch wiring I end up going with, I have a unit that can take + or - inputs and translate them into a totally clean +5v signal. The 1k resistors I added should act as the pull down for my breakout board too. I'll probably go ahead and pull the resistors and caps off of the input circuits on the protoneer board, then reuse those caps for noise filtering on my little sensor opto board.

I thought I'd be able to get over to the machine today but it looks like I'll have to try all this out tomorrow.

[langwadt]

@neomadic have you considered that maybe the wiring isn't the culprit, but rather the internals of your sensor that get triggered by the magnetic field of the torch?

[neomadic]

@langwadt

From a comment a few days ago:

"The more I research this, the more I come to the conclusion that I need to run a dedicated ground wire up the gantry, to a shielding ring around the base of the torch holder. This also eliminates the possibility of specs of flying dross shorting the mechanical z upper limit switch."

https://github.com/gnea/grbl/issues/478#issuecomment-399201632

Knowing my luck, I'm probably fighting emi from the torch triggering the sensors themselves, flying bits of dross magically landing perfectly in the z upper limit switch, the proximity sensor relay coils bouncing, an iffy power supply, AND dirty wall voltage. I've got two options here. Throw everything I can at it as far as shielding, isolation, and power conditioning goes, which is all labor, or get a scope, which costs way more than I have, and start logging everything and cutting more metal into garbage. I've just about exhausted step one... :)

[terjeio]

@neomadic : calm down, I think it is time to make a drawings and try to isolate the real source of your problems by systematically excluding them. I believe there is no need for an oscilloscope thay may in fact create more confusion in such a noisy environment as you have. I'll try to come up with one tomorrow to see if I understand your setup correctly.

[neomadic]

@terjeio I have to make a drawing to put in the manual for this machine anyway so I'll work on that tonight. I haven't done it yet because it doesn't work yet but it may help me visualize things better too and I'd hate for you to waste too much time on it.

If I can get into the shop in the morning, here's the current plan:

Change tip/shield cup Clean plate/ground well Adjust debounce settings and recompile grbl Slightly increase tension on floating head test run-if it fails, add limit override $ commands to g-code and retest Adjust THC voltage and sensitivity test run Wrap sensors/leads in foil, connect to separate ground wire Make steel shield to go between torch holder and base to block EMI test run Add diodes on sensor outputs Add resistors to relay coils to increase load on prox switches to 200ma Add resistors on relay outputs to increase contact wetting test run Rewire mechanical limit switches to NC wiring, invert limits pins, recompile grbl, remove pull up resistors from Protoneer board Install opto isolator board on limit switch inputs

[neomadic]

It just occurred to me that I have band practice tonight so I'll have to work on the drawings tomorrow evening.

[langwadt]

@neomadic considered microswitches instead?

[neomadic]

Definitely. I only charged $800 for this build and install and am already in it $500 in parts and a few months of labor/research though so I'd like to make what's there work rather than insert my tail between my legs and go backwards technologically with mechanical switches, which I'd have to modify the floating head to accommodate. Two of the proximity sensors came with the floating head and I ordered the one for the probe separately.

Here's the floating head, manufactured specifically for a CNC plasma cutter, with the switches I'm using as a factory option. I'm thinking that they should work.

http://robot3t.com/en/san-pham/cth3t-01-anti-collision-torch-holder-2/

[neomadic]

I solved it!

I went in early this morning and got methodical. I ran a test with fresh consumables, clean metal, and a good ground and verified the mystery alarm problem still existed. I changed the debounce setting to 100ms, then 250ms, and it failed. Then I started wrapping things in grounded foil and testing until it ran a full test with no errors. I started with the collision and probe sensors and the upper z limit switch pigtails and it still threw errors randomly, but much less frequently, so I made a little foil cover for the Z axis upper limit mechanical switch, which lives about a foot away from the torch head, and got a clean run. I went ahead and did the x and y switches too because I'd already cut up enough foil into strips.

I went ahead and set the limit debounce back to 32ms and everything seems to be working fine!

If I get any more strangeness in the future, I'll add the resistors and diodes to the sensor circuit, invert the limit inputs, wire everything NC, and add my optoisolator board....basically do stuff I should have done in the first place!

If anyone else out there is having issues with limit switch noise, I'd highly recommend studying this thread, which I somehow didn't come across until yesterday, even though I've been searching for limit switch info for weeks.

https://github.com/gnea/grbl/issues/96

I guess since this "issue" was more of a bandaid for a tricky noise issue, we can call this one closed. Thank you all again for taking the time to reply here!

[neomadic]

Well, I thought I got it but it alarmed out three times today for no apparent reason. I had hard limits disabled because my THC isn't quite tuned right for 14g yet and ever so often the torch just barely touches some dross and sets off the anti-collision sensors, and got an alarm 3 anyway, mid run, with nothing wrong physically or the code.

Is there a way to find out exactly what input line is getting triggered? I saw someone in a video checking limit switches in the terminal screen but can't figure out how to get it to log, or get the log to show up in terminal.

[StuartB4]

Just a thought. Have you thought about using Solid State Relays instead of Electromechanical ones. Have you thought about fitting antiparasitic ferrites to the cableing.

[MeJasonT]

This is what i did, control the pilot and arc switch by using plastic fibre optic, absolutely no chance of picking up RF noise in control signalling, its dirt cheap but you will need to replace those resistors with LEDs and photo diode. I used a fibre for each. I also ran the limit switches back to my controller using plastic fibres. (3 plastic fibres running back to controller). use screened cables for motors and any other control wiring you have, failing that use the Chinese finger type wire braiding where you can feed all your wiring through them. Add ferrites to each control cable - again very cheap. earth and wire braids or screened cables (one end only, you may get an earth loop if you connect both ends of the braid. Earth every piece of hardware back to a central point (one wire for each) so braiding from wiring, Z axis, Y axis, X axis, Table, control box and external earth connection on Plasma cutter machine. Connect this central earth point to an earth rod installed into the ground outside 4ft copper earthing rod should do it. If the ground is prone to drying out you may have to water the ground around the earth rod. Keep all cabling as short as possible and use a mains power filters for the control box electronics psu. Do that you will kill the RF EMI floating around the machine and rf energy created by the plasma torch. You could also put th GRBL controller inside a metal box or a box lined with copper, copper slug tape is cheap and brilliant for lining boxes - be careful not create any short to the board. I'm using a cheap cut50 plasma cutter and its noisy as hell Rf wise but works like a treat. My machine was not built for a pilot arc torch, so i replaced the torch with a pilot arc enabled torch and use a motorcycle starter motor relay to energise the pilot arc. Its a 300A beast relay which makes a connection between the torch nozzle and the machine cutting bed, Machine+ connection. We cheat by saying the earth clamp is connected to the bed and treat the torch like its positive where in reality the opposite is actually he case, best not to be bogged down with electrical welder theory just wire it up as per the handbook, it'll be grand. your post processor needs to switch on the pilot arc for a second or two and whilst it on switch on the arc switch / enable add a delay of 1.5 seconds to allow arc to start and penetrate through the steel plate. Disable the pilot then move off and start cutting operation. The post processor uses the coolant output as the pilot and the spindle as arc enable. Try to avoid relays directly controlled by circuity directly connected to your grbl control board, its a huge coil of wire which in itself is a magnetic field producing device, ie electro mechanical switch. Its also a bloody big aerial for RF, that stuff loves wires and coils, the more loops the more energy it can harvest. I will give you a clue, its like a wireless phone charger.