I am running a 3D carving program that uses a 1/4 ball nose 2 flute router bit . Part way through the program I get a hard limit warning . homing and restarting the program goes a bit further then the hard limit comes up again. I reduced the speed to 10 % ( same problem) ,reduced depth of cut ( same problem ). Pulling the bit and running the program gives me no problems. Thinking the bit was dull I replaced it ( no difference). Any ideas what may be going on.
@coffeewood Just use Gsender to disable Soft and Hard Limits in the EEPROM. You aren’t the only person experiencing false limit errors. I expect the problem is due to noise on one, or more, of the limit switch lines, but I’m not sure what to do about it. I use the limits for establishing repeatable X, Y and Z zeros.
1 Like
I will give that a try Thank you for your assistance .
1 Like
A good test would be to disconnect the switches after homing and see if the problem still happens occasionally. It would be useful to know if this is a problem with signal filtration or with Arduino GRBL code. There also appears to a problem with soft limits
I ran my Longmill with the end switches disconnected and it shut down with a hard limit trip after about an hour of running. Running with hard limits only turned off worked fine.
1 Like
Very useful test I would think. Looks like an error in GRBL?
Where did you disconnect the switches? If you disconnected them at the switches themselves, the hanging wires would have picked up noise and could have triggered the limits. If you disconnected them at the Arduino, ignore this comment 
That is interesting. I would still suspect noise on the Long Board over a GRBL error.
In answer to previous queries,the sensor wires were removed from the longboard
That’s not the issue. Disable Hard Limits…set $21 = 0
1 Like
@NeilFerreri Looks like a smoking gun to me if hard limits activate with no sensors attached - GRBL implicated. Disabling them mitigates the issue, but this points to the culprit
Is it likely that the developers of the program are aware of this issue and are working on a solution? I have not had my Longmill long enough to need their expertise.
There are two main layers of software involved: gSender, which runs on your computer, and the Arduino firmware (GRBL) which is inside the Longboard. I get the impression that gSender may be innocent in this matter. The Arduino firmware is not developed by Sienci, so I am not sure how promptly this one will get fixed
1 Like
@coffeewood, GRBL is open source and developed by volunteers. You can search through the GRBL problem log on github for hard limit errors and you will find instances going back at least as far as 2016. Bottom line is that this is considered to be a electrical noise issue to be remedied by adding filtering to the three switch inputs and not a GRBL software issue so don’t expect any fix in GRBL. What would be needed to be implemented in GRBL to deal with this is a glitch filter that would sample the inputs some specified time after the interrupt occurred to make sure the signal was still present so that it would ignore a glitch caused by noise. From what I read it is not possible to implement this function with an Arduino and its 8 bit ATMEGA328P microcontroller- there just isn’t enough computing power. I did see that there were some of ports GRBL to some 32 bit microcontrollers that incorporated this function, but that doesn’t help us.
I have an older 1.2 version Longboard so I added the provided caps. They might have helped some, but not completely. I think that what I will try next is adding 20K pullups to the caps. There are pullups on these signals in the ATMEGA328P microcontroller (on the Arduino Uno) but I looked at the specs and their value ranges from 20K minimum to 50K maximum. That means they could be pretty weak. I figure adding 20K in parallel with the internal pullup would give a range of 10K to 14.2K which might work better.
1 Like
BUT if hard limits can activate with no input connected, there would be no external noise applied to these inputs. What is the trigger in that case? It is not hard to make a digital filter to add to the inputs: I’ll present a design but I don’t think that is the only problem
Even though there is nothing connected to the Longboard input pins there are still pcb traces from those input pins to the ATMEGA328P input pins. I suspect that noise is coupling into these traces on the Longboard itself.
I will gladly do any testing that would help the cause
This is a quick example of a one-channel digital filter which can be added that uses cheap parts. The LED lights and the input is triggered low only if the limit input is low for at least 255 consecutive counts of the clock. If the switch is closed, then a manual reset by pushbutton is required.
2 Likes
Simple filter like this may also suffice. The input will have to be (on average) low for at least 1 mS before input is triggered. The equipment I design at work is next to a klystron which handles 100 ampere 250kV pulses. Now that’s a noisy environment!
3 Likes
One experiment that might be interesting would be to leave the limit switches disconnected, tie (i.e., connect) the X, Y and Z limit inputs directly to ground, set $5=1 in the EEPROM, enable hard limits in the EEPROM and run your test again. I expect with the pins tied directly to ground, noise would be less of a problem. When $5=0, GRBL is looking for a high to low transition on the input pins to indicate a limit switch has tripped. With $5=1 GRBL, is looking for a low to high transition, so setting $5=1 and tying the inputs to ground should equate to no limit switch ever tripping. Don’t try homing in this configuration as it will fail. If you can run this way without false hard limit errors it gives more credence to my noise theory.
This is a “just if you have nothing better to do” experiment.
2 Likes