AVR-Chat

Randy,

If your switch is a KILL/ESTOP switching function, if memory serves 
correctly, it must be a mechanical type according to most electrical 
codes...and conservative design practice.  We don't need to depend on 
any electronic component, with its indefinite or undefined life 
expectancy, to protect life or limb.

At the very least you might think about putting a NO, held or operated 
closed, contact in series with the contactor that powers the motor.  You 
can add another contact to your controller to indicate a fault and take 
the control logic to some predetermined state so you don't have to 
restart the whole process when your pinkie is out of the way.


REB



bytheriverkwai wrote:

>--- In AVR-Chat@yahoogroups.com, John Samperi <samperi@...> wrote:
>  
>
>>If INT1 routine or ANY OTHER interrupts routine is running
>>then nothing else can stop that routine UNLESS you reenable
>>interrupts within the INT1 routine which is VERY DANGEROUS
>>unless you handle it properly.
>>
>>You can get INT1 (and INT0) to simply set a flag and exit and
>>then you handle their service in the main loop, this way if another
>>int happens it can be serviced suspending the current service.
>>
>>STILL IT CAN GET VERY MESSY unless handled properly.
>>
>>By the way I hope you have RETIs in your interrupts routines.
>>
>>Regards
>>
>>John Samperi
>>
>>    
>>
>
>John
>Thanks for responding.
>
>How does the AVR do this internally - is the mcu is executing it's 
>own form of "CLI"? Or is it just turning off the Enable flags for 
>INT0 and INT1?
>
>In my case, what I'm doing is making a PCB drill, and a debounced 
>footswitch is attached to INT1. That kicks off a single drill cycle 
>that runs a slide up and down using a stepper. At the end of the INT1 
>ISR, I'm hitting the EIFR register to clear the INT1 flag. This 
>prevents a second cycle unless the first cycle has ended, in case I 
>accidently press the footswitch again in the middle of the cycle. 
>
>The INT0 switch is a KILL / Emergency switch, so it's response MUST 
>be immediate - in case I'm about to drill my finger, etc. A pc of 
>broken .025" carbide in my finger is not my idea of fun.
>
>I like your idea of jumping right back out of the ISR's, and having a 
>master routine handle all of the switches. I'll have to see if that 
>will work in my code.
>
>I can see how it could get messy, but in my case, when the KILL 
>switch is executed, I want it to jump to the INT0 ISR, and stay in 
>there in an endless loop until I reset the CPU. I have an error LED 
>that flashes in the INT0 ISR.
>
>Randy
>
>
>
> 
>Yahoo! Groups Links
>
>
>
>
>
>  
>


[Non-text portions of this message have been removed]