Wait for command to finish?

Home › Forums › TinyG › TinyG Support › Wait for command to finish?

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • April 15, 2013 at 2:27 am #4004
    vonnieda
    Member

    Hi folks, I am implementing a TinyG driver for OpenPnP and I am wondering what the best way to wait for a command to finish would be? In OpenPnP we don’t really stream gcode, we run a gcode, wait for it to finish, do some work, repeat. With Grbl I would execute a G4P0 after each command and this would cause it to not return “ok” until the queue was empty. In TinyG this returns instantly (although, specifically using 0 seems to kill TinyG, more on that later).

    So, what do you think the best way to do this would be? So far it looks like my best bet might be monitoring status reports and waiting for stat=5.

    As for G4P0, running this command seems to leave TinyG thinking it’s in Run mode forever. It doesn’t seem to ever recover. I haven’t done extensive testing on this, but I’ve been seeing it happen.

    Thanks,

    Jason

     

    April 15, 2013 at 6:42 am #4005
    JuKu
    Member

    Set the status report time longer than your command would take. You’ll get a report right away when TinyG is done with the current command.

    April 15, 2013 at 3:49 pm #4006
    alden
    Member

    JuKu is right. A status report is sent when movement ceases and automatically at the set interval.

    Thanks for noting the P0 bug. I’ll have to track that down and fix it. Honestly I never thought to test that, but it should be made to be non-destructive.

    April 16, 2013 at 2:38 am #4010
    vonnieda
    Member

    Thanks JuKu and alden, that should work okay. I need to parse the status reports anyway so I can provide feedback during a move.

    Next question: What do you recommend for an emergency stop situation? What I’d like to do is be able to issue a command and have all outputs turned off immediately. I hacked this into Grbl previously with $1000=1, $1000=0.

    Also, one comment on the status reports: If I issue a movement command that results in no movement, no status report is issued. For example, running G0X0 and then G0X0 again the second one will not result in any status reports since no movement actually happens. I personally think that for consistency’s sake, it should at least emit the final report. Just throwing that out there.

    Thanks,

    Jason

     

    April 16, 2013 at 6:46 am #4011
    alden
    Member

    To stop the machine instantantly w/o losing position issue a feedhold. Send a ‘!’ char to the board. Issuing a cycle_start ‘~’ will resume that move, or issue a queue flush $qf to flush the buffer so you can start a new move.

    Good suggestion on the status report.

    April 18, 2013 at 12:10 am #4020
    vonnieda
    Member

    Thanks Alden, but what I am looking for is an emergency stop – not a controlled stop. I’d like to be able to power everything down and turn off all outputs. This primarily comes from my experience with milling machines, but I feel like it applies to any computer controlled machine. There should be a way to say “Stop everything right now”. This would typically map to the big red button you see in so many machine shops.

    It’s not critical, but maybe something to mull over.

    April 18, 2013 at 7:45 pm #4025
    Riley
    Keymaster

    I would say this lies outside of “firmware” or “hardware” I set this up now with a red button that kills power to my tinyg.  This way its out side of TinyG and will kill everything without question.

     

    Riley

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