gnea / grbl

An open source, embedded, high performance g-code-parser and CNC milling controller written in optimized C that will run on a straight Arduino
https://github.com/gnea/grbl/wiki
Other
4.08k stars 1.61k forks source link

CNC no Homing #326

Closed boogerclone closed 6 years ago

boogerclone commented 6 years ago

First attempt to resolve issue with Mfr: I wiped GRBL1.1 and reloaded to Arduino Uno. Then after trying to reinvent the wheel, discovered the table of default values for GRBL settings in the Assembly instructions. I thought that would fix everything, but alas, no. Homing will not work. First, the z-axis motor moves down, instead of up. (Yes, $23=3), but then it immediately stops with an Alarm 8 code. Help! There are other issues with jogging just freezing after a few jogs, but I think it may be related to the fact that I cannot home the machine & it thinks that I am exceeding soft limits. Maybe/maybe not, but I think/hope that solving the homing issue will resolve all other issues. Any advice? Need info? Response: Please see the troubleshooting guide for reversing the direction of the stepper motor. https://www.bobscnc.com/products/e3-cnc-engraving-kit. Z should move in the up direction when homed. Me: Ok, I have reviewed the document. Still won't home correctly. The stepper motors run in the correct direction when I jog the machine. The spindle moves down, incorrectly, ONLY while homing. Per your instructions, I set $23=3 to reverse X & Y for homing (limit switches are negative direction), but leave Z the same (limit switch is up/positive direction). But when homing, the spindle immediately starts down. After brief movement, I get the error message, "An error was detected while sending '$H': (ALARM:8) Homing fail. Pull off travel failed to clear limit switch. Try increasing pull-off setting or check wiring. Streaming has been paused." This followed immediately by a second error message, "Error while processing response: An unexpected command was completed by the controller." The wiring is fine. I even replaced the X home switch that was showing a higher resistance (bad solder joint). I have tried so many different settings that I am now completely confused and frustrated. When I put my E3 together the first time, it worked perfectly. Now it is a desk sculpture. I even reloaded Netbeans-UGS and tried 3 different versions: ugsplatform (most recent nightly rebuild), UniversalGcodeSender-v1.0.6, and UniversalGcodeSender-v1.0.9. None look like my original and I can no longer find that file on the website. The ugsplatform is most similar, but it does not have the x, y, z check boxes in the Controller State window as described in your recommended help document.

I think this detail may be important: When I jog X+, the gantry moves to the right (away from home switch) and the Controller State windows shows the X position getting bigger. Good! BUT. It is a negative number rising toward zero. When it reaches zero, the gantry stops and I get an error message, "An error was detected while sending '$J=G21G91X1F500': (error:15) Jog target exceeds machine travel. Jog command has been ignored. Streaming has been paused." That is, the system is working in negative space!

I understand if you plead to being a mechanical guy, rather than a software guy. But I need help! Any & all advice welcome, even referral to a GRBL help site for old guys who long for the TurboBasic days. Christmas IS coming and I have gifts to make!

Ok, folks, the above is not meant to disparage Bob's CNC. I works great and I have been happy. But I need help to get my Christmas "shop-ping" done! This feels like I am overlooking something simple, but I can't figure it out. Anyone? Buehler? Buehler?

chamnit commented 6 years ago

@StewartNewark : It's likely you have electrical noise in your limit switch wiring. An Alarm:8 code indicates that it skipped the search phase of the homing cycle, because Grbl detected your limit switch as triggered. Then started to move down to try to clear the switch. See the wiki page on limit switches.

As for negative space, read this FAQ

boogerclone commented 6 years ago

I've have been busy trying to act on your suggestion with the following results: The z home switch is triggered So, tried the following:

  1. Manually activated the switch to check for normally open/closed mixup
  2. Separated switch wires to eliminate noise from motor wires
  3. Jumpered the z limit switch at the board
  4. Jumpered both z limit switch
  5. Switched z & y limit switch connections
  6. Swapped z & y motor connections
  7. Swapped Arduino Uno for known good Arduino Uno including new USB cable
  8. Bought and installed new CNC Shield, including the small, heat shielded motor control boards
  9. Downloaded and reinstalled new software to known good spare laptop computer

Consistent behavior at all times:

  1. Z limit switch would not clear...always in alarm
  2. X and y limit switches alarm and clear properly when manually activated
  3. Swapping z & y limit switches still results in z alarm and manually activating the physical z switch cause the y alarm to appear and clear properly.

Operating system: Linux Mint 18.1 with Cinnamon 32 bit; on new computer Linux Mint 18.3 with Mate 64 bit

Thanks for any help you can provide.

chamnit commented 6 years ago

@StewartNewark : Moving the wires will not likely help your electrical problem. It's often caused with ground loops as well.

Please note that Grbl v0.9, v1.1 have a different pin config as older versions. The CNC shield you have may have the configuration for v0.8 and prior. Check pins D11 and D12. For v1.1, D11 needs to be spindle enable, and D12 is Z-limit. They were swapped to access the hardware PWM on D11. This would explain why your z-limit is always triggered.

trbLeeciN commented 6 years ago

If you are using cnc shield for arduino uno as @chamnit said pins are different. You need to connect your Spindle Enable to lim Z+ or limZ- of CNC Shield(both works). and lim Z pin to Spindle Enable pin of CNC Shield.

boogerclone commented 6 years ago

chamnit: Success!!! Thank you, thank you, thank you!

I studied the GRBL config.h and cpu_map.h files in a text editor (and while watching football), was able to regenerate long-dormant, nested if statement skills, and figure out that I only needed to comment one line in config.h. I changed "#define VARIABLE_SPINDLE" to "// #define VARIABLE_SPINDLE" which caused the nested if block in cpu_map.h to swap the assignment of pins 11 and 12. When uploaded to my Arduino and connected to UGS, the z alarm was gone!

For others who may have a similar issue: I first edited the wrong version of config.h. I had originally downloaded the files into a desktop folder called "CNC Downloaded Files" and used the one located there by accident. When no change and further thinking, I realized that the file I needed to edit was located in ./home>sketchbook>libraries>grbl. Also, even though the z alarm was now off, it still would not home, because the z motor would not actuate. I could hear it and even see slight twitching, like it was trying, but no movement. I tried swapping the y and z motors to see if it was the motor, but that was not the problem. I then swapped out my new shield and replaced it with my old one that I had thought was bad (until you set me straight on the pin 11/12 issue), and voilà! The machine immediately homed like it was brand new. I believe the new shield has different stepper driver resistors and that there is a simple work-around. But I am tired and will work on that tomorrow-ish.

Thanks again for taking the time and making the effort to help. Thank you very much!