So I just thought of something, I tried the other version of GRBL. And I also tried reloading GRBL to Arduino. Why is it that whenever I reload GRBL, and I connect UGS. The GRBL Settings are still the same as before, they don't go back to the default settings, it's like they are saved. my understanding, was that when I uploaded a new code to Arduino, it was supposed to erase everything, and upload a new version. But this doesn't seem to be the case. This makes me wonder that the first version of GRBL that I uploaded is still on there. The first version may have been the wrong version. Is there a way to manually delete my Arduino?
You say you expect and get a 10K resistance between pin 13 on the Arduino and the Enable pins on the driver chip. That sounds like the problem to me. I expect no resistance. Check that first. The enable pin with the shield unplugged should have a 10K resistance to 5V, which will cause it to "float up to 5V" in the absense of anything else driving the D13 line high or low. Thats what you want - the default "don't know where I am" state should case the motors to be disabled. But I expect a direct connection between D13 and the enable pin on the driver chip. Not 10K resistance. So once you plug in the shield and and tell the arduino "set pin 13 high, set pin 13 low" then whatever happens on pin 13 should also happen on the driver chip EN pin. I suggest after checking that unwanted 10K resistance you plug in your shield and run the little program of your own that goes High / Low on pin 13, and check it out again, at pin 13, and at the enable leg on the driver chip. For the second part of your question, I don't know where the settings are stored. But the Arduino has three kinds of memory - FLASH for program code, SRAM for short-term variables while the program runs, and EEPROM which will keep information even if you re-flash the chip. So if the settings are stored in EEPROM (I don't know if they are) then this is "by design" that your settings do not revert. There is some magic command you can give to UGS to "restore all settings to the compile-time defaults". Peter
When I said that I expected 10k resistance in between Arduino Pin 13 and the EN legs, this was because I knew that there was a resistor in series between those two test points. I've attached a photo of the shield. R1 is the resistor that is connected to Pin 13. I tried your sample code again on the Arduino, and this time I hooked up the shield and tested the EN Legs. This time I got 5V to 0V. Blinking on and off. I then changed it so that it was set HIGH indefinitely. this Produced 4.68V on the EN Leg Then changed it so that it was set LOW indefinitely. This produced 0V on the EN Leg So what your saying with whatever PIN 13 is doing. It is also doing that on the EN leg. This still doesn't (according to my limited knowledge) tell me why GRBL is sending 0.5V out on Pin 13 when the motor is supposed to be moving or not. It doesn't change a darn thing no matter what code I send it. I can't get the EN leg to show 0V when GRBL is loaded onto the Arduino. Should I try this without the 10k Ohm resistor? I could remove the resistor and jump the connection with a jumper wire. Does anybody know that magic code for UGS to send to restore everything to defaults?
gnea/grbl $RST=$, $RST=#, and $RST=*- Restore Grbl settings and data to defaults You seemed to talk previously of TWO 10K resistors. One pulling EN up to 5v, the other in series with pin 13 - so a 10K resistance between D13 and the EN pins on the drivers. Certainly do NOT short the 10K resistor that is pulling the line up to 5V. (i.e. do not short EN permanently to 5V). If you do that, you'll be driving D13 high. Now if the Arduino tries to drive it to ground it will result in a surge of current and likely blow the driver pads on the Arduino. I think they're limited to sinking about 40ma. Your experiment above gets us closer. It is not clear to me whether your board also had its 5V and GND also connected when you sucessfuly pulled EN high then low. Try it with the external board powered. (5V power needed - not the 19v to drive the motors). If you can't get the LOW now, the problem is on the board and with that 10K pullup resistor. I somehow doubt the grbl code is at fault (unless the CPU pin mapping is wrong). But if some external resistor is holding the line high, the Arduino may not have enough oomph to drive it low. You previously said there was also a 10K resistor between D13 on the driver board and the EN line. I challenged this. Is that 10K resistor really there? Do you just have this one 10K resistor, and is it from EN to 5V, or from EN to D13? Does the manufacturer have a schematic we can look at? Peter
So there is only 1 10kohm resistor to be found. My apologies if I made it sound like I had 2. I can see by the tracks on the board that the resistor is directly right after D13 pin from the Arduino. Path is D13 - 10k ohm resistor - EN Leg. Ok So I tried your next suggestion. And I think I got unwanted results but I don't exactly know what it means. I disconnected Arduino and Directly hooked up the shield with the following jumpers. 5V to D13 5V to 5V - STAYED CONNECTED GND to GND -STAYED CONNECTED With 5V on D13. - EN leg showed 5V With 5V Disconnected from D13 - EN Leg STILL showed 5V. So my Stab at interpreting this is that there's a problem on the shield and not Arduino. And the D13 line is somehow connected to 5V somewhere. I must also mention that this board was a kit, and I was the one that soldered it all together. That's the schematic that came from the manufacturer. I'll Start pouring over this board and see if I can see anything out of the ordinary. I also just did a resistance test between D13 and 5V on the board.... 10Kohm resistance. Testing on the other side of the resistor gives me a couple 0.02Ohms I will email the manufacturer and see if that is supposed to happen. My guess is it's not....
OK, you seem to have it wired wrong. The path should be a direct line from D13 to EN. Somewhere on that direct line, one end of the resistor. The other end of the resistor onto 5V. So both the D13 and the EN pin should be connected to each other / low resistance, and both should show 10K resistance to 5 V. Here is my scrappy schematic for how I believe it needs to be:
Ok, So I think I see what your trying to get me to do... I think.... But after your Explanation, I re did it but I saw that I had to wire it up again, the same way. With no Arduino hooked up: I put 5v into where the Arduino 5V pin is supposed to go I put GND where the Arduino GND pin is supposed to go. then I manually applied 5V to the D13 Pin. With 5V to the D13, 5V on the EN Leg With nothing attached to D13, 5V on the EN Leg then I disconnected the Resistor altogether. With 5V to the D13, 5V on the EN Leg with nothing attached to D13, 0V on the EN Leg What am I missing?
You're missing that the Arduino shouldnt just "put nothing" on the pin, it actually pulls it down to GND with a little built in transistor. The pullup should be weak (10k-30k) then when the arduino does a digitalWrite LOW it activates a transistor that pulls the pin down to GND, the pullup resistor passes too little current to overcome the drain from the Atmega's transistor, and thus shows effectively 0v out. So for your test without an ATMEGA (with the resistor in place) instead of "nothing attached to D13", rather GND D13 and measure then
The purpose of the pull-up resistor (a resistor that is tied UP (i.e. 5V)) is to pull a signal to some voltage in the absense of D13 putting either HIGH or LOW on the line. Digital pins like D13 can typically be in one of three states: they are "high-impedance", which happens when D13 is declared to be an INPUT pin. (Or perhaps momentarily when you're rebooting your Arduino.) Then the pull-up resistor wins the day, and the line will go to 5V. Or, in your case, no connection at all on the line, it should pull up to 5V. But once D13 is connected and programmed to be an OUTPUT line, it will drive the line either HIGH or LOW. In both cases, D13 must win and the line should follow what it is driving. So Peter is correct: once the pin is programmed for OUTPUT, it will either drive to 5V or drive to 0 volts. You should see that same D13 voltage on the EN pin. If it is still wired with the resistor between D13 and EN (and I still don't know where the 5V connects in this case) then I reckon it is still wrong. Why do you believe this is how you have to wire it?
Ok. I appreciate your guys patience with me. What I was missing was what Peter has said. The GND has to attach to D13 to simulate a LOW output. I was only providing 5V and then NOTHING. But it should have been 5V and GND. This time I've attached some pictures to explain a few things. This Photo has 5V applied to the shield where 5V would be supplied by the Arduino. The Yellow wire has D13 pulled to GND This Produces 0V on the EN LEG This Image is the same except I put D13 to 5V (Green Wire) This Produced 5V on the EN LEG I think I see where putting 5V somewhere was confusing. I was under the assumption that I needed the 5V pin on the Shield powered in order for it to work. But I'm wrong, I just tried with just the GND (Orange) wire hooked up. And it produces the same results. So Basically I see Exactly the same voltage with whatever I supply D13. I believe this is the result that we wanted... Correct?
So I've taken the liberty of Trying what I think should be the next experiment. So I tried to set up the scenario where the Arduino is Running GRBL and hooked 5V and Gnd to the rail on the breadboard D13 hooked to a 10k Resistor, then pulled up to 5V (like your Scribbled schematic above) Then I measured D13 I immediately got 4.92V Then I started UGS, and sent GCode to send the X in a positive direction. Still had 4.92V. I then played around with whatever settings in GRBL that I thought necessary. and Continued to try to move X axis. No matter what I did. I couldn't pull D13 to GND. I then played around with the resistor. Resistor to GND produced 1.1mv on D13 Resistor Disconnected produced 0.636V Resistor to 5V rail produced 4.92V (Same as your Scribbled Schematic) All three of the above readings Did not Change whether G Code was sent or No G Code.
Hi guys, i have a question concerning a somewhat unconventional machine, and would like to know if this is possible to be done inside grbl. to get an x-axis movement, stepper 1 must be moved for y-axis movement, stepper 2 and 3 must be moved (in a ratio of 1:2) for z-axis movement, only stepper 3 is moved. might sound strange... but to give you a better understanding: if a usual setup would be [XIn] [$100 0 0 ] [XStepper] [YIn] x [0 $101 0 ] = [YStepper] [ZIn] [0 0 $102] [ZStepper] then i would need [XIn] [$100 0 0 ] [XStepper] [YIn] x [0 $101 ???] = [YStepper] [ZIn] [0 0 $102] [ZStepper] Of course it would be possible to consider this peculiarity in my gcode generation, but this would affect its readability and elegancy, so i'd rather like to include it in the machine controller, so that the coordinates actually represent axis positions, not stepper positions... Any hints? edit: system.c, line 288 and following look like this might be a starting point? best regards Simon
Are you saying stepper 2 needs to move X distance and stepper 3 needs to move 2X distance? Can not be done at the software level, you would need to change the pulley or gearing or whatever mechanical system you are using to do that.
would it work if the ratio was 1:1 ? i don't think the problem is the ratio (???), but the fact that y and z movement are interconnected at all..? the mechanical hardware is finished and is very compact/tight, so there is hardly any space left for changes. Not sure if you got it right (difficult to explain, though)..? If i move stepper 3 alone, only z-axis is affected, but if i move stepper 2, both y and z axis are affected. That means if i want to move y-axis only, i have to do a compensation move with stepper 3, compensating the unwanted z-axis movement. If this works with 1:1 ratio, could you please state where to start? NEXT QUESTION (other subject): I'd like to use an encoder for x-axis movement- not at the stepper (which would be a closed-loop hybrid servo stepper), but at the workpiece, to recognize/compensate for mechanical slippage. Say if the workpiece slips, the encoder value would not match the step count any longer, so the stepper should do additional steps until the desired position is reached at the workpiece.
what you want is LinuxCNC which can do custom motion kinematics across 9 axes. LinuxCNC LinuxCNC Documentation Wiki: Kinematics
lol, don't aks why Y-movement is rotation of an excenter and Z-movement is axial movement of that same part. Rotation is done over a splined shaft and axial movement is done over a coaxial pulley, being threaded on the inside (the inner part that is moved is both splined and threaded). For a screw drive, it doesn't matter if you turn the screw or the nut... Seperating these movements would have resulted in a less compact and more complex construction, more standard parts, more lathe work. That's why... well- maybe, but besides needing a pc with parallel port and a breakout board, it seems a bit "overkill" for this application. I'm not talking about complex kinematics, just something like ZStepper = ZMotion + 2 * YMotion ... shouldn't this be possible with grbl (or a slightly modified version of it)?
Hi All, desperate for some help, I started a new thread a couple of weeks ago but no responses. Is anyone able to assist please or even point me in the direction of another source for information/help? The issue is hard limits arent working but homing. Full details here instead of duplicating. Thanks in advance! GRBL Arduino Mega/Ramps - Homing works hard limits doesn't
Not sure if this is the right forum to post this , but I think it might be something with grbl. I can’t find what is causing this, I’m using a black box 4 , I don’t think it was happening with my previous controller or a separate arduino I had connected There always a shift on those xy spots, it switches to the opposite side if I make the circle clockwise or counter clockwise
This issue points to a bug in the GRBLMega/ramps code, which means you need to talk to the port maintainers on github (ie whoever did the RAMPS port in the first place). However, lets read the code and see what we can find: in config.h you have to disable all other boards and enable the RAMPS setup. this sets CPU_MAP_2560_RAMPS_BOARD in cpu_map.h that setting creates a lot of defaults and one of them is #define DISABLE_HW_LIMITS now in limits.c we find the code Code: #ifdef DEFAULTS_RAMPS_BOARD #ifndef DISABLE_HW_LIMITS #error "HW limits are not implemented" #endif which causes the compiler to stop with an error if HW limits are not disabled and RAMPS is enabled. This is because there is no code for doing the pin change interrupts for HW limits in the RAMPS configuration. This tells me that hardware limits on RAMPS are just not supported because the code has not been written. So, I was wrong, not a bug, a feature (-: (I think soft limits should work though, once you have homed then soft limits make sense.)
Hello again! Sorry about posting again about the same issue, but finally, working on my "self-working" cnc machine, I could use a CNC shield for ESP32 (Grbl_ESP32 Development Board Version 3.1 at Buildlog.Net Blog) so I can store the Gcode on the micro-sd implemented on the shield. Sadly, I need it connected to the computer to send the 3 messages to start executing the .gcode: $FM // Enables the microSD $F // Show all the .gcodes inside the microSD $F/mycode.gcode // Executes the gcode I've noticed that the Rx and TX pins from the ESP32 are not used on that CNC shield, and my question (a bit noob I must admit) is: Is there any way to send that 3 codes from another ESP32 or arduino (using logic level shifters) via serial? Should be easy to make a little program on the "master" ESP32, like if "Start" = 1 Then (Send Gcodes) Have anyone tried to send commands to GRBL using another ESP32, and not a computer, or even send them via Serial/UART? Thanks!
Self-working - ie same job each time it starts? (if yes: Can you use gnea/grbl ) (startup-blocks) to send your SD commands?
If I understand what you want, you want the computer to talk to the ESP32 then have ESP32 to talk to the device running GRBL. If you use a USB connection to the ESP32 (on most dev boards I've seen, anyway), the RX and TX pins are in use (hardware UART0). But the ESP32 has two other hardware serial ports. I vaguely recall that you should avoid UART1 on most dev boards because they use for something important (memory access?). But UART2 is available and will use TX2=GPIO17, RX2=GPIO16. So use your USB to talk to the ESP32 as you always do. Then a couple of lines of code allows you to create the Serial2 object in your program, set its baudrate to match the system running GRBL, and you should be able to keep two independent serial channels open simultaneously - one from the PC to control the ESP32, one from the ESP32 to control the GRBL device.
Great!! Will try that, I thought I couldn't use a 2nd UART while the USB connection was on. About Peter Van Der Walt post, I tried that also, and found out that using $N (and then more into it using $N1 and $N2) I can assign some "startup actions" using a gcode universal sender and they get stored into EEPROM. Sadly, I follow all the instructions and my $N0 and $N1 always appear empty (Info about $N= gnea/grbl) Has anyone used the $N commands and kept alive while trying? I can't seem to assign anything on them, I might need to activate something before trying to store info inside? Thanks a lot!!
Some of the things that work in official Grbl (github.com/gnea/grbl) hasnt been ported to ESP32 version yet. Never sure what works an what doesnt
I have the PRO Controller with the Raspberry Pi3. Things have worked well this last year, Started up a few days ago and no BCNC on Boot up. Any suggestions?
Hello and thanks for your excellent job and for your help. In my case I made during last months a big cnc for a friend. Everything seems to work but when I try to reduce some millimeters the working space (145x180cm) the never finish the program. I tried 2 times and same situation happens. Gbrl send all the gcode lines, but stops to ok them suddenly. Any idea about what to check? Thanks in advance for your support that allows to people like me to start and finish this kind of projects
GRBL has a $C - Check gcode command that says OK for every line of valid gcode, but does nothing. gnea/grbl It sounds like your job may be switching over to Check Mode in the middle of the run. I suggest 1) Try Check Mode for the whole job and see that the gcode is all valid. 2) If your sender to grbl can send only "one line at a time" (to allow you to step through the grbl codes) use that and see if you can find out where /when it first goes wrong. 3) grbl has a small input buffer to store commands. There is some way to query how big the buffer is and to report on the size / space remaining (but I forget how). But it is important that your sender knows how big this buffer is so that it never overflows the buffer, otherwise you will get strange things happening. If you change your gcode to make points closer together, etc. you will probably get more gcode, and have more risk of overflowing the grbl buffer if the sender does not obey the protocol. 4) grbl cannot handle long lines (where many commands are put on the same line) - certainly not longer than its input buffer. Look at your grbl code. What is the longest line you send to grbl? When you make the points closer together, maybe your tool that creates the grbl points creates lines that are too long. Good luck Peter
