We 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.
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.
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?
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.
Thanks 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 is from the original forum (March 2018). Your reply starts a new discussion linked to it.