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?
Hacking the code: Wait for previous command to finish?
From the original Synthetos forum (2011–2025)
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
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! :lol: I'm just beginning, my TinyG hasn't even arived yet!
It might be good for us to integrate a vacuum controller in the code. I'm definitely interested.
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.
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
Thanks! I will keep you informed about my progress.
This topic is from the original forum (December 2012). Your reply starts a new discussion linked to it.
Back to TinyG Support or latest activity.