narrowing down more, I tentatively have the condition where the interpreter
should wait for a G38 to finish - I'm looking for a suggestion how to make it
actually wait
Interp::synch() isnt it - any suggestions?
-Michael
rs274_pre.cc near line 250:
logDebug("!!!KL Open file is:%s:", _setup.filename);
logDebug("MDImode = %d", MDImode);
while(MDImode && _setup.call_level) // we are still in a subroutine
{
status = read(0); // reads from current file and calls parse
logDebug("status = %d\n",status);
if (status != INTERP_OK)
{
return status;
}
int exec_status = execute();
/* the following condition is true if a G38 was issued and
* the next interpreter read should wait for it to finish
*/
if ((exec_status == INTERP_EXECUTE_FINISH) &&
(_setup.probe_flag == ON)) {
printf("execute(%s) returns INTERP_EXECUTE_FINISH , probe_flag
ON\n",
_setup.blocktext);
/* this doesnt work: Interp::synch();
*/
}
}
Am 10.05.2010 um 01:55 schrieb Michael Haberler:
> I've looked into this a bit more - it is definitely a race condition.
>
> The interpreter inner loop which reads and executes a o-word block fails to
> wait for a G38 to finish and immediately executes the next command which
> explains the erratic coordinate results observed thereafter (near
> emc/rs274ngc/rs274ngc_pre.cc line 241). It also behaves differently from
> normal main loop executing an .ngc file (no calls to
> emcTaskPlanSynch(),emcTaskPlanClearWait(),emcTaskPlanRead() etc).
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
