Have a read through gnea/grbl As per Grbl Wiki An inverted Z is very weird, one wants to home Z up away from the workpiece to avoid crashing. Put your switches at Max of each axis, and use default of $23=0 custom compile, or stock official Hex installed? And test without the “solenoids” - if that is part of the cause, consider actual Optos instead. Mechanical devices have a lot of “bounce” and is far from ideal for this use case. Hook up an oscilloscope, you will be shocked at the output from the solenoid contacts.
Does jogging Z+ jog up too, because your $23=6 puts Z switch at Z- No regular CNC ever sets $23 to anything other than 0-3 as homing Z toward negative is never the right answer $3 is fine. Optos are LEDs, correct resistor value and it can take a 24v input.
G0 commands xyz all move to the + side just the homing moves minus. That is what is really throwing me. if I command a move it moves in the correct directions. but homing it doesn't behave normally. I changed the $3 value to 0 and now it moves down. I will remove the Hiletgo solenoid and go to the opto isolator. that may take me a little while. have to search and find the correct wiring for the opto. I assume the opto will no longer need the filter caps etc.
my opto isolators should be here in a few days. I assume that I need to reverse the wires on the motors so that I can invert the motor directions and then not invert the home. Does that make sense or just wait till I see what the opto isolators react.
You can leave the motors and $3 alone if its jogging correctly: X+ moves tool toward the right Y+ moves tool away from you if you are in front of machine Z+ lifts tool up and away from the workpiece 1) make machine do the above first! 2) now sort out homing: Homing Invert is not as much a question as where are you moving too. Its "where are the switches, at max (default) or min (inverted) Follow standards and put all three limits physically installed on the Max (positive) (top, right, back) of the machine, then $23=0 should apply. You need Max for most compatibility with modern CAMs that often have G53 Machine moves.
You sure X is homing away? It should home to the front left. X0 Y0 should be at the bottom left corner.
Thats the problem! X is left to right axis. Y is the back to front axis! You have them swopped. Also, X should ideally home to the right, not left
Random GRBL question.. will OB ever support point cloud. I know some other GRBL senders/packages (bcnc I think, and some commercial/open source pcb milling applications) support it.
I changed a few things and now it all works as it should. It homes and backs off the switches the correct amount. I fixed it before I got on to the forum this am and read your posts. What I discovered is that the documentation I had for the settings was not correct. but I experimented around to discover that. So I guess we can close this whole episode. I will still change to an opto isolator and remove the Hiletgo solenoid board. should have my parts in the next day or 2.
What the heck is a "Hiletgo solenoid board"? Optocouplers are the way to go. see: CNC Optical Limit Switch Isolator - GRBL by The Eccentric Workshop on Tindie for an example. It's virtually impossible for noise to get through an optocoupler. MG
noise doesn't go thru a solenoid switch either especially if it is 24 volts etc. but if you had read the previous you would have seen that all this has been solved and opto isolator is going in not because of noise but because of accuracy.
Almost certainly not- the point of CONTROL is to be dead simple and intuitive for absolute beginners. It's usable for the basics, but it was never intended to have the more advanced features that people can get lost in and take up too much dev time maintaining. bCNC is the way most of us go who want the more advanced features (or just visible G53 coords ) "Hiletgo" is one of those pop-up Chinese brands on Amazon where they just mash words together to make the company name. DC-coupled noise, no, though the voltage doesn't really matter so much as the physical isolation. But it generates its own noise if you don't have debouncing circuitry- it's another mechanical solution, like the limit switch itself.
See To be tested at some point, sounds like an awesome feature by petervanderwalt · Pull Request #110 · OpenBuilds/OpenBuilds-CONTROL and see Z probe - warp compensation · Issue #62 · OpenBuilds/OpenBuilds-CONTROL If you have some spare time, that open Pull needs updating to merge, and testing (; I found it on a community fork of CONTROL, never had time to dig into it yet. Speaking of forks, OpenBuilds/OpenBuilds-CONTROL is interesting entertainment Of course tested doesn't mean included - but it would be cool for the PCB milling guys - so its not a definate no - the rest of Rob's observations are spot on though! And support time (; That said, we add "hard" features if we can make it easy for the users - that's the key - and it takes time to build easy to understand UIs and processes
I'm having trouble getting homing switches to work for a dual axis configuration (dual axis X with limit switches hooked to X and Z, running grbl 1.1h). My grbl settings are below. Running the homing command just runs my gantry into the sensors even though the sensors test fine (grbl reports each sensor correctly). Am I missing a setting or does anyone have suggestions on things to try? Code: $0=3 (Step pulse time, microseconds) $1=25 (Step idle delay, milliseconds) $2=0 (Step pulse invert, mask) $3=0 (Step direction invert, mask) $4=0 (Invert step enable pin, boolean) $5=0 (Invert limit pins, boolean) $6=0 (Invert probe pin, boolean) $10=0 (Status report options, mask) $11=0.010 (Junction deviation, millimeters) $12=0.002 (Arc tolerance, millimeters) $13=0 (Report in inches, boolean) $20=0 (Soft limits enable, boolean) $21=1 (Hard limits enable, boolean) $22=1 (Homing cycle enable, boolean) $23=0 (Homing direction invert, mask) $24=25.000 (Homing locate feed rate, mm/min) $25=500.000 (Homing search seek rate, mm/min) $26=250 (Homing switch debounce delay, milliseconds) $27=10.000 (Homing switch pull-off distance, millimeters) $30=0 (Maximum spindle speed, RPM) $31=0 (Minimum spindle speed, RPM) $32=0 (Laser-mode enable, boolean) $100=80.000 (X-axis travel resolution, step/mm) $101=250.000 (Y-axis travel resolution, step/mm) $102=250.000 (Z-axis travel resolution, step/mm) $110=4000.000 (X-axis maximum rate, mm/min) $111=500.000 (Y-axis maximum rate, mm/min) $112=500.000 (Z-axis maximum rate, mm/min) $120=10.000 (X-axis acceleration, mm/sec^2) $121=10.000 (Y-axis acceleration, mm/sec^2) $122=10.000 (Z-axis acceleration, mm/sec^2) $130=1800.000 (X-axis maximum travel, millimeters) $131=200.000 (Y-axis maximum travel, millimeters) $132=200.000 (Z-axis maximum travel, millimeters)
Before going down that advanced route, first get it homing with the stock config. What switches are you using How are they wired (NO, NC?) Also make sure of correct axis (If you press the X switch, does the X indicator report it was triggered), and also note if the state is correct (if you use CONTROL> Troubleshooting tab, should be GREEN when nothing is touching the switch, and goes RED when the switch is triggered)
Thanks for the quick response - I'm very new to this so hopefully I'm not stating anything too misinformed. I'm using NO NPN switches. When one is touched X sensor reports and the LED on the sensor turns on. When the other is touched XZ sensor reports and the LED on the sensor turns on. I'm checking that with the ? command. I have grbl compiled to only home the X axis in cycle 0 - it's a single axis machine with dual motors right now. Everything that I have seen so far is that it moves correctly when manually jogging (-X goes left, +X goes right, sensors are at end of right side). Edit *XZ sensor not YZ Edit 2: Also hard limits seems to trigger correctly. If I have the machine hooked up and touch a sensor with a piece of metal the hard limit triggers with ALARM 1.
Inductives? Each wired to own input? (Can't easily just parallel them up etc like a mechanical switch) What controller are you using? How's the Inductive's signals wired into the controller (most are 6-36v - so if its directly into an Arduino for example, do you use a reverse baised diode, voltage divider, optocoupler?) In the Grbl feedback? (Pn:?.... status?) or how are you checking? Ok good to know Test with Dual Homing disabled? Does that home fine? (ie is it related to the dual homing setup, or something else) Paste your config.h dual homing section? Matches your config, so that's eliminated: Default is homing to axis maximum.
I decided to take the easy route and got 5V inductive sensors. One to X board limit pin, one to Z board limit pin. Protoneer Raspberry Pi CNC hat v2.60. Brown (+) to external 5V Blue (-) to external ground + board's ground Black to X limit pin (D9) or Z limit pin (D12) My understanding is there is noise reduction builtin to the Protoneer board (capacitor, etc.). Using the "?" command. Getting Pn:X when one is triggered and Pn:XZ when the other is triggered. I moved my Z limit to Y, moved my A axis driver wiring to Y, and then removed the dual axis stuff from the config. I was able to complete the homing cycle with no issue. It triggered, backed off, moved back in slowly, then did the final pull off. So it seems it's related to the dual axis. Code: #define HOMING_CYCLE_0 (1<<X_AXIS) #define ENABLE_DUAL_AXIS #define DUAL_AXIS_SELECT X_AXIS #define DUAL_AXIS_CONFIG_PROTONEER_V3_51
I appreciate the help. I went through the cpu_map.h and everything to me seems to line up. If there was a pin assignment issue I would also think grbl wouldn't report the status correctly? Manually testing the limits works in dual mode. I can also starting moving a distance in the negative direction and hit the limit switch and it will stop the axis so I don't think it's a noise issue. It feels like there's some sort of bug in the homing code but others have reported success.
Try it with the default configs and use Y instead of X. I have played with it using Y (never X) Didn't like the feature though - much easier to build the machine square, or sync motion using a driveshaft
Good idea - the other person I saw using it was using it for Y as well. I'll give that a try this evening and report back. Thanks a lot for the help. I feel a lot closer than I was.
OK, I had a chance at lunch time to take a look. I had my limit switches mixed up between axes! When I rewired for dual homing I apparently fixed these. My axis driver wires are connected with phoenix terminal connectors. I imagine at some point I reversed these by accident. So, with my original configuration everything works! Thanks again for your assistant troubleshooting Peter!
Hello Sonny, I'm using GRBL to run the X axis power feed on my mill, with my phone as a BTLE controller. I also have CNC on my lathe and another mill, using Mach3, for which I've built the controllers. So reasonably familiar with CNC both using and configuring. I want to lash up a CNC coil winder using a couple of steppers, and it would make sense to use my GRBL control box with an extra drive chip for the winding spindle. The problem I see is that I would need to make the spindle run continuously while the feed goes one way then the other as the layers are put on. I'm thinking that the way to do that would be to define the spindle axis to have a very large "steps per" value and give it a BIG move so it rotates for a long time. I think this should work as long as I have soft limits and homing turned off - am I right in thinking this please? Thanks, John.
Hi, I'm working on a project right now where I and a few others are building a CNC machine using a plasma cutter to rotate and cut notches in metal tubing. I'm using grbl on an Arduino Mega to control the motor movements through Universal GCode sender, which is working great for us so far. I've run into a roadblock, however, as I try to implement a feature to control several relays for plasma cutter and status LED control. I was hoping to use some of the Mega's unused pins to switch pins high and low to flip 5 relay switches (2 for our plasma cutter and 3 for the status lights). I was hoping to turn on appropriate status lights based on the machine state as displayed in Universal GCode Sender. I have been going through the grbl library code and I think I have found where the machine state is set in system.c, so I was hoping to add code to that to flip specific unused pins high using the method described here (https://www.tderflinger.com/en/arduino-blinking-led-pure-c). I have been doing my testing thus far using the Mega's Port L (pins 42-49) as this port does not seem to be used by grbl. I have tried adding lines of code as shown below directly into system.c and also modifying cpu_map.h to add additional definitions based on the formatting of the existing definitions. Unfortunately, I have had no success in changing pin states using either method. I do not have any prior experience working with Arduinos in C rather than .ino scripts, so any advice on how to implement additional pin control would be greatly appreciated. Code I tried inserting into system.c (specifically in the system_execute_line function where the sys.state is set to STATE_IDLE), with the intention of setting pin 42 (Port L pin 7) high: DDRL |= _BV(7); PORTL |= _BV(7); Code I tried inserting into the cpu_map.h definitions: #define LED_DDR DDRL #define LED_PORT PORTL #define GREEN_LED_BIT 7 #define LED_MASK (1<<GREEN_LED_BIT) with this code inserted, I tried to add the following to system.c to set pin 42 high: LED_PORT |= (1<<GREEN_LED_BIT) Is this the right approach with the wrong implementation, or is my idea completely wrong?
Anyone have experience with running CAMBAM produced g code through Open Builds CONTROL? I'm getting this error (see image). Seems like I might need to find the right post processor? Any suggestions what that might be?
