Am 03.03.2013 um 13:45 schrieb andy pugh: > On 3 March 2013 07:39, Michael Haberler <[email protected]> wrote: > >> I have looked into the issue in the past, more with an eye towards fast >> estop, and the gist was: if it is too work fast, the shutdown sequence must >> be aware of the hardware it is using; for instance, the fastest, >> lowest-impact method to shutdown a Mesa card was to remove the watchdog >> function from the thread which got the time windows down to a watchdog >> period. So shutdown is fast or portable, tick either one. It is not an issue >> which can be solved en passant with a quick fix; it needs a bit of a plan >> and some systematic work which doesnt immediately yield results. > > This is considering the process that happens when LinuxCNC is exited > with a machine powered-up and running? I can see this is a type of > e-stop, but not the normal sort.
Right > Is it possible to refuse to quit until at least one servo cycle has > run with the LinuxCNC enable outputs disabled? the current sequence is in scripts/linuxcnc function Cleanup: it sends signals to all user processes (UI, task etc) ; first SIGTERM, later SIGKILL if a process wont exit then it stops the realtime threads via halcmd stop then it proceeds to unload hal_lib, rtapi and modules and cleans up If anything happens before threads are stopped really depends on what user processes are doing and if/how they react to a signal what I was referring to: if you react to the shutdown signal (or a segfault for that matter) in one of the user processes, that potentially reduces the time window until threads are stopped, and there is some choice what still can be done - provided safe signal programming techniques are used I'd need to look if any components actually react in HAL due to a signal directly; cant remember having seen it -m ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
