#429 mdi queue flushed on mdi error

[Sebastian Kuzminsky]

The buildbot occasionally reports failures of tests that use lots of MDI, specifically the tests/t0 suite.

These tests use linuxcncrsh to send MDI commands consisting of a combination of regular G-codes and user-defined M-codes. The M-codes are handled by shell scripts which append data to a log file, to introspect the interpreter. The checkresult script verifies this log file against the expected.

I've attached an example of a failure, with some extra debug logging from linuxcncrsh and Task. In this failure, the log file is missing several lines, starting with "sequence number 208".

Checkresult: http://paste.ubuntu.com/12037738/

result file (linuxcnc output while running test): http://paste.ubuntu.com/12037724/

Line 5382 of the result file shows linuxcncrsh sending the MDI command that's supposed to add "sequence number 208" to the log file but gets dropped instead. Task receives it but is busy running another MDI command, so the new incoming command goes on the mdi_execute_queue. Several more MDI commands come in and get queued. Then the currently executing MDI command finishes, and Task starts draining the MDI queue (line 5547).

The command before 'sequence number 208' in the mdi_execute_queue is invalid and causes an interpreter error (line 5574). This error is deliberate in this test, but the interaction with MDI queueing is not. The interpreter error causes emcTaskPlanExecute() to return 5 (INTERP_ERROR). This is handled by emcTaskIssueCommand(), which calls mdi_execute_abort() to clear the MDI queue, dropping everything that linuxcncrsh had queued up.

[Sebastian Kuzminsky]

It's probably correct to flush the MDI queue on error. Until such a time as we decide it's wrong, we'll keep doing it. For now, the test will use linuxcncrsh's "set wait done" command to cork the pipeline immediately after a possibly-failing MDI command.

Fixed in 2.6.9 and v2.7.0-pre6-353-g1af4ade.