Arduino (grbl) resetting during run,

I’ve been having a problem lately where the arduino board appears to reset and hang in the middle of a job. I’ve ran it several time and it never stops in the same spot. I’ve tried with Chillipeppr and UGCS with the same results. I’ve posted the last few lines of the Command Table and Console as displayed by UGCS. You can see at the end of the console output that grble reports back that it needs to be unlocked as though it has reset. Any clues? If it was a bad G-code sequence I would expect the problem to happen at the same point every time and it does not.

Thanks in advance.

// Console Output.
ok
ok

G3X8.1423Y7.38I0.8095J-2.1528
G1X8.0415Y7.3289
ok
G1X8.1319Y7.1505F90
ok
G3X7.9332Y7.0358I0.9491J-1.8733F90
ok
G1X7.8386Y6.974
ok
G3X7.6536Y6.8383I1.1478J-1.7586
ok
G1X7.5662Y6.7666
ok
ok
G3X7.3972Y6.6115I1.3328J-1.6229
G1X7.3182Y6.5307
ok
ok
G3X7.167Y6.3581I1.5018J-1.4678
G1X7.0973Y6.2692
ok

Grbl 0.9j [‘$’ for help]
[‘$H’|‘$X’ to unlock]

// Command Table Output.
G3X9.4318Y10.8074I0.3311J2.2761 true true ok
G1X9.5437Y10.8033 true true ok
G3X9.7927Y10.8078I0.083J2.2985 true true ok
G1X9.9044Y10.8159 true true ok
G3X10.1516Y10.8473I-0.166J2.294 true true ok
G1X12.2661Y9.6266 true true ok
G1X12.2657Y8.8902 true true ok
G1X10.1503Y7.6689 true true ok
G3X9.9128Y7.6999I-0.4157J-2.2621 true true ok
G1X9.8001Y7.7086 true true ok
G3X9.5489Y7.7144I-0.1782J-2.2931 true true ok
G1X9.436Y7.7108 true true ok
G3X9.1856Y7.6891I0.073J-2.2988 true true ok
G1X9.0737Y7.6732 true true ok
G3X8.8273Y7.6244I0.3233J-2.2772 true true ok
G1X8.7178Y7.5964 true true ok
G3X8.4781Y7.5209I0.5698J-2.2283 true true ok
G1X8.3723Y7.4811 true true ok
G3X8.1423Y7.38I0.8095J-2.1528 true true ok
G1X8.0415Y7.3289 true true ok
G1X8.1319Y7.1505F90 true true ok
G3X7.9332Y7.0358I0.9491J-1.8733F90 true true ok
G1X7.8386Y6.974 true true ok
G3X7.6536Y6.8383I1.1478J-1.7586 true true ok
G1X7.5662Y6.7666 true true ok
G3X7.3972Y6.6115I1.3328J-1.6229 true false
G1X7.3182Y6.5307 true false
G3X7.167Y6.3581I1.5018J-1.4678 true false
G1X7.0973Y6.2692 true false
G3X6.9659Y6.0811I1.653J-1.2952 false false
G1X6.9063Y5.9851 false false

Is your computer falling asleep in the middle of the run?

If not, that’s the extent of my guesswork… :smile:

No, already been down that path ;0)

Another clue. I fell back to a previous version of my file that is mostly the same except the feed rate is 60 ipm. The failing file is running at 90ipm.

I’m going to do a little more testing to try to isolate the problem to feed rate. Any known issues with that on the arduino?

-B

I had this happen twice both in easel and ugcs. In both cases I have been around and doing things around machine. So I have been suspecting short of some sord. I grounded since than with copper wire my dust collect hose all the way from router mount to grounding rods. Problem did not happen since but it has been very busy week and I have not been able to carve any long jobs so I can’t tell for sure.

Interesting idea. It is getting cold and very dry here so static is a big issue. Sawdust brushing past plastic can build up a good charge. It does seem I had the vacuum running in all the cases the processor reset. I’ll confirm that and report back.

It seems the primary path back to the arduino are the stepper drive signals and the limit switches. The drive signals are low impedance and isolated through the driver board so that leaves the limit switch inputs. I’ll also try disconnecting those.

It’s been frustrating. Between this and occasional skipping I’ve lost more work than I’ve successfully created. I anticipated mechanical issues with belt drive and flexible rails, so I’ve done the usual mods which helped greatly. I think the week link now is using hobby grade electronics (and some buggy software). After I get through this job (if I ever do) maybe I’ll turn my attention to designing a more robust controller - open source of course ;0)

After considerable testing I confirmed the resets were being caused by the static discharge from the vacuum. I tried disconnecting the limit switch wires from the controller since they were not shielded, but still had 1 reset occur when I was running the vacuum. I’ve had no resets if I don’t run the vacuum.

Once I get through this job I’ll start looking into making the controller less prone to resets, either through shielding, isolation or a combination. Grounding the shop hose as you’ve done may be the quickest solution.

1 Like

Did you ever figure out what the solution was? I’m going through the same issues.

  • Alex

Grab long spool of preferably copper wire and tie it along the hose. Than use grounding rod or anything else that would ground it lime gas or water pipe …

I’m not an expert myself so correct me if I’m wrong on that. Personally I just got grounding kit from amazon and grounding rod from hardware store.

I see your point.
What we aiming at here is grounding the hose of dust collect against all the dry environment friction inside. I believe this is more to prevent explosion of fine saw dust more than protecting circuits.
I suspect static charges collecting on the system were somehow messing with my controller, once ground (not to gas pipe) my issues went away.