I think I've solved the state change conundrum I asked about last week - While watching the debug messages (using 0x000011c0 debug setting), a deactivation event occurred, causing a 'emcTaskPlanClose' event, but nothing that indicated the precipitant event. I backed the machine to a previous program point and restarted - bad move; I had picked the wrong restart point and had to e-stop the machine. However, the e-stop generated the same plan close event report - Hmmmm
As I originally reported, there is no HAL pin associated with the machine's active/inactive state - but there is for e-stop (e-stop chain activates a relay, one pole of which goes to emc-enable-in). The relay is a recycled dry contact unit, so there is a potential for noisy connections. After adding a debounce function to the e-stop signal, no further instances of the state change phenomenon have been observed, so it looks like that demon has been exorcised. However, this does raise a question about LCNC's e-stop behavior: at initial startup, we have to manually exit e-stop state via the user panel, but thereafter e-stop state tracks the HAL pin, so a noise spike on e-stop can bump the machine to inactive state and leave no trace (unless there is a debug setting I missed). At the least, such asymmetrical behavior can lead to confusion (see current writer). Given that e-stop is a cataclysmic event, I would think it more appropriate for an e-stop event to latch the machine's state and require a manual reset, as at system startup. Is there a specific rationale for the way e-stop is currently handled? Thanks to all who offered suggestions -ldw ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
