When we were trying to debug the problem with our added reload pin, we saw that root_window.update() call and it’s associated comment and wondered what the consequences of simply removing it were. Sounds like there could be bad consequences if we just remove it - ie, a user unintentionally hits RUN while the file is loading comes to mind.
Note we made local modifications [adding the reload pin] because we had to, or thought we had to, not because we wanted to. I would much rather use a stock Axis than a custom one. Updates are a PIA which is the reason we were at 2.5.8! Updating Axis every time (or even sometimes) Linuxcnc updates Axis out from under you is no fun. We were quite happy to discover "axis-remote —reload“ today! If you (or someone) can help me understand how to use git bisect I may be able to attempt running it on various versions to see where it stops working. However, 2.7.3 also brings a change to the OS, so really I should have said our reload pin worked on Ubuntu/2.5.8 but not on Debian/2.7.3 That kind of testing could be much more work. Also, given that when testing (using axis-remote) it NEVER gives us the error executing this: o<touch_xy> sub G10 L20 P1 X0Y0 M140 o<touch_xy> endsub And ALWAYS gives us the error executing this: o<touch_xy> sub G10 L20 P1 X0 M140 o<touch_xy> endsub It seems like it very well could be a timing issue and if so due to the different OS and/or RTAI? Thanks for the info Jeff, -Tom > On Jan 4, 2016, at 11:13 PM, Jeff Epler <[email protected]> wrote: > > Yuck. I am sorry that this got worse between 2.5 and 2.7, but it is > likely that there is no simple fix. > > I think the root of the problem you're having is that: > * AXIS has to change modes to AUTO to actually (re)load a part > program > * but at the time you make the reload request, you are in MDI mode and > an MDI command is executing > * so AXIS can't change to MDI mode right away (this is why it becomes > unresponsive for a bit) > * after this, the event-driven nature of GUI programming means that > some function gets called when it shouldn't, resulting in the actual > error message displayed. > > The comment block above the root_window.update() states why it is there: > to ensure that key presses that occurred while the program was loading > are discarded, rather than processed. It has also been there for a long > time, well before 2.5.x. (in fact all the way back to before AXIS was > integrated with the program once known as EMC, if my spelunking in the > project history is accurate!) > > Unfortunately, the update also handles other events, such as the > periodic checking of HAL pin changes or the reception of requests sent > by axis-remote. These are inapproriate events to handle. But there's > not sufficient control over *what kind of events* update() will handle. > :( > > Without further analysis, I am loathe to simply remove that line. But > if you are making local modifications to linuxcnc anyway, then go ahead > and do whatever you need to do to make your system work like you need. > > If you do have additional analysis (such as what specific commit broke > it, which may be findable using git bisect since you have a good > procedure to reproduce the problem) or an alternative solution, please > let us know what you are able to learn. > > Jeff > > ------------------------------------------------------------------------------ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
