How to locate workpiece

Home › Forums › TinyG › TinyG Support › How to locate workpiece

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • March 25, 2018 at 11:25 am #10934
    larrycook99
    Member

    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.

    • This topic was modified 6 years, 7 months ago by larrycook99.
    March 25, 2018 at 11:33 am #10936
    Zootalaws
    Member

    Why 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, 7 months ago by Zootalaws.
    March 25, 2018 at 11:43 am #10938
    larrycook99
    Member

    I 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 #10939
    larrycook99
    Member

    I 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 #10940
    cmcgrath5035
    Moderator

    G38.2 does work.
    Look here: https://github.com/synthetos/TinyG/wiki/ChiliPeppr-PCB-Auto-Level#chilipeppr-auto-level-a-pcb-with-tinyg

    I didn’t realize that https://github.com/synthetos/TinyG/wiki/Gcode-Support had not been updated

    March 26, 2018 at 4:08 pm #10941
    larrycook99
    Member

    That 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 #10942
    cmcgrath5035
    Moderator

    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.

    March 27, 2018 at 7:34 am #10943
    larrycook99
    Member

    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.

  • Author
    Posts
Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.