Hacking the code: Wait for previous command to finish?

Home Forums TinyG TinyG Support Hacking the code: Wait for previous command to finish?

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #3657
    JuKu
    Member

    I am planning to add some custom features to my device, that are not supported by G-codes. Having the parser to branch to my routine when it sees a custom (non G-code) command is easy enough. How would I know that the commands already sent are finished?

    #3659
    alden
    Member

    Simple. use cm_isbusy(). You can find an example in cycle_homing.c

    uint8_t cm_homing_callback(void)

    {

    if (cm.cycle_state != CYCLE_HOMING) { return (TG_NOOP);} // exit if not in a homing cycle

    if (cm_isbusy() == true) { return (TG_EAGAIN);}// sync to planner move ends

    return (hm.func(hm.axis));// execute the current homing move

    }

    Can I ask what you are trying to do? It might be something we should include. Also, I’d work from the edge branch if you are going to hack anything. Be aware that it will be updated a few times in the coming weeks
    –Alden
    #3660
    JuKu
    Member

    The goal is to greate a pick and place machine. First, I need to learn how the code works and what it can do as standard, but I know I will need at least:

    – after a set of commands, wait for the completion to turn the vacuum on and off

    – figure out component heights, probing: mobe to vertain direction until a switch gets activated

    And more, you’ll hear more about me later! šŸ˜† I’m just beginning, my TinyG hasn’t even arived yet!

    #3661
    alden
    Member

    It might be good for us to integrate a vacuum controller in the code. I’m definitely interested.

    #3662
    JuKu
    Member

    No different than spindle control, other than the need to know that movements are complete. I’m really more concerned about calibration and component height recognition, both which need a probing type function.

    #3663
    alden
    Member

    I haveĀ anticipatedĀ a probe function and left stubs in the code to support a probe function this would be based on Gcode G38.2, which is the Gcode probe command. Here is what I would do if I were doing this:

     

    — add a G38 command to the Gcode parser:

    case 38:

    switch (_point(value)) {

    case 2: SET_MODAL (MODAL_GROUP_G0, next_action, NEXT_ACTION_STRAIGHT_PROBE);

    default: status = TG_UNRECOGNIZED_COMMAND;

    }

    break;

    }

    ….Ā case NEXT_ACTION_STRAIGHT_PROBE: { status = cm_probe_cycle_start(); break;}
    Add a file called cycle_probe.c modeled after cycle_homing.c. The homing logic can then be adapted to run a probe cycle. You will also need to go into gpio.c to configure any switches you are using, and to add a CYCLE_PROBE behavior to the ISR helper. CYCLE_PROBE is defined in canonical_machine.h, and would need to be set in cycle_probe.c when you enter the cycle.
    Of course there’s a lot more to it than this, but hopefully this will get you started.
    —Alden
    #3664
    JuKu
    Member

    Thanks! I will keep you informed about my progress.

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