push button interrupt does it need a resistors

I hope I just need confirmation ...

I am putting in a switch to cause an interrupt. So initially the circuit seems straightforward (but wrong) ie gnd/vin through switch to pin.

I presume (as with leds) there needs to be a resistor in the circuit (to avoid the potential damage that is talked about with leds,

But then the question is what size resistor and is a pull-up or pull-down necessary to ensure a correct value?

My thinking is that a resistor is needed and I that a pullup/pulldown is necessary.

Connect the switch to ground and a digital input. Set the input: pinMode(Dx, INPUT_PULLUP); If you don't use the cap, you may need to debounce the switch in software.

My thinking is that a resistor is needed and I that a pullup/pulldown is necessary.

Correct! :blush: No! I mis-read what I just quoted.... The resistor is the pull-up (or pull-down).

You can use the internal pull-ups. See [u]this page[/u].

With no connection (and the internal pull-up disabled) the inputs are "floating", high impedance, and undefined. You need to "drive" the input up or down. Typically the pull-up is used to pull the input high when the switch is off, and when turned-in, the switch pulls-down the input and "overrides" the resistor. (With the switch on, current flows through the resistor, through the switch to ground.

Botolph:
I presume (as with leds) there needs to be a resistor in the circuit (to avoid the potential damage that is talked about with leds,

No. The input is not LED. So, just no.

LED is a diode.
LED = diode
Diode != resistor
Diode != inductor
Diode != capacitor
Diode != switch
Diode != camel
Diode != dog
Diode != motorcycle

Diode != capacitor

Not quite true, a reverse biased diode is a capacitor, and varactor diodes rely
on this effect!

I must do a course, or buy a book.

So in summary:

  1. if using the in-built pullup another resistor is not needed
  2. if not using the inbuilt pullup another resistor is required to force a pullup/pulldown

3 . you can't use a camel as a diode

You got it! :smiley:

Botolph:
3 . you can't use a camel as a diode

An african camel or a european camel?

The big question here is -

You said an interrupt. Why do you fantasise you need an interrupt to read a switch?

This is virtually never appropriate. There is only one possible reason for doing so, if you wish to use it to wake the processor from sleep.

Otherwise, it is a big problem - and a big trap for newbies. :wink:

Or perhaps, camels.

aarg:
An african camel or a european camel?

So presumably you're named after a well-known castle?

An african camel or a european camel?

That's hard to swallow.

B'dum, tsssh

Paul__B:
The big question here is -

You said an interrupt. Why do you fantasise you need an interrupt to read a switch?

This is virtually never appropriate. There is only one possible reason for doing so, if you wish to use it to wake the processor from sleep.

Otherwise, it is a big problem - and a big trap for newbies. :wink:

Or perhaps, camels.

I think the interrupt is the right approach because the project is controlling moving some milling machinery. I am putting in a safety barrier which if opened immediately closes off the cutters. Because it has some long linear processes (and they are coded as linear) it is simpler to use an interrupt either to close down the power to the cutters (my preference) or to set a flag to exit loops. I am not a fan of this as it would be difficult to test effectiveness in all scenarios.

NEWBIE TRAP: Is there anything other than an interrupt will take an elevated process that will effectively stop all other processes including clock interrupts and values that are being coincidentally updated by other processes will have erratic results. Neither of these will cause a problem in this situation. (I hope ! )

Ah dear! :astonished:

You have practically screamed at us that you have not the slightest idea of the purpose of an interrupt!

Yes, it is a "newbie" trap to be sure.

Someone who is not experienced with computing sees the word "interrupt" and thinks "Ah, I can use this to interrupt one process and make it do something different". This is simply not the case. The whole concept of an interrupt is that a critical operation which it is necessary to perform with a very small delay of an event occurring and which can be dealt with - not necessarily completely, but the necessary action can be initiated and allowed to proceed - very quickly, can be performed without significantly affecting or altering the operation of the main program stream in any way apart from a negligible delay.

{As an extension of this, multiprocessing operating systems may - using interrupts for "pre-emptive multi-tasking" - allow a number of program streams to proceed independently such that each program "sees" itself as the only one running, but cannot rely on how fast it will run.}

Having a program - "sketch" - alter its action in response to an event which "interrupts" its "train of thought" is on the other hand, entirely the responsibility of that program or process. There must be some point in that process where it makes a decision on which path to follow and if it is to be promptly responsive to an event such as an input from a switch, optical encoder, serial port or similar, then it must return to check for such an event frequently, which process is called "polling".

Only if the event which is to affect the program flow is so evanescent that it may have gone away by the time the main process loops through to poll it, will it be appropriate for the event to trigger an interrupt which does nothing else but set a marker variable - a "flag" which the main process can read in due course, and then clear the interrupt and return to the main process. A manually operated switch or encoder is almost never going to constitute such a situation.

Now in your case, two things are relevant. One is that your safety barrier switch must by definition simply cut off the power to the equipment. Not via the Arduino, because if the Arduino program "crashes" - as it just might - then the system will continue merrily on under no control at all.

That understood, what you have not taken into account, is when your proposed interrupt occurs and you shut down your mill, what the program does next? If you have indeed interrupted the process at a random point and taken certain actions, then you have lost the current status of the procedure, you cannot just exit the interrupt and imagine things are going to proceed as before. What did you intend to do?

No, it is all a matter of planning. Your "linear" code must proceed in defined steps (using "state machine" coding to work through the steps) where each step (and with a very fine resolution) is dependent on polling your safety switch, allowing it to shut down in an orderly fashion and re-start. The shut-down itself is an alternate process in the sequence of operations and handled as such in your "mainline" code.

You can not (certainly should not) "patch" improperly organised code by inserting random "exceptions" as interrupts.

Despite that, if the OP doesn't want to rewrite, an interrupt which turns off all devices and then just goes into a loop doing nothing, would be better than nothing at all. Then you would need to reset the processor to regain control.

However it is probably better do design safety in from the start. Your proposed idea sounds a bit like shutting down the engine of a car if it detects some failure situation.

A state machine, implemented properly, would mean the code is never stuck in some long "process". Then the main loop can check the state machine status (and change it if necessary) as well as do other useful things in the main loop like:

  • Check the safety switch
  • Update a display
  • Check for key presses (eg. operator presses "stop" button)
  • Check temperature, overspeed, etc.

As a warning, I should point out that if some code turns interrupts off (which it might do without you knowing) then your emergency switch will be inactive during that time. And if it turns interrupts off and then crashes or loops, then the emergency switch won't work at all.

Paul__B's suggestion of an independent emergency response circuit is probably the safest. Something that just trips the relays or does whatever is needed to avoid a hazardous situation. That can then be tested independently and you can confirm that it always works.

Yep - that's what I said! :smiley:

Although this project is a bit of fun to keep me out of the house, in case there is an opportunity to patent this and make a fortune (unlikely) I won't go into details. I struggle with the electronics not the engineering or the code.

The code for the primary Arduino is a two layer state machine. This drives another Arduino for motor controls and feedback and another Arduino and PC for image processing. And I am about to double up on the last one. to get images in two planes.

I talk about a switch and gate, although mechanically equivalent the elapsed operating time (circuit closed) for these is around 5 ms at about 15ms distance from the cutters. And just powering everything off - although safe - could result in significant damage to the machine.

The long linear processes are designed that way because they use a lot of processing power and I don't want to risk mistakes occurring because I am off checking states of things which have no relevance in that process.

To close down the cutters is a simple pin write. So nothing arduous there. After that the code will operate correctly.

I have no concern on the risk to life and limb at the machine. It operates in a locked steel and toughened glass enclosure with a UPS. The lock cannot operate unless the machine is powered down to a safety level.

Just as an aside I wrote my first time sharing operating system in 1976. For an old Varian Since then I have carried on doing a few bits including systems to operate manufacturing process and missile guidence. Not bad to know I am a newbie.

I hope explanation of the context helps.

Interesting :the earlier post on camels got me researching. I knew about bactrian and dromedary but didn't realise there are the poetically named F1 and F2 hybrids. I would guess the F1 is the fastest camel. Camels