On 05/30/2016 11:37 AM, Sebastian Kuzminsky wrote: > Ok, i'll fix it. I have some ideas for places to look.
I tracked this problem down. On a sunny day when everything goes right, a running G-code program ends by executing M2 or M30, which ends up calling interp_convert.cc's convert_stop(). This function resets a bunch of Interp state (by setting fields in Interp's `setup` struct) and resets an bunch of Canon state (by calling into emccanon, placing commands on interp_list). So in this code path everything is taken care of. On a gloomy day, the user sends Abort in the middle of running a program. Task handles it by (among other things) sending Aborts to Motion and IO, and calling Interp's close() method. Task then calls Interp's on_abort() method, which does a good job of cleaning up Interp, but a poor job of cleaning up Canon. I fixed the bug by teaching Interp's on_abort() method to do the same cleanup as Interp's handing of M2/M30. This exposed some other bugs which i also fixed, related to Task initialization and the execution of RS274NGC_STARTUP_CODE from the ini file. The proposed fixes are in a branch named seb/2.6/task-abort-fix. It's more invasive than I'd like this late in the 2.6 and 2.7 stable branches, but it fixes a couple of real bugs that people have pointed out there, so i think we need something like it. I'd appreciate any feedback on the branch. -- Sebastian Kuzminsky ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
