Re: [Emc-users] Spurious machine state changes, updates

2015-08-11 Thread Karlsson Wang
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


[Emc-users] Spurious machine state changes, updates

2015-08-11 Thread lloyd wilson
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