Welcome to Our Community

Some features disabled for guests. Register Today.

Ask Grbl CNC questions here.

Discussion in 'Control Software' started by Sonny Jeon, Aug 12, 2015.

  1. DarkPenguin

    DarkPenguin Well-Known
    Builder

    Joined:
    Sep 16, 2017
    Messages:
    201
    Likes Received:
    65
    That looks like the business. Thanks!
     
  2. snip3r

    snip3r New
    Builder

    Joined:
    Oct 8, 2020
    Messages:
    10
    Likes Received:
    0
    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?
     
    #1172 snip3r, Oct 8, 2020
    Last edited: Oct 9, 2020
  3. phil from seattle

    phil from seattle Journeyman
    Builder

    Joined:
    Mar 17, 2017
    Messages:
    312
    Likes Received:
    137
    What happens if you just issue
    G38.2 Z25 F10​

    I think that's actually what you want to do.
     
    Peter Van Der Walt likes this.
  4. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder Resident Builder

    Joined:
    Aug 6, 2013
    Messages:
    3,237
    Likes Received:
    1,815
    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 .
     
  5. phil from seattle

    phil from seattle Journeyman
    Builder

    Joined:
    Mar 17, 2017
    Messages:
    312
    Likes Received:
    137
    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.
     
  6. Peter Van Der Walt

    Peter Van Der Walt OpenBuilds Team
    Staff Member Moderator Builder Resident Builder

    Joined:
    Mar 1, 2017
    Messages:
    13,749
    Likes Received:
    4,070
    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
     
    #1176 Peter Van Der Walt, Oct 9, 2020
    Last edited: Oct 9, 2020
  7. snip3r

    snip3r New
    Builder

    Joined:
    Oct 8, 2020
    Messages:
    10
    Likes Received:
    0
    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.
     
  8. snip3r

    snip3r New
    Builder

    Joined:
    Oct 8, 2020
    Messages:
    10
    Likes Received:
    0
    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.
     
  9. Rob Taylor

    Rob Taylor Master
    Builder

    Joined:
    Dec 15, 2013
    Messages:
    1,470
    Likes Received:
    746
    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.
     
  10. snip3r

    snip3r New
    Builder

    Joined:
    Oct 8, 2020
    Messages:
    10
    Likes Received:
    0
    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.
     
  11. phil from seattle

    phil from seattle Journeyman
    Builder

    Joined:
    Mar 17, 2017
    Messages:
    312
    Likes Received:
    137
    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?
     
  12. Rob Taylor

    Rob Taylor Master
    Builder

    Joined:
    Dec 15, 2013
    Messages:
    1,470
    Likes Received:
    746
    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?
     
    #1182 Rob Taylor, Oct 9, 2020
    Last edited: Oct 9, 2020
  13. snip3r

    snip3r New
    Builder

    Joined:
    Oct 8, 2020
    Messages:
    10
    Likes Received:
    0
    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.
     
  14. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder Resident Builder

    Joined:
    Aug 6, 2013
    Messages:
    3,237
    Likes Received:
    1,815
    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.
     
  15. snip3r

    snip3r New
    Builder

    Joined:
    Oct 8, 2020
    Messages:
    10
    Likes Received:
    0
    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.
     
  16. phil from seattle

    phil from seattle Journeyman
    Builder

    Joined:
    Mar 17, 2017
    Messages:
    312
    Likes Received:
    137
    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.
     
  17. Rob Taylor

    Rob Taylor Master
    Builder

    Joined:
    Dec 15, 2013
    Messages:
    1,470
    Likes Received:
    746
    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?
     
  18. phil from seattle

    phil from seattle Journeyman
    Builder

    Joined:
    Mar 17, 2017
    Messages:
    312
    Likes Received:
    137
    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.
     
  19. snip3r

    snip3r New
    Builder

    Joined:
    Oct 8, 2020
    Messages:
    10
    Likes Received:
    0
    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.
     
  20. snip3r

    snip3r New
    Builder

    Joined:
    Oct 8, 2020
    Messages:
    10
    Likes Received:
    0
    Thanks guys for your time and effort, much appreciated!
     
  21. Peter Van Der Walt

    Peter Van Der Walt OpenBuilds Team
    Staff Member Moderator Builder Resident Builder

    Joined:
    Mar 1, 2017
    Messages:
    13,749
    Likes Received:
    4,070
    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
     
  22. snip3r

    snip3r New
    Builder

    Joined:
    Oct 8, 2020
    Messages:
    10
    Likes Received:
    0
    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.
     
  23. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder Resident Builder

    Joined:
    Aug 6, 2013
    Messages:
    3,237
    Likes Received:
    1,815
    you may want to look at GRBLHAL which can use a variety of 32bit hardware with spare timers.
    terjeio/grblHAL
     
  24. snip3r

    snip3r New
    Builder

    Joined:
    Oct 8, 2020
    Messages:
    10
    Likes Received:
    0
    Thanks David, I will. Phil has already brought it to my attention and it definitely looks promising.
     
  25. phil from seattle

    phil from seattle Journeyman
    Builder

    Joined:
    Mar 17, 2017
    Messages:
    312
    Likes Received:
    137
    Yes, grblHAL is designed to be much more easily configurable than Grbl Classic. The HAL abstracts out the machine dependencies from the Grbl core.
     
  26. Peter Van Der Walt

    Peter Van Der Walt OpenBuilds Team
    Staff Member Moderator Builder Resident Builder

    Joined:
    Mar 1, 2017
    Messages:
    13,749
    Likes Received:
    4,070
    (; take that up with them (; gnea/grbl
    as just saying, we didn't know :)
     
  27. bpm009

    bpm009 New
    Builder

    Joined:
    Oct 22, 2020
    Messages:
    1
    Likes Received:
    0
    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.
     
  28. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder Resident Builder

    Joined:
    Aug 6, 2013
    Messages:
    3,237
    Likes Received:
    1,815
    I believe you should increase the pulloff setting
    gnea/grbl
     
  29. Game_Changer

    Builder

    Joined:
    Dec 2, 2020
    Messages:
    1
    Likes Received:
    0
    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?
     
  30. phil from seattle

    phil from seattle Journeyman
    Builder

    Joined:
    Mar 17, 2017
    Messages:
    312
    Likes Received:
    137
    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.
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice