Cheers thanks for the response. I will look into the SketchUcam as i use sketch up quite a bit. With regards to the Z axis my negative take the axis away from the job. Could this be a mix up on the ardunio board? Or do you know how i can correct it?
You can reverse the Z (or any other axis) by changing a setting in GRBL in GRBL settings . you dont say what GUI you are using, but it may have a settings panel for this (OpenBuildsCONTROL has such a panel under 'GRBL Settings') You should read the whole GRBL wiki now anyway. Knowledge is power!
Thanks so much for the help. I will go check it out, just would also help if i understood what they were saying half the time ha ha, but you guys have set me on the right path at least.
@David the swarfer Sorry the late reply! >_< UGS-P will, upon receiving the Return to Zero command raise Z to the top, move X/Y to 0, and then lower Z to 0 which is okay for parts that were Zeroed on top of the Stock but becomes an issue with ones that were Zeroed on top of the Spoilboard like after flipping a part that take reference from the previously cut top side now being on the bottom as it would then try to drive the bit through the, most likely, still present stock which is kinda "meh" to say the least :° I'll be checking those Macros out tomorrow ( actually today ). Question though... The way I read it, it appears as if one Macro sets the Offset while the other removes it. Wouldn't that mean I'd have to use them in that order for them to work? As always start with Milling > Do the Macro to apply the Offset > Do some Lasering > Remove the Offset. What happens if, for whatever reason, I decided to start with Lasering first and then decide to switch over to Milling? Once the Lasering is done I'd have to remove the Offset but that was never written to begin with since I didn't start with Milling which would then have the Offset written before switching to Lasering, no?
I agree that that is a bad sequence. Moving to work Z zero should not be part of the macro. that is the idea. What happens if, for whatever reason, I decided to start with Lasering first and then decide to switch over to Milling? Once the Lasering is done I'd have to remove the Offset but that was never written to begin with since I didn't start with Milling which would then have the Offset written before switching to Lasering, no?[/QUOTE] You can do that but you will still need to set the initial part zero using the milling spindle, then click the 'offset of laser' macro, do the laser cut, then click 'go back to milling' and do the milling. You could create 4 macros, 2 that work for milling -> laser and 2 that work for laser -> milling, but then that is an extra thing to remember. I believe it safer to just use the 'milling to laser' sequence every time, even if you do the actual laser cut first.
Homing problems Setup Arduino Uno CNC Shield 2 x Stepper Drives DVR8825 4W Diode Laser CoreXY setup When setting $23 = 1 it only inverts X axis not the Y axis. System works good without homing enabled.
Hi I have just started using my 4axis GRBL foam cutter all was going well then all of a sudden I get this COM3 problem saying (please select a comport or connect the cable) Could someone please help me with this problem please note that I am new to too all of this and I do not know much about computers Regards John
Have you looked at this gnea/grbl If you look at the explanation for step port invert, mask it explains how the mask works - it is a binary mask so to invert X and Y you need to set (decimal) 3. Alex.
the Wiki says $23 - Homing dir invert, mask By default, Grbl assumes your homing limit switches are in the positive direction, first moving the z-axis positive, then the x-y axes positive before trying to precisely locate machine zero by going back and forth slowly around the switch. If your machine has a limit switch in the negative direction, the homing direction mask can invert the axes' direction. It works just like the step port invert and direction port invert masks, where all you have to do is send the value in the table to indicate what axes you want to invert and search for in the opposite direction. and the 'step port invert mask' can be read about as well
My problem was a burnt out Mega 2560 R3 Mega 2560 REV3 ATmega 2560-16AU Board This might help someone else Mega 2560 R3 Mega 2560 REV3 ATmega 2560-16AU Board
Hi model maker Thanks it had me worried there fopr a while but a friend of mine came to the rescue and found the problen in no time it turned out to be a burnt out Mega 2560 R3 Mega 2560 REV3 ATmega 2560-16AU Board so I am back up and running again Regards John
@Gary Caruso I am able to load GBRL onto the mega as far as I can tell, used both the IDE and Hex loader, have tried all baud rates in UGS. Sorry I mean when trying to load the Firmware settings in the controller software. To makes sure the boards were OK, I used the simple Blink sketch to test them, Blink works fine on both boards. Cheers MM
Hi All Finally got it fixed, looks like there was an issue with my Arduino IDE, unistalled it, deleted any folders and references, then reinstalled the IDE. After reinstalling GBRL installed and can communicate with the controller software. Cheers MM
I use a program called Xloader instead of the Arduino IDE. Very quick and easy. Works well with Uno and Nano, not sure about Mega. Needs the internal boot loader. MG
I'll have to check that out, Arduino IDE is bloated (more features than i need) and confusing IMO. Gary
Hows it going everyone! So I have been doing quite a bit of reading on the GRBL Github Page but I cant seem to find a direct answer to my problem. I have a GRBL CNC Shield just like this one and it works great. I have been having a blast with this little desktop router I built mainly to produce PCB's. I picked up this spindle from ebay and on its control board it has a screw terminal for PWM. Awesome so I find the pinout for PWM on GRBL v1.1 which is pin 11. I connect pin 11 to the PWM terminal on the spindle control board and it works !! So my first issue is that the spindle does not go full speed, I want to say it goes 75%, Im not entirely sure I just hear an audible difference in comparison to manually setting it to full speed. Do I need to boost the signal or something? or is there something i should changed it the firmware? I poked around in the firmware changing #define SPINDLE_MAX_RPM and other settings but nothing really seemed to make a difference. Second issue I have but have not tested yet, the GRBL CNC Shield pin 11 is considered the z limit switch. So when I want to use the shield do i treat the z limit switch as the PWM pin, if thats the case what happens to the Z limit switch pin. I poked around the CPUMAP config file and found an if statement saying that if the spindle is enabled then the new z limit switch is pin 12. So on the CNC Shield are the spindle pins now the z limit pins? Sorry if I am not explaining this the best but I hope you can see the predicament I am in. Basically what happens to the z limit pin on the GRBL CNC Shield when it is taken as a PWM pin? I will be doing some testing after work to investigate this issue and will post my discovery. I thought maybe someone here might know what to do or whats going on. Thanks for reading!!
If you are using GRBL version >1.0+ the pins are already set up with pin 11 as PWM and pin 12 as Z limit. No tweaking is necessary. How are you setting your spindle speed? You should have a g-code instruction something like: G0 M3 S10000 where G0 is a rapid instruction, M3 turns the spindle on, and S10000 sets the spindle speed to 10000. Note that the Spindle speed needs to be set up by using min and max spindle speed settings according to it's specifications. So, set $31 to your minimum spindle speed (in your case 3000), and $30 to max spindle speed (12000) according tho the spindle manufacturers specifications. This will set the PWM range from 0=3000 RPM to 255=12000 RPM. Note that this is not an exact setting, YMMV. Unless you have a tachometer to verify speeds, you are just going to have to live with any error. A few hundred RPM here and there isn't going to make any difference in your work. As far as your GRBL Shield question, you will have to check the dox to see how they handle the difference between GRBL versions <0.9 and GRBL versions >1.0. The pinout change happened in this version change. You probably don't have to do anything but connect it to the right pin, but there may be a jumper or something. The fact that you can change speeds means you have it connected correctly. MG
Metalguru, Thanks for the reply !! That makes sense I remember imputing some values for spindle speeds but never checked the specks of my spindle in the first place! I feel a little dumb haha! Ill make the change when I get home from work, I have a feeling that that problem is in the past! Yeah that was my logic as well I was just going to solder a wire off the shield directly where pin 11 is and send it to the spindle control board. Switching gears to the GRBL shield, what do you mean by dox? Is that some kind of documentation created by the makers of the GRBL shield documenting what they did to accommodate the new v1.1 pinout? Similar to the direct soldering to the pin 11 pin for PWM could I just create my own limit switch circuit bypassing the shield and soldering the Z limit switch to pin 12 directly ? Thanks again !
By dox I mean dox, surely there was some kind of documentation with the board when you bought it. If not, Google is your friend. MG
Iam designing a certain cnc laser machine where i need to make the $100 changing consequantly while working depending on an equation I will give . All what saw about changing it in GRBL was static
Unfortunately that's not what $100 is for, and will not work. Checkout fra589/grbl-Mega-5X as a better alternative (Grbl stays in degrees, your code adapts mm to degrees on the fly)
I am experimenting with grlb V1.1 on an Arduino Uno ... using a VB front end ... I am running into some trouble with the responses from Grlb while attempting to keep the buffer full .... Following is the g-code I am sending: Code: G91 F10000 X100 X-100 X100 X-100 X100 X-100 The g-code is "cleaned" prior to being sent so that <crlf> is converted to <cr> and <crcr> is converted to <cr> ... In theory I should get the following responses: Code: ok ok ok ok ok ok ok And, in fact, sometimes I do; however, sometimes I get no response at all, sometimes I get a bunch of garbage like this: Code: (shown as Hex Character Codes) Response X: FE 80 00 00 08 08 00 00 00 00 00 20 23 02 00 17 6A 00 00 20 02 02 00 17 6C 20 02 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 (Note: This Response contains No "ok" responses, No Carriage Returns and No Line Feeds) Response X+1: 69 47 31 30 30 00 30 30 30 30 00 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 FF 00 16 06 04 56 B0 76 04 04 AA AB 00 00 00 20 23 02 00 17 6A 02 00 20 02 02 00 17 6C 20 02 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 (Note: No Carriage Returns or Line Feeds in the above block ...) 6F 6B 6F 6B 6F 6B 6F 6B 6F 6B 6F 6B 6F 6B (Note: The last 7 lines of this response are 7 x "ok" ) Response X+2 16 06 04 56 B0 76 04 04 AA AB 00 00 00 20 23 02 00 17 6A 02 00 20 02 02 00 17 6C 20 02 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 (Note: No Carriage Returns or Line Feeds in the above block ...) 6F 6B 6F 6B 6F 6B 6F 6B 6F 6B 6F 6B 6F 00 07 34 6F 6B 6F 6B 6F 6B 6F 6B 6F 6B 6F 6B 6F 6B (Note: The Last 13 lines of this response contain "ok") Response X+3 42 8E 00 00 42 B0 AA AB BC A0 00 20 23 02 00 17 6C 20 02 02 00 17 6B 00 20 02 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 00 07 34 FF 00 16 06 FE 80 00 00 00 08 00 00 00 00 00 20 23 02 (Note: No Carriage Returns or Line Feeds in the above block ...) 00 17 6A 00 00 20 02 6F 6B 6F 6B 6F 6B 6F 6B 6F 6B 6F 6B 6F 6B (Note: There are 7 "ok" lines in this response) Response X+4 06 AA BA 04 DA 04 02 AA AB C8 00 00 20 23 02 00 17 6C 20 02 02 00 17 69 00 02 00 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 6C 20 02 02 00 17 6E 02 00 17 20 02 02 00 17 6E 6B (Note: No Carriage Returns or Line Feeds in the above block ...) 6F 6B 6F 6B 6F 6B 6F 6B 6F 6B 6F 6B (Note: There are 6 "ok" lines in this response, Plus "6E 6B" = "nk" LoL) The "rules" for displaying the above responses are: <crlf> is retained, <cr> and <lf> are converted to <crlf>, <crlf><crlf> is reduced to <crlf> all other ascii characters are displayed as lines of 16 characters as hex ascii numbers .... I know for most people this is not the most intuitive way to look at responses, but it is the only way I know to "show" otherwise non-displayable characters. I should note that the grlb Uno was connected to a driver/stepper for the first 3 responses, and disconnected for the final two (to make sure the issue was not noise from the driver/stepper. Confidence is high that the PC, USB and Front End are not the cause of the trouble ... I have numerous Arduino 2560s and UNOs Flashed with different firmware that can communicate flawlessly with the same front end on the same PC ... That being said, it seems odd that I can't find any reference to this issue ... I guess it is possible the UNO I am using has some type of clock issue and there are some framing errors .... that might explain something like "6E 6B", but I don't think it would explain large blocks of extra characters ... ? Ultimately the goal is to replace the PC with a second Arduino in a stand alone unit with a display and analog inputs for speed and length of stroke, (grbl is overkill for this application, but because the speed and length of stroke need to be user adjustable, it seemed easier to create a set of canned cycles that "create g-code on the fly" using the analog length and speed inputs .... letting grlb handle acceleration ... ) Any help resolving this would be much appreciated! Fish
you need to read the wiki for the details on interfacing with grbl. then you need to look at existing , working , interface code for examples on doing it correctly. pretty much everything you need is on github.
Thanks David! So I don't bury the lead: my Front-End was at fault ... You are 100% correct about (re) reading the wiki ... I started this project back in the Spring ... got the basics of a front-end I have used for years modified to work pretty much the way I wanted with grbl... then my computer crashed, life happened and 5 months passed ... I forgot a lot of what I had read AND that my code-writing session ended in a computer crash ... so what I remembered was that "I had it working when last I worked on it", and I ***-u-med that I was now receiving some type of non-ascii error messages that had not been present previously. As I re-read the wiki and reviewed my code I remembered the crash and realized how many "stubs" there were in my front-end code .... obviously I lost more than a few changes in the crash ... So, I spent a few hours filling in enough of the stubs in my code to keep a steady flow of g-code flowing, but something Peter said in a PM kept nagging at me, While I have been anxious to try grlb on a traditional 3-Axis machine using a real PC, this project is simply not a good fit .... This project is a single Axis machine that only needs a couple of modes of operation .... literally a "speed knob", a "min - max" travel knob, a Direction Switch and a SPDT momentary switch .... (FWIW, I am building a stepper-based Tapping Head ... the head uses gravity and the Tap itself for "feed rate" ... an operator lines the Tap up with a pre-drilled hole and holds the momentary switch "down" to tap, and "up" to remove the tap .... the "speed" adjusts how rapidly the tap spins, the "min - max" travel adjusts how many steps the Tap travels forward before reversing to break/clear chips ... the "Direction Switch" is for left/right hand tapping....) I have a "mock-up" (that uses a PC // Arduino to control the stepper driver) and using a 10:1 Gear Reduced NEMA-23 Stepper can tap 3/8-16 holes in 1/2" 1018 steel in just over a minute ... smaller sizes and aluminum are quick/easy. My thought with grlb was that using g-code to create "settings" based on material//tap size and stored in a second Arduino host would make fine tuning easier ... but a laminated piece of paper with the approximate analog speed/travel settings in a chart is all that is truly requisite. While the precise acceleration // deceleration algorithms in grbl would be nice, because "lost steps" and "extra steps" are trivial in this application, simple acceleration // deceleration routines hard-coded in firmware should be sufficient .... Finally, though I have muddled my way through the start of a functional front-end on a PC in a high-level language, I feel confident I would run into more problems porting that front-end to an Arduino than I would simply replacing the PC in my existing mock-up with a few analog inputs. Again, Thanks for your response! Sorry I posted before going back and re-reading the wiki ( AND my own front-end code). Fish
Still, instead of two Arduinos and Grbl, if its just one axis, just control it directly from your own sketch. See OpenBuilds/ArduinoStepperDriver (interface your switches and knobs in the sketch directly)
Hi, I'm not sure if this is the right topic, maybe you can redirect me if i'm wrong. BTW, i'm always asking myself if GRBL can lose step due to gcode coordinates resolution. I mean, I'm creating the gcode files through Fusion 360 CAM packet, and on gcode I can see example X12.345 and i've 0,01mm of resolution (1/4th microsteps,200-step motors, 8mm t2 leadscrew). Can this resolution difference give me problems? I'm building an MPCNC but having problems with Y (double motor) and X axes shifting some step, so I'm searching for the problem. If someone can also explain me (roughly) how grbl handle this resolution difference, i will be grateful. Thanks in advance, 50Special
