If I remember correctly I heard somewhere stop is not allowed to be a toggle
button.
Regards Nicklas Karlsson
On Tue, 11 Aug 2015 08:06:51 -0400
lloyd wilson llwilso...@rochester.rr.com wrote:
I think I've solved the state change conundrum I asked about last week -
While watching the debug messages (using 0x11c0 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 - H
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
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users