Home › Forums › TinyG › TinyG Support › Hacking the code: Wait for previous command to finish?
- This topic has 6 replies, 2 voices, and was last updated 12 years ago by JuKu.
-
AuthorPosts
-
December 17, 2012 at 8:15 am #3657JuKuMember
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?
December 17, 2012 at 3:16 pm #3659aldenMemberSimple. 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–AldenDecember 17, 2012 at 4:08 pm #3660JuKuMemberThe 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!
December 17, 2012 at 5:57 pm #3661aldenMemberIt might be good for us to integrate a vacuum controller in the code. I’m definitely interested.
December 18, 2012 at 2:34 am #3662JuKuMemberNo 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.
December 18, 2012 at 5:47 am #3663aldenMemberI 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.—AldenDecember 18, 2012 at 6:42 am #3664JuKuMemberThanks! I will keep you informed about my progress.
-
AuthorPosts
- You must be logged in to reply to this topic.