I am not sure if I am in the right place to ask this or not, but I am going to try anyway. I am creating a saw stop stop that uses a stepper motor to move a stop via a belt. I am using grbl flashed to an arduino uno to control the stepper. Everything is working fine. I have the stepper moving the stop and calibrated the distances. However, I can't get the homing to work. I am only utilizing one axis and I know grbl is supposed to home the z first. So, I went in to notepad and edited the config.h file and have changed the file to this: // NOTE: Defaults are set for a traditional 3-axis CNC machine. Z-axis first to clear, followed by X & Y. #define HOMING_CYCLE_0 (1<<X_AXIS) // REQUIRED: First move Z to clear workspace. //#define HOMING_CYCLE_1 ((1<<X_AXIS)|(1<<Y_AXIS)) // OPTIONAL: Then move X,Y at the same time. // #define HOMING_CYCLE_2 // OPTIONAL: Uncomment and add axes mask to enable As you can see, I have changed the "required first move z to be my x axis. The x axis is how I am controlling the saw stop. If I want to make a move, I type in something like "G0 X15" and it will move 15 inches. My WPOS that reports when I type "?" in the serial does not match the distance it actually moved, but the movements are accurate. When I try to home the machine with "$H" I get no movement at all. I have enabled the $22 =1 and tried with $21=1 and $20-1, but no luck. I know the stepper is working and will move, but I get no movement durring homing. I have also tried both $5=1 and 5=0. The switch I am using is NC so I assum I should be using 5=1, but neither make a difference. PLEASE HELP!!! IT is driving me crazy. Here is the current config I have. 16:24:23.453 -> $0=254 16:24:23.453 -> $1=0 16:24:23.453 -> $2=1 16:24:23.453 -> $3=1 16:24:23.453 -> $4=0 16:24:23.500 -> $5=1 16:24:23.500 -> $6=0 16:24:23.500 -> $10=254 16:24:23.500 -> $11=0.010 16:24:23.500 -> $12=0.002 16:24:23.500 -> $13=1 16:24:23.500 -> $20=0 16:24:23.500 -> $21=0 16:24:23.500 -> $22=1 16:24:23.500 -> $23=0 16:24:23.500 -> $24=25.000 16:24:23.500 -> $25=500.000 16:24:23.500 -> $26=250 16:24:23.500 -> $27=200.000 16:24:23.500 -> $30=1000 16:24:23.500 -> $31=0 16:24:23.500 -> $32=0 16:24:23.500 -> $100=254.500 16:24:23.500 -> $101=250.000 16:24:23.500 -> $102=250.000 16:24:23.500 -> $110=300.000 16:24:23.500 -> $111=500.000 16:24:23.500 -> $112=500.000 16:24:23.500 -> $120=10.000 16:24:23.500 -> $121=10.000 16:24:23.500 -> $122=10.000 16:24:23.500 -> $130=200.000 16:24:23.500 -> $131=200.000 16:24:23.500 -> $132=200.000 16:24:23.500 -> ok THANKS!
The obvious question (sorry if you have already covered this) - how have you wired your homing switch? You have set $5=1 does the homing switch send a high signal when triggered. If not (sends a low - 0V) then set $5=0. grbl/settings.md at master · gnea/grbl Alex.
As of right now, I have the homing switch (NORMALLY CLOSED) one wire to ground and the other to pin9. Should one pin be 5v and the other to pin 9? One thing I should point out is, I just changed the config.h file back to the z axis to home first and commented out the other two #define HOMMING lines because I don't need them. I changed my pulse and dir pins from 2 and 5 (x axis) to 4 and 7 (z axis) and now I do get movement when the $H command si typed in. HOweve, the limit switch (as its wired) does stop the z from going in one direction, but then it starts in the other direction and will not stop unless i turn power off. Not sure what is going on. But I only want one limit switch for the axis not two. Thanks!
Wiring for the switch and $5 setting is correct for a NC switch. I'm a bit rusty with the Arduino, but I thought for grbl 1.1f (you didn't mention which version of grbl you are using) pin 12 was the Z axis switch? Alex.
Thanks again for your quick responses!! Yes, I think you are correct, z axis limit switch is pin 12, but the pulse and direction for z axis is 4 and 7. I have it now where the z axis will attempt to home upon entering $H, but if the switch is pressed while it is attempting to home, the motor reverses direction and will not stop at all no matter what I do. Other than kill the power. Thanks!
I think I may have figured that issue out. I think that was in my $27 config from above. I had changed it trying to figure out the other. I have it homing correctly, but once it finishes homing the z axis its like it freezes. Like it is "homing" the y and x axis that are not connected. I thought by commenting the define lines above this bypassed it? Edit: I see you had already noticed the problem while I was typing... sorry Any idea why I can't bypass the other two axis? Thanks!
Correct, but did you comment it in the correct location (Arduino Libraries > grbl) and did you properly compile and upload it.
This is probably the problem…. When I downloaded the grbl master file, I downloaded it to the desktop. When I made the change to the config file I opened the file up on the desktop and made the change. This is apparently wrong. So, I need to go to the config file that is located within the file location under the arduino folder? Thanks so much for the help!
Ooops, I was under the wrong account with the last reply above. I have found the file under arduino/library/gfbl and edited it. I will give it a shot tomorrow, but I feel like this was the issue. THANKS!
Refer the Grbl Wiki for instructions yes. Editing the config is just one of the steps (to tell the source code what to do, still needs compilation for that change to take effect and upload before it is on your arduino/controller before you can expect it to work)
Can you explain why my WPOS (what I get if I type the '?' command in serial; I think this is work coordinates) do not match my actual distances? I'll try to explain better. I have converted GRBL to report in inches, and adjusted my steps. So if I type in Serial "G0 X15" The machine moves to 15 inches from 0. This works well. However, after making that 15 inch move, if I type "?" instead of WPOS reporting a 15 for the x axis, it will report a much smaller number. How can I change that so that it reports 15 for the x axis when I type "?" Thanks again!
Zero your Work Coordinates using G10L20/G10L2 where the origin is (for most rotaries that would be centerline)
Ok, So once its hommed, if I put in a line like G10 L20 P1 X0 This makes my work coordinates 0. That works good, but I have been calibrating everything with my N0=G21 (reports in metric) if I change that to N0=G20 to report in inches, my calibration is WAY off. I don't understand how to set it back now so that it works with inches reporting and the calibration correctly. When it was working right, my $100 = 254.5 and my $110 = 300 and my N0=G21 And if I pressed G0 X15 it would move 15" exactly, but my WPOS would report like 1.2345 (Even though it started at 0 before the move) which I assume was in metric. However, if I change my N0 = G20 then enter G0 X15 it moves ALOT farther than 15 inches, but it is reporting right in WPOS. If I change my $100 = 10 it moves supper slow! What am i doing wrong? Thanks!
Negative. G20/21 has no bearing on reporting, that is you telling Grbl "the lines following hereafter are in mm/inch" Reporting is set in Grbl Settings but note some host like OpenBuilds CONTROL wants that in Metric and will not allow you to change that setting, as we do our own conversion in the UI, keeping all parsers and backend in Metric. Might be G90 vs G91. Do you want to "move another 15 that way" or "move to the coordinate X15 - i might be at X=2 now (the DRO will tell you) and moving to X15 is only 13 inches of movement for example" Include the G90/91 so you know what mode you are in. Make sure axis is calibrated too and Max Rate and Acceleration suitably tuned so stalls doesnt make you come up short
also make sure your jog directions are correct. jog+ must jog away from the switch then you must reverse the homing direction so that homing moves negative to find home You should be using OBControl for setup, just to make life easier. (-:
I don’t think I have been very clear with what my issue is. I am going to try to explain better. I have now successfully edited the config file (edit in the correct file location). I am only using one axis (x) the other two I have the homing for the other two axis disabled in the config file. There is no problem here…now. The x is homing as it should and the others are disabled. Thanks @Peter Van Der Walt! I want to be in absolute mode which I am and it works as expected. Everything seems to work as I expect except if I enter a “?” To grbl, the location it returns (WPOS) does not match the physical location of my saw stop nor does it match what I have entered. What I entered matches the physical location, but it doesn’t match the WPOS. Example: I press $h. The x axis homes correctly and I get an “ok”. I center my WPOS coordinates so if I I press “?” every axis reads WPOS 0,0,0 I then enter a desired distance for the saw stop (“G0 x22”) The saw stop correctly moves to 22 inches on my external scale. if I I enter a “?” Now, I expect the WPOS to look something like WPOS (22,0,0). However it doesn’t. It looks something like this WPOS (2.453,0,0). I can’t find any significance in the number it is reporting, the 2.453 is just an arbitrary number I used for this example. I can’t figure out how to get this to report correctly. Everything else to this point seems to be working as I expect. @David the swarfer i would do these adjustments in the openbuilds control, but will it work with just one axis turned on? Thanks again for all the help!
What is the actual actual number? Perhaps we see a pattern. Did you wait to send "?" when the machine was idle? What are you sending/receiving with? Are we sure its not delaying in parsing/queueing? If its not CONTROL, do try CONTROL as an elimination step if we suspect serial sender to be an issue. Do you have Report Inches turned on in Grbl Settings? (for CONTROL you want it disabled, but if you are just using a raw serial terminal it may help to see it in inches) When you send G0 X20 how sure are you are in inches? Did you send a G20/21 and G90/91 just before to ensure you are in the correct modal. CONTROL will work fine with 1 axis. Home. Jog to where you want the origin, or if its already there after homing its fine. Click SetZero. Use jog buttons in Incremental mode to move (Not manual commands - buttons sets modals so lets us check another thing) . Check DRO - should be accurate. Check real world. Should also be accurate. Report back on any deviance from above.
I am not at the machine right now, but I will provide it when I get back. Yes. I am using the arduino IDE serial monitor to send and receive commands with the uno. The project itself actually gets a little more complicated than that, as I am going to have a keypad to enter the desired distance for the saw stop and an lcd to display it. An arduino mega (connected to keypad and lcd) will be sending commands over serial to the uno with grbl. However, I am not doing that to set it up. I have the uno with grbl connected directly to a laptop with the IDE to send and receive commands. No other changes have been made to the grbl file other than disabling homing of the Y and Z axis. I have $13 = 1. I believe this is the correct setting for reporting to be in inches. Umm.... I don't really know that I understand. Do these need to be sent each time before a move? or one time at start up? Or, can they be saved so they are always in a set mode? Edit: I went and looked because I had forgotten what G20/G21 are. I think this may be my problem, but I don't know how to fix it. I think I am currently in G21, but if I change to G20 my calibration is WAY off. So, if I change to G20 and type a command G0 x20 it would go WAY too far and crash. The only way to calibrate that I know is changing the steps/mm, but this makes the machine move really slow as I have to change my steps/mm from 255 to around 10 for it to be close to accurate. Thanks!!
Grbl defaults to mm. You can see the default modals by sending $G right after Grbl boots: Grbl v1.1 Commands · gnea/grbl Wiki The Grbl Wiki also shows the defaults in the same link by Bolding the default value in the table You can send it any time you are unsure in which mode you are. In CONTROL for example: OpenBuilds-CONTROL/jog.js at master · OpenBuilds/OpenBuilds-CONTROL we err on the side of caution: i.e We send the G91 and the G20 in every jog command - in case something or someone changed the mode on us, we are not going to need to wonder or worry about the mode, we set it to what we want it to be. That's why GCODE job files always includes the modals in the header too - no need to assume, if you can explicitly set it to what you want it to be Use CONTROL to do your calibration, and it's UI handles the Imperial conversion for you on the DRO. Calibration wizard is mm though - but as Grbl is mm internally, perfect too. For an understanding adjustment the long way round though: G20: Inch, G21: mm: See G Codes (hehe notice the little note they have underneath it in reference to above points) So, send G20 first Zero your Axis with G10 L20 X0 Move G0 X10 (Moves 10 inches supposedly - assuming it is close to calibrated. If not, it may move very little or far too far) Take your measurement Calculate corrected steps-per-mm Code: newstepspermm = (currentstepspermm * (commanded distance / actual distance)) Apply in Grbl settings Retest What mechanical drive system are you using? Our leadscrews are around 199/200 steps per mm Prior to calibration, lets first calculate the steps-per-mm so we get in the right ballpark Too slow could also be MAX RATE in Grbl Settings (if calibration is off, this will be off too - calibrate first, then tune acceleration, max rate)
(; perfect use case for a Javascript Macro in CONTROL (; Getting started with Javascript Macros in CONTROL / Library of Macros created by the community
WOW! Thanks for all the help! I think I am following the calibration stuff although, I don't understand what CONTROL does to handle the conversion from mm to inches, but I'll give it a shot. However, you lost me with the JAVA macros stuff? What are you suggesting I should use it for? Thanks!
Everything in CONTROL is mm, when you click the Inch tab we: redraw the Grid so the pattern is in inch, and update the labels on the 3D view OpenBuilds-CONTROL/jog.js at master · OpenBuilds/OpenBuilds-CONTROL change the values of the jog buttons. OpenBuilds-CONTROL/jog.js at master · OpenBuilds/OpenBuilds-CONTROL And the DRO shows (dro value in mm divided by 25.4) instead of mm values for all feedback received OpenBuilds-CONTROL/websocket.js at master · OpenBuilds/OpenBuilds-CONTROL Entirely cosmetic, the backend and Grbl reporting, and jog commands and probe commands etc are all Millimeters
Instead of the arduino+lcd+keypad+lotsofcustom code Win10 Computer (think 10" $50 tablet from walmart mounted near the saw), running CONTROL. Simple Javascript macro to create a user Interface with an input form - enter dimensions, click "move to" so you can do the cut. CONTROL does all the parsing, sending, etc making it super easy
I apologize I didn’t notice… I’m a bit slow! Ok, now I love the idea of doing this (using tablet with CONTROL) instead of what I am doing currently, but I have another issue you can probably help me with working out. I am also planing on using the mega in addition to the keypads and lcd to have a motor of some kind (servo, linear actuator) to “lock” the saw stop in place once the stepper has stopped moving. I know the stepper will lock on its own, but I need something to hold better than the belts I’m using. Would there be a way to control something like this with using the macros and CONTROL? thanks!!
As its a saw, can we assume its in a workshop setup? And do you have compressed air available? If so, may I suggest a Pneumatic Actuator, plumbed through a solenoid tied to the Coolant output: docs:blackbox:connect-coolant [OpenBuilds Documentation] M8 to turn the air solenoid on, Pneumatic actuator pressurises and pressed down on the stop. M9 turns off the solenoied, depressurises the actuator (can either spring return, or use a double acting solenoid that pushes it back) Macro can send the M8/M9 too (either part of the move to button, or seperate lock/unlock button) Something like MAL25x200 25mm Bore 200mm Stroke Double Acting Mini Pneumatic Air Cylinder (but finding one with a shorter stroke will be fine for your use case, Amazon results not so great as it tries to apply geolocation to me, but something like https://www.amazon.com/uxcell-Pneumatic-Cylinder-Single-Double/dp/B07VD1HCGD/)
Ah. Your ideas are better and better! I do have compressed air and could do this very interesting. But I assume the m8/m9 commands just send a high/low output signal to the corresponding pin on the uno with grbl? If so, I could use these outputs to drive any kind of dc motor I assume. Thanks!!
DC motors need reversal too, so no (assuming your motor driven mechanism locks in place, you have to reverse the motor to unlock?) If you aren't using a spindle, you could re-use Grbl spindle-direction pin, along with the spindle-pwm pin but that needs a motor controller too, and then you are not sure where in the travel the DC motor is. I still think the pneumatic stop is a lot simpler to implement and super reliable As you have a bare arduino, not a BlackBox, you'll just need a N-channel mosfet in there too (or get a BlackBox (; )
I will look in to it. In the mean time I am connected to it now, and have CONTROL. Pulled up and connected to the arduino. It says it’s connected, but it will not accept any commands ex $h. I don’t get an ok an error or anything. The command disappears, but nothing happens. I don’t know why, but in the connection box it says ch340 arduino fake. Does this mean something? thanks!
