Welcome to Our Community

Unlock hidden features. Sign Up for Free Today!

Multiple positions

Discussion in 'CNC Mills/Routers' started by Dale Y, Nov 13, 2016.

  1. Dale Y

    Dale Y Well-Known
    Builder

    Joined:
    Jun 20, 2016
    Messages:
    12
    Likes Received:
    1
    Here is a more generic question, more about the controllers. I have learned how to set up multiple (I have 5) 0,0 positions in G-code, but have seen a couple mistakes by the machine. There has been a couple times where the machine goes to the wrong 0,0 location, so far always the previous 0,0 then the one called. Any ideas?
     
  2. Joe Santarsiero

    Joe Santarsiero OB addict
    Staff Member Moderator Builder

    Joined:
    Oct 30, 2014
    Messages:
    647
    Likes Received:
    134
    I've had this happen once before. Never figured it out. Is this repeatable for you?
     
  3. Dale Y

    Dale Y Well-Known
    Builder

    Joined:
    Jun 20, 2016
    Messages:
    12
    Likes Received:
    1
    not repeatable when I want. Just happened a couple times, both times when I was trying to lay out a grid on my table for those positions. Trying to figure out why before I get a big project and mess it all up
     
  4. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2013
    Messages:
    521
    Likes Received:
    250
    My first reaction is that you made a mistake on the setup (-: say, G56 and G57 in the same place.
    But it could also be a controller glitch, or a Gcode problem, ie 2 pats with the same co-ordinates selected.

    So how to check that you got the set up correct?
    I would write a little Gcode like this
    %
    G90 G17
    G53 G0 z0 ; hopefully a safe height, depends on correct machine home
    ; check G54
    G54 ; select G54
    G0 x0 y0 ; go to 0,0
    z0 ; drop down to z0
    G4 P3 ; pause for 3 seconds
    G0 Z50 ; raise up
    ; check G55
    G55 ; do the next one
    G0 x0 y0
    z0
    G4 P3
    G0 Z50
    ; check G56
    G56
    G0 x0 y0
    z0
    G4 P3
    G0 Z50
    ; check G57
    G57
    G0 x0 y0
    z0
    G4 P3
    G0 Z50
    ; check G58
    G58
    G0 x0 y0
    z0
    G4 P3
    G0 Z50
    ; go to machine home
    G53 G0 x0 y0
    M30
    %

    what that does it go to each 0,0,0 position in turn and pause for 3 seconds so you can see that each is correct.

    so, having checked that the G54-G58 are indeed correct, you can run code. If it then goes wrong, there is either a problem in the controller, or a problem in the code itself.
     
  5. Joe Santarsiero

    Joe Santarsiero OB addict
    Staff Member Moderator Builder

    Joined:
    Oct 30, 2014
    Messages:
    647
    Likes Received:
    134
    Dave, is there any possibility an error like this is related to buffering and/or look ahead? I don't know much about coding or the way these things work on the back end.
     
  6. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2013
    Messages:
    521
    Likes Received:
    250
    yes, but I don't think so, it is much easier to make a mess with the setup than to have such a long running bug hanging around (-:

    on the back end codes like G54 have to do certain things like make sure the buffer clears, make sure motion stops and so on, if one of those things goes wrong it should be obvious in a trivial test.

    However, not many GRBL users will be using multiple setups so it is not getting exersized a lot in that area, so maybe there is a bug. An intermitant bug is the worst to track down though. But then again, intermitant points at a communication type problem. We already know that the CH430 USB chip used on clone Arduinos is very bad at doing long files, so, hopefully you are not using one of those. Even the Atmega16u2 on genuine Arduino UNO's needs to be reflashed to avoid problems with long jobs.

    Maybe Dale should post a query about this on the GRBL forum? Especially if he can replicate it.
     
  7. Dale Y

    Dale Y Well-Known
    Builder

    Joined:
    Jun 20, 2016
    Messages:
    12
    Likes Received:
    1
    Actually, I am using a laser engraver, both times it has happened is on my machine and a smaller one of my brother's. On his we setup a program to lay out a pattern of stops positions. First it ran the pattern for position 4 in position 3, then when we reran the program, it ran position 5 in position 4. My machine did the same thing. So to me, it seems like it skips the command to switch to the new zero location. the only difference in my command lines is that we write it up like "G56 G0 x0 y0" all on one line rathe then 2 line.
     
  8. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2013
    Messages:
    521
    Likes Received:
    250
    Please try it with the g56 on a line by itself.

    The reason for this is that g53 plus a commond on one line has special meaning.
    Maybe you are confusing the software by putting it all on one line.
     
  9. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2013
    Messages:
    521
    Likes Received:
    250
    I have been running the code I wrote a few posts ago and cannot see any problems, the offsets switch as expected.

    However, I do notice that the offsets appear to switch too early.
    roughly....
    G55
    G0 z0
    G4 P3
    G0 Z50
    G56
    ...

    I see that the G56 offsets come into effect during the G0 Z50 move! Surely that cannot be right?
    Using GRBL-Panel 1.0.9.7 and GRBL 1.1
    @Sonny Jeon and @GerritV - could it be just GRBL-panel updating the display before the motion is finished?
     
  10. Sonny Jeon

    Sonny Jeon Veteran
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2015
    Messages:
    110
    Likes Received:
    37
    There is a long known issue with work position offsets in v0.9 and prior. What's shown as work position is based on the g-code parser state, rather than what is actually executing at the time. So, Grbl most likely parsed G0 Z50, placed it into the planner, then parsed G56. At that point, the work coordinate offset would have changed and be shown incorrectly until queued motions before the G56 are executed. In other words, it'll very briefly show the wrong work position, but still execute everything correctly.

    In most cases, work coordinate offsets aren't changed that much and it hasn't posed a problem. Actually, you are the first person to ask about this since v0.7, when this problem first appeared.

    To verify, you can just add a very short G4 delay line between G0Z50 and G56 to force Grbl to empty the planner. It should show everything correctly.

    That said, I did fix this in the new v1.1 protocol updates. I've enforced planner syncs whenever there is a work coordinate offset change. So, work position and what is executing doesn't get out of sync anymore.
     
  11. Dale Y

    Dale Y Well-Known
    Builder

    Joined:
    Jun 20, 2016
    Messages:
    12
    Likes Received:
    1
    My issue was not that it would switch early, it was that it would not switch and then run over the top on the previous position. I switched my commands to put the g54, g55, etc. on their own line, then execute a g0 x0 y0 on the next line. So far I have not seen a repeat. My only guess at this point is as was suggested is that when on the same line with another command, it misses the switch to the next position. My system only did it once, but on my brother's the problem repeated, but just on a different spot. Live and learn.
     
    Giarc likes this.
  12. Sonny Jeon

    Sonny Jeon Veteran
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2015
    Messages:
    110
    Likes Received:
    37
    There is a potential issue with EEPROM accesses in sequence like this. I've written about this in the interface document. The problem is the AVR processor shuts down interrupts during an EEPROM read or write. Or about a handful of cycles per byte accessed. It can lead to missing a serial transmission. For the most part, it occurs mostly on an EEPROM write but can still happen on a read. In this case, reading the work coordinate data from EEPROM when you change them.

    This would be the first time I've heard about this or at least someone posting and reading about it. This is likely because most people don't use multiple work coordinates.

    I think if you use a short G4 dwell before a work cord change, this intermittent issue will go away.
     

Share This Page

  • About Us

    The OpenBuilds Team is dedicated helping you to Dream it - Build it - Share it! Collaborate on our forums and be sure to visit the Part Store for all your Building needs!
  • Like us on Facebook

  • Support Open Source FairShare Program!

    OpenBuilds FairShare Give Back Program provide resources to Open Source projects, developers and schools around the world. Invest in your future by helping others develop theirs!

    Donate to FairShare!