Homing all (RepSnapper)
Posted by anode505
|
Homing all (RepSnapper) January 20, 2011 06:05PM |
Registered: 14 years ago Posts: 99 |
I just got toe the point of moving things around with RepSnapper.
Now when I home all, It does the X then Y then Z.
This can't be the norm can it?!?! I haven't tried any other of the host software, so not sure if its a RepSnapper issue or firmware.
Every CNC I have worked on (I currently fix CNC lasers for a living), retracts the tool first, so the other axis don't crash into the tool.
Now when I home all, It does the X then Y then Z.
This can't be the norm can it?!?! I haven't tried any other of the host software, so not sure if its a RepSnapper issue or firmware.
Every CNC I have worked on (I currently fix CNC lasers for a living), retracts the tool first, so the other axis don't crash into the tool.
|
Re: Homing all (RepSnapper) January 20, 2011 06:27PM |
Registered: 17 years ago Posts: 438 |
Actually, I was just looking at the code for that (in the 5D firmware) this morning. That is the norm for the "official 5D reprap firmware" when it receives a G28 code.
You can specify which axes to home, and they are test for (and homed) in X Y Z order. If you just say "G28" then it does all axes, one at a time, in X Y Z order.
I do not believe that this behavior is correct, but nor is it incorrect. The closest thing we have to a "spec" for g-code says it's a "G0" or non-syncronized move. You might assume that means all axes traversing at max speed, and just not stopping at the same time, but it could also be taken to mean one at a time.
I'm trying to write something better and more consistent (for triffid's fiveD_on_arduino firmware) but getting it right in all cases is more complicated than I thought it would be.
--
I'm building it with Baling Wire
You can specify which axes to home, and they are test for (and homed) in X Y Z order. If you just say "G28" then it does all axes, one at a time, in X Y Z order.
I do not believe that this behavior is correct, but nor is it incorrect. The closest thing we have to a "spec" for g-code says it's a "G0" or non-syncronized move. You might assume that means all axes traversing at max speed, and just not stopping at the same time, but it could also be taken to mean one at a time.
I'm trying to write something better and more consistent (for triffid's fiveD_on_arduino firmware) but getting it right in all cases is more complicated than I thought it would be.
--
I'm building it with Baling Wire
|
Re: Homing all (RepSnapper) January 22, 2011 09:15AM |
Registered: 14 years ago Posts: 99 |
|
Re: Homing all (RepSnapper) January 22, 2011 11:46AM |
Admin Registered: 16 years ago Posts: 1,470 |
You could just write a simple g-code to do it and save it under one of the custom buttons.
|
Help improve the RepRap wiki!
Just click "Edit" in the top-right corner of the page and start typing. Anyone can edit the wiki! |
|
Re: Homing all (RepSnapper) January 26, 2011 03:04PM |
Registered: 14 years ago Posts: 443 |
|
Re: Homing all (RepSnapper) January 26, 2011 04:06PM |
Admin Registered: 16 years ago Posts: 1,470 |
Yes, but normally when you want to home the axes there is nothing in the way, so the homing order does not matter. (Hopefully you removed your previous print before starting a new one?) With milling the order of homing becomes more important because you don't want your mill to crash into the material to be cut.
|
Help improve the RepRap wiki!
Just click "Edit" in the top-right corner of the page and start typing. Anyone can edit the wiki! |
Sorry, only registered users may post in this forum.