Home › Forums › TinyG › TinyG Support › How to locate workpiece
- This topic has 7 replies, 3 voices, and was last updated 6 years, 5 months ago by
larrycook99.
-
AuthorPosts
-
March 25, 2018 at 11:25 am #10934
larrycook99
MemberWe have built a small 4-axis machine with TinyG with an endmill and I have devised a method for locating the tool with the endmill that I wanted to see if I had done anything incorrectly or could do better.
I know when the end mill makes contact with the work piece because we can detect continuity when that happens.
With the TinyG I move the endmill close to the work piece and then move the tool incrementally closer to the workpiece until I detect continuity. The way I move the tool towards the work piece is:
Put TG into increment move mode
do until continuity found
Move tool 0.001 towards the tool. (0.001 is 1 motor step)
Wait for TG to stop
Measure for continuity
if no continuity repeat
if continuity then ask TG its position, the z position is where the work piece is.Programmatically I do the following:
Send “g91” to TG
Move to start position
Test for continuity, if touching error because we should not be touching at this point.
do
{
send g1z0.001f200 to TG
wait for response from TG
do
{
send {mots:null} to TG
wait for response from TG
if response is not 1 (TG running), break
}
if (continuity found) break;
}send {pos:null} to TG to get position
z position is where the work piece is in z.Is there anything wrong with this process? Is there a better/preferred way to do this?
It seems to work but I just wanted confirmation from someone who knew the TG better than I do that I wasn’t doing something wrong that was going to bite me.
-
This topic was modified 6 years, 6 months ago by
larrycook99.
March 25, 2018 at 11:33 am #10936Zootalaws
MemberWhy don’t you just use the grbl g38.2 probe command?
That’s exactly what it’s there for.
-
This reply was modified 6 years, 6 months ago by
Zootalaws.
March 25, 2018 at 11:43 am #10938larrycook99
MemberI am controlling the TinyG with an Arduino using C/C++ via serial, and the TG according to the documentation doesn’t support the G38.2 command.
March 25, 2018 at 12:01 pm #10939larrycook99
MemberI just realized that my single step distance is wrong. It should say 0.01 mm not 0.001.
March 25, 2018 at 7:35 pm #10940cmcgrath5035
ModeratorG38.2 does work.
Look here: https://github.com/synthetos/TinyG/wiki/ChiliPeppr-PCB-Auto-Level#chilipeppr-auto-level-a-pcb-with-tinygI didn’t realize that https://github.com/synthetos/TinyG/wiki/Gcode-Support had not been updated
March 26, 2018 at 4:08 pm #10941larrycook99
MemberThat is good to know.
However, our system currently isn’t set up to do this and I would like to know if there is anything wrong with the method we are currently using?
Also, is {mots:null} the best way to determine that motion has stopped? I use that in other cases as well. For instance we have a brake on our A-axis and I want to be certain that motion has stopped before applying the brake after a rotation.
March 26, 2018 at 9:57 pm #10942cmcgrath5035
ModeratorHowever, our system currently isn’t set up to do this and I would like to know if there is anything wrong with the method we are currently using?
I believe that G38.2 would move more quickly, but that is a guess and speed may not matter that much.
Reading your outline a pseudo code, you are doing the same job – if it works for you and you like it,it works.Also, is {mots:null} the best way to determine that motion has stopped? I use that in other cases as well. For instance we have a brake on our A-axis and I want to be certain that motion has stopped before applying the brake after a rotation.
I think so, but a bit hard to say for sure without understanding your overall motion programming strategy in detail.
What you really want, I suspect, is to know that the machine is not currently moving and no motion is planned in the near future (i.e. until I tell you to move some more.)
Perhaps that translates to “(not moving) AND (command buffers empty)”?
Perhaps your coding strategy makes that implicit.March 27, 2018 at 7:34 am #10943larrycook99
MemberThanks for that. That tells me that I seem to understand how things are working.
You are correct about the planning buffers. I am monitoring them as part of the communications logic and failed to mention that in my initial post.
Originally I was using {stat:null} to determine whether the tool was in motion and then found {mots:null} and thought it might be better. Not sure there is a significant difference, if any.
-
This topic was modified 6 years, 6 months ago by
-
AuthorPosts
- You must be logged in to reply to this topic.