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?
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
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.
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.
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.
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.
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.
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?
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.
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.
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.
