Hey folks, I've been scratching my head for a couple of hours over a probing problem. I'd appreciate any input. I have grbl 1.1f running on a custom board designed around an arduino nano and DRV8825 stepper drivers. The axes have been set up alright, homing (inductive proximity sensors) works well, movements (G1) are fine. However, when I'm executing G38.2 X0 Y0 Z25 F100 the Z axis moves only 0.324 mm in the right direction, then stops abruptly and grbl issues alarm 5. This is somewhat baffling, as alarm 5 should only be raised when the commanded position has been reached without triggering the probe input. If I reset the machine, home the axes and execute G1 X0 Y0 Z25 F100 instead of the straight probe command above, the axis moves to Z=25 without any errors. Needless to say, the commanded position is well within the work envelope. There's a reflective optical sensor wired to the probe pin. I've added a custom command that does nothing when the sensor is triggered and errors out when it's not, so I was able to verify that probe_get_state() returns the correct value - not that the machine controller gave it any chance as a movement as small as 0.324 mm is nowhere near enough to trigger the sensor. When I cover the sensor even before issuing the G38.2 command, I receive alarm 4 as expected. What am I missing?
Z25 is a movement UP away from the work. is that what you intend? probing will usually be down toward the work (negative), and should also be a relative move (G91) G91 G38.2 Z-25 F10 However this may also give you a softlimit error as I doubt your Z has 25 inches of travel (-: (I assume inches from your F10, GRBL cannot feed properly below about 50mm/min depending on hardware) Note that any macros you write must always set the units and relative/absolute mode otherwise you can get some unexpected movements because the previous Gcode file left the modes in an unknown state. so a full probe macro might be G21 G91 G17 ; set modes G38.2 Z-5 F60 ; probe down G10 L20 P1 Z9.63 ; set offset G91 G1 Z5 F200 ; move up 5mm G90 That is actually my probe macro that I use in bCNC. 9.63mm is the height of my opto probe sensor .
Not necessarily. He could be in absolute mode and his starting Z could be above 25. By the way the new sender, ioSender, has a fantastic probing section. Worth switch to it for that alone.
As does OpenBuildsCONTROL (; @snip3r give it a try, if it works with the wizard (known good code) you know at least that your hardware is fine. CONTROL also has a Troubleshooting tab where you can test your probe wiring
Hi, specifying the X and Y coords is indeed a bit superfluous, but there should be and there is no difference at all between the results: ?<Idle|WPos:0.000,0.000,0.000|FS:0,0> G38.2 Z25 F100 ALARM:5 [PRB:0.000,0.000,0.000:0] ok ?<Alarm|WPos:0.000,0.000,0.324|FS:0,0> If I reduce the feedrate, the axis moves a bit less.
Thanks for your input. The machine works in metric units, and indeed at 10 mm/min the movement is a bit choppy, but G1 has no trouble moving the axis to the desired position at the same feedrate (while of course the motion being somewhat "granular"). FWIW my go-to feedrate was 100 mm/min but changing the feedrate makes barely any difference (at slower feedrates, the axis moves a bit less, at higher ones it moves a bit more and it does so consistently). The kinematics of the machine are a bit awkward, but the end result is the same; G38.2 still fails to move the axis in a meaningful way, and I always get alarm 5 no matter which direction the axis is supposed to move, as I can cover the reflective sensor at will, at any time, but the axis won't move more than 0.5 mm in either direction. I tried to find out if 0.5 mm of movement would be enough to trigger the sensor but it proved impossible so far to position the workpiece (a piece of styrofoam with somewhat jagged edges) in a way that it doesn't trip the sensor before G38.2 is executed (hence risking getting alarm 4), but close enough to the sensor that 0.5 mm of movement would be enough for it to be detected. Unfortunately relative mode makes no difference wrt the outcome.
So to confirm, entering: G91 G38.2 Z-25 F60 G90 verbatim does NOT produce a meaningful result? Struggling to see what it possibly couldn't like here.
Hi there, the result is: ?<Idle|WPos:0.000,0.000,0.000|FS:0,0> G91 G38.2 Z-25 F60 ALARM:5 [PRB:0.000,0.000,0.000:0] ok ?<Alarm|WPos:0.000,0.000,-0.235|FS:0,0> As you can see, it moved a tiny bit to the desired direction, then stopped abruptly and claims that it has reached the commanded position w/o contact (alarm 5). Please note that ?<Idle|WPos:0.000,0.000,0.000|FS:0,0> G91 G1 Z-25 F60 ok ?<Idle|WPos:0.000,0.000,-24.981|FS:0,0> G1, again, moves the axis to the commanded position.
hmmm, if it alarms immediately that means grbl is seeing the probe signal. Is the probe set up NO or NC? And what is $6 set to? Is there an EMI issue?
That was my first thought, but if it sees a probe trigger through EMI, it should error 4, not 5? Edit: actually no, it should just successfully complete at random locations, not exactly 0.235mm every time. Edit edit: actually, if one is 0.324mm and one is 0.235mm, maybe it IS an EMI issue. 0.1uF cap on the probe input at the controller end of the cable?
If I cover the sensor before issuing G38.2, grbl bails out with alarm 4 (as expected). Alarm 5 should only be raised when the movement to the specified coordinates has completed without triggering the probe input.
you said it is a reflective opto sensor, does this mean it is mounted like a tool and is moving toward the workpiece? I would like to see a photo (-: that seams like a neat idea the only thing I can think of now is your messing about in the code (-: go back to a fresh codebase from github and use the troubleshooting tab in CONTROL to check operation rather than changing the GRBL code.
This is a production machine running a custom firmware I wrote years ago. The client requested more sophisticated CNC control so I decided to use grbl as a drop-in replacement. The output transitions of the reflective optical sensor are pretty crisp, there's a 10n cap involved IIRC, and it's about 40 mm away from the probe pin on the very same PCB. Please note that alarm 5 means that the probe has never been triggered during the movement performed by G38.2 and I've verified that probe_get_state() returns the correct value when the sensor is covered. As I said, the actual movement (couple of tenths of a mm) depends on the feedrate, F100 results in 0.324 mm, F60 in 0.235 etc.
OK, David raises a good question on stock vs modified code. If the probe has not triggered and the specified point was not reached then the only conclusion is that grbl is malfunctioning. This seems highly unlikely given the "billions served" nature of the distributed code. On the sensor, not only a photo but perhaps a more in depth description. what kind of sensor? [edit] I see we were both posting at the same time.
Yeah I second-second guessed myself because I was on the phone and apparently couldn't multitask. It should definitely complete successfully but incorrectly if it were EMI. This seems like the thing to do, because of this: I can't think of any way around functioning code, or even malfunctioning hardware, that produces this result- where the probe subroutine thinks the stepgen has fired significantly more than it has whilst still reporting correct coordinates to the sender. The only logical conclusion is the issue being in the firmware itself. Has probing ever been an issue in the past on this same machine and control, or is this the first time it's been attempted since modifying the control?
Lots of probing problems out there. However, the vast majority of probing problems that I see are user error - usually a misunderstanding of how it works. It is, indeed, a complex thing to understand. Especially when you get to corner finding or height mapping. This doesn't seem to be the case here, though. Following with great interest.
I've already reduced my changeset to cpu_map.h and config.h before I started debugging. The Z axis consists of a pair of feed rollers that move the workpiece left and right. The sensor is mounted between the rollers so it can pick up the edge of the workpiece as it passes in front of the aperture of the sensor. The X and Y axes are compact linear actuators mounted perpendicularly to the Z axis but parallel to each other. This way the hot wire between the plungers of the X and Y axes can make straight and slant cuts (among others) while the workpiece is being fed through the machine by the rollers. The actual problem was that - even though the timer parameters for spindle PWM control can be modified in cpu_map.h and I took advantage of that as I might need variable power for the hot wire later on - the other two timers on the 328p (the default target for grbl) are both in use and their parameters are hardcoded (ugh...). No wonder that interfering with one of these timers caused this kind of issue. I'm somewhat baffled that in spite of this collision, G1 commands were executing successfully on all axes, but I can't be bothered to spend more time on this, I'm just gonna roll out another revision of the PCB where I'll use a different pin for the spindle PWM signal, connected to one of the Timer2 OC pins. I've seen some people praising grbl's documentation; as a person who has chewed through thousands of pages of s/w and h/w docs over the last 20 years I can tell it's rather mediocre. Configuration parameters should be fair game and/or their cross-dependencies should be noted properly.
Next time just let us know right up ahead that you made major changes (even if they seem to be unlikely or insignificant) please it just helps to think of potential issues
That's my point, exactly. Changes made to the configuration are supposed to be trivial - unless the software is poorly structured or the documentation is poor. Examples of major changes are removing coolant control and control input handling, altering core logic etc. Making changes to user-modifiable config parameters shouldn't result in interference with hardcoded values, or at least the limitation should be noted accordingly, as they are indeed wrt. other configuration tokens like step pulse, direction, limit and control pins.
you may want to look at GRBLHAL which can use a variety of 32bit hardware with spare timers. terjeio/grblHAL
Yes, grblHAL is designed to be much more easily configurable than Grbl Classic. The HAL abstracts out the machine dependencies from the Grbl core.
I'm setting up a single axis machine and I'm trying to setup homing. From what I've found on the internet, in the config file I'm supposed to comment out everything but defining the Homing_Cycle_0 for the X-axis. I have done that as shown. When I'm going through the setup function and setting up homing, the x-axis homes correctly but I immediately get an Alarm homing failed afterward. Am I missing something else? // 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<<Z_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 // NOTE: The following are two examples to setup homing for 2-axis machines. // #define HOMING_CYCLE_0 ((1<<X_AXIS)|(1<<Y_AXIS)) // NOT COMPATIBLE WITH COREXY: Homes both X-Y in one cycle. #define HOMING_CYCLE_0 (1<<X_AXIS) // COREXY COMPATIBLE: First home X // #define HOMING_CYCLE_1 (1<<Y_AXIS) // COREXY COMPATIBLE: Then home Y [Error] 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.
Hello everyone, I am working on cnc machine project. I have a question. I am using the grbl library. In addition, I have added it in the encoder and I can compare the position information from the encoder with the position information from the stepper motor. However, if the motor has not reached the desired position, I want to move it in code myself. I know how to move from serial terminal. How do I write the move code in source code? Since I am using Arduino, I could not fully understand the operation of the code because I could not debug the code. Can you please help?
grbl/gnea is pretty tightly written to take advantage of the ATMega. You might want to look at grblHAL which has factored out the processor specific stuff from the core motion control code. Very active development going on these days.
