I've been adapting the firmware to make it usefull for a CNC foam cutter I am going to build.
In doing so I found a deadlock situation that also exists in the original firmware:
the fragment below can (and did!) result in a deadlock when the G0 command finishes while the G90 command is being handled
G91
G00 X1.0
G90
Situation
The G00 step is running
The G90 command is received
This line locks the move_queue (process_string.pde)
// Lock move queue while adding new move
172 move_queue_lock_main = true;
The G0 step finishes
470 // If finished, start next move
471 if ( move_finished ) {
472
473 // Make sure queue not being modified by
474 // main routine and then advance
475 if (!move_queue_lock_main) advance_move_queue();
476
477 // If the queue is locked by the main routine, we can't hang about
478 // and wait for it as this would freeze up the whole system,
479 // so we just wait until the next time the interrupt routine
480 // is called and try again
481 }
The G90 command waits until the move is done (process_string.pde)
303 while (moving) {} // Do not try and do this while moving
Now the move_queue is locked, and moving is still true => deadlock
I fixed this situation by adding a 'move_queue_main_lock=false;' line before all 'while (moving) {}' lines
Jaap.
