I'm designing an arduino board to read inputs from HVAC devices on or off and logging on times. I would like to use an interrupt to read device status and not poll all 8 inputs all the time. Problem with this design now is if I get a second interrupt on the board output to interrupt pin will not see it. I would like to add something like a one shot IC to set interrupt when ever I get a change on any input. Would love some suggestions on this projects and maybe what IC I may need to add. Circuit is attached and I hope is readable!

 

I'm designing an arduino board to read inputs from HVAC devices on or off and logging on times. I would like to use an interrupt to read device status and not poll all 8 inputs all the time.

I can't determine what you want. Since this post has a couple dozen views and no other replies, it appears I'm not alone.

You say you want to monitor status, but you don't want to poll the inputs. Can you monitor your inputs for rising and falling edges, or is it one or the other?

What are you trying to do with the one shots? When an optocoupler is turned on, it triggers the one shot, but you're clamping the timing cap so the one shot will never time out. Direct coupling the trigger is doing the same thing; the one shot won't time out until the monitored device turns off.

You have the 8 one shot outputs NANDed together. That will give you a HIGH output unless all of the inputs are HIGH. Is that what you want?

When you draw schematics, it's better to show the logic. I had to look up what an 'LS30 was... It seems that the schematic editor you're using emphasizes pin order instead of function. That makes for difficult to read schematics.


It's a bad idea to connect the potentiometers the way you have them. If the pot is inadvertently set to 0 ohms, the transistors will short the supply.

 

The 'pin change interrupt' is available on all Arduino pins but doesn't uniquely identify which pin changed, only into which of three groups it falls but you could use this to know that a pin has changed and in which group and then poll the pins in that group.
http://playground.arduino.cc/Main/PinChangeInt

 

I can't determine what you want. Since this post has a couple dozen views and no other replies, it appears I'm not alone.

You say you want to monitor status, but you don't want to poll the inputs. Can you monitor

I can't determine what you want. Since this post has a couple dozen views and no other replies, it appears I'm not alone.

You say you want to monitor status, but you don't want to poll the inputs. Can you monitor your inputs for rising and falling edges, or is it one or the other?

What are you trying to do with the one shots? When an optocoupler is turned on, it triggers the one shot, but you're clamping the timing cap so the one shot will never time out. Direct coupling the trigger is doing the same thing; the one shot won't time out until the monitored device turns off.

You have the 8 one shot outputs NANDed together. That will give you a HIGH output unless all of the inputs are HIGH. Is that what you want?

When you draw schematics, it's better to show the logic. I had to look up what an 'LS30 was... It seems that the schematic editor you're using emphasizes pin order instead of function. That makes for difficult to read schematics.


It's a bad idea to connect the potentiometers the way you have them. If the pot is inadvertently set to 0 ohms, the transistors will short the supply.

your inputs for rising and falling edges, or is it one or the other?

What are you trying to do with the one shots? When an optocoupler is turned on, it triggers the one shot, but you're clamping the timing cap so the one shot will never time out. Direct coupling the trigger is doing the same thing; the one shot won't time out until the monitored device turns off.

You have the 8 one shot outputs NANDed together. That will give you a HIGH output unless all of the inputs are HIGH. Is that what you want?

When you draw schematics, it's better to show the logic. I had to look up what an 'LS30 was... It seems that the schematic editor you're using emphasizes pin order instead of function. That makes for difficult to read schematics.


It's a bad idea to connect the potentiometers the way you have them. If the pot is inadvertently set to 0 ohms, the transistors will short the supply.

 

If I understand:

You want to know when each of eight devices (e.g., air conditioners) turn on and when they turn off. You want to timestamp each event for logging.

You believe that the reason your present set up does not cut it is that the output of the LS30 is in one state when all eight inputs are ‘0’ or all eight inputs are ‘1’. You want the output of the LS30 to be an edge-triggered source of interrupt but it does not distinguish between 1-7 units being on. So, if unit #1 comes on and all the rest of the units are off, you get an interrupt. If #2 comes on and #1 is still on, you do not get an interrupt. Am I close?

I think you need a different approach. You have not said anything about the precision of the timestamp. Because of my perception of typical examples of HVAC equipment, you don’t have the situation where an air conditioner, for example, comes on, then off, then on again, within a few milliseconds. In fact, you may only need to have a timestamp resolution of a few seconds. If that is the case, then a different approach may serve you better.

As has already been suggested by @AlbertHall, the Arduino pins can be configured for interrupts on a pin change. Also as he noted, they are grouped rather than individual interrupts. So, a pin change on D0-D7 produces a single interrupt. At first, I thought this may be the easiest way to get to a solution.

The problem is, as I recall, after you attach an ISR, execution of the ISR will end in a CLI and clear the interrupt. So, you will ‘miss’ any units that turned on or off while you are doing your interrupt processing. You might be able to streamline ISR processing, but the problem is that you have eight independent units and you don’t know when any will turn on or off. Given enough time, you probably will miss an event. Still, I am not completely discarding this approach.

I would set up a periodic interrupt unrelated to the data pins. The ISR would read the bits representing the eight devices, into a byte and compare it to the last such byte that was read. If the bytes are not equal, it saves the value and sets a flag in the form of a volatile variable. Your main program must have a routine that looks at the flag and does the actual data logging - determines what turned on or off and when. It also resets the flag.

You could use one of the Arduino Timers to make the periodic interrupt. You may have to add a counter to “slow it down” in the sense of only executing the meat of the ISR ~ every second. If you have an RTC to assist with the timestamping, you may also be able to configure it as the source of a periodic interrupt.

The advantage of this approach is that, if you miss an on/off event, it is still there to be processed by the next interrupt tick. As long as your main program can check at a reasonable rate (i.e. a rate that you are comfortable with for what you want to log), this will only result in a worst case scenario of the timestamp being slightly off.

I would dump the LS30 altogether. I also don’t understand the necessity for the 556s, and some of the transistors, but my understanding is limited and you may have your reasons.

I might not have everything correct here, but I hope this helps.

 

Sorry for not being clear! I'm inputting 24vac from HVAC devices, relays. The 74ls30 is for, if any one input goes LOW the output would be LOW, but if a second one goes LOW I will not know (so will not work!). So how can I make a pulse output to the interrupt if any of the eight inputs change? Yes I could poll all eight pins of a change. How should I connect the potentiometers? I haven't built this yet, still in the design stage.
recap: 24vac input thru optocoupler, to missing pulse det. if no ac present, HIGH out put to Arduino pin.
Any help would be great!

 

If I understand:

You want to know when each of eight devices (e.g., air conditioners) turn on and when they turn off. You want to timestamp each event for logging.

You believe that the reason your present set up does not cut it is that the output of the LS30 is in one state when all eight inputs are ‘0’ or all eight inputs are ‘1’. You want the output of the LS30 to be an edge-triggered source of interrupt but it does not distinguish between 1-7 units being on. So, if unit #1 comes on and all the rest of the units are off, you get an interrupt. If #2 comes on and #1 is still on, you do not get an interrupt. Am I close?

I think you need a different approach. You have not said anything about the precision of the timestamp. Because of my perception of typical examples of HVAC equipment, you don’t have the situation where an air conditioner, for example, comes on, then off, then on again, within a few milliseconds. In fact, you may only need to have a timestamp resolution of a few seconds. If that is the case, then a different approach may serve you better.

As has already been suggested by @AlbertHall, the Arduino pins can be configured for interrupts on a pin change. Also as he noted, they are grouped rather than individual interrupts. So, a pin change on D0-D7 produces a single interrupt. At first, I thought this may be the easiest way to get to a solution.

The problem is, as I recall, after you attach an ISR, execution of the ISR will end in a CLI and clear the interrupt. So, you will ‘miss’ any units that turned on or off while you are doing your interrupt processing. You might be able to streamline ISR processing, but the problem is that you have eight independent units and you don’t know when any will turn on or off. Given enough time, you probably will miss an event. Still, I am not completely discarding this approach.

I would set up a periodic interrupt unrelated to the data pins. The ISR would read the bits representing the eight devices, into a byte and compare it to the last such byte that was read. If the bytes are not equal, it saves the value and sets a flag in the form of a volatile variable. Your main program must have a routine that looks at the flag and does the actual data logging - determines what turned on or off and when. It also resets the flag.

You could use one of the Arduino Timers to make the periodic interrupt. You may have to add a counter to “slow it down” in the sense of only executing the meat of the ISR ~ every second. If you have an RTC to assist with the timestamping, you may also be able to configure it as the source of a periodic interrupt.

The advantage of this approach is that, if you miss an on/off event, it is still there to be processed by the next interrupt tick. As long as your main program can check at a reasonable rate (i.e. a rate that you are comfortable with for what you want to log), this will only result in a worst case scenario of the timestamp being slightly off.

I would dump the LS30 altogether. I also don’t understand the necessity for the 556s, and some of the transistors, but my understanding is limited and you may have your reasons.

I might not have everything correct here, but I hope this helps.

 

Sorry for not being clear! I'm inputting 24vac from HVAC devices, relays. The 74ls30 is for, if any one input goes LOW the output would be LOW, but if a second one goes LOW I will not know (so will not work!). So how can I make a pulse output to the interrupt if any of the eight inputs change? Yes I could poll all eight pins of a change. How should I connect the potentiometers? I haven't built this yet, still in the design stage.
recap: 24vac input thru optocoupler, to missing pulse det. if no ac present, HIGH out put to Arduino pin.
Any help would be great!

I may have responded while you were making your response. It takes a while to get used to the board - after you quote the message, just continue on with your response

I'm saying that you don't need the LS30 or any of the 556s or pots. The HVAC equipment turns on the LED in the opto and the transistor switches the input to an Arduino port bit. Maybe you need some signal conditioning in a noisy environment I suppose.

Informally put, no missing pulse detection strategy, instead a periodic interrupt from an internal Arduino timer or an external interrupt from an RTC. Your ISR polls the bits into a byte and lets your main program know that there has been a change. Your main program routine, figures out the change and the timestamp for logging.

 

Raymond I believe you have my intent of the 7430, but may not be the correct approach. If I understand your comments you have a point. The 556's are used as missing pulse det., when 60hz pulse input, output LOW. I don't need a timestamp to be on the money, (AC on, Heat on, Fan on, Pump running, etc.)
I thank you all for your time!

 

So do you want an interrupt or are you okay with polling?

From the reference regarding the Arduino interrupt capability, it's still unclear to me whether the ports can detect rising *and* falling edges or if it's one or the other. To me, it reads one or the other, but not both:

 

So do you want an interrupt or are you okay with polling?

From the reference regarding the Arduino interrupt capability, it's still unclear to me whether the ports can detect rising *and* falling edges or if it's one or the other. To me, it reads one or the other, but not both:
View attachment 126004

http://playground.arduino.cc/Main/PinChangeInterrupt
"The interrupt fires on a change of the pin state (rising and falling). For more information please refer to the excellent tutorials of Nick Gammon: http://gammon.com.au/interrupts"

I think we may have lost Tom, but let me ask you something about common word usage. When you say "So do you want an interrupt or are you okay with polling?", you are communicating a difference between 'polling' and interrupt. I have seen and heard this in common usage and I really am asking for my own education because I fear I am missing something...

To poll means to "record the opinion or vote of". In this case we mean to record the state of the pin. My problem is in the distinction between 'polling' and 'interrupt'. That is, you can poll in the main program without an interrupt or you can poll inside of the interrupt. I don't see it as a polling versus interrupt.

 

I don't see why polling would not work fine in this application. Interrupts would be overkill, arguably misapplied, and as others are saying, will take some care to implement.

I would poll each input or group of inputs and compare the new values with stored previous values. A difference indicates the input changed and needs processing. The current 'new' value gives ON/OFF status.

 

I would poll each input or group of inputs and compare the new values with stored previous values. A difference indicates the input changed and needs processing. The current 'new' value gives ON/OFF status.

I agree. For 8 inputs, polling will be small and quick.

 

I agree. For 8 inputs, polling will be small and quick.

Yeah, maybe. I don't know what else the program needs to do and simply examining the inputs in the main program may fit the bill.

 

When you say "So do you want an interrupt or are you okay with polling?", you are communicating a difference between 'polling' and interrupt. I have seen and heard this in common usage and I really am asking for my own education because I fear I am missing something...

In this context, polling is a continuous or timed event which may be too frequent, wasting compute resources, or not frequent enough, causing events to be missed.

Interrupts get the attention of a monitoring program by generating an interrupt. Hence less wasted resource and no missed events; assuming the interrupt wasn't masked (ignored).

If you want to search for a definition, qualify it with it's usage in computer science.

 

In this context, polling is a continuous or timed event which may be too frequent, wasting compute resources, or not frequent enough, causing events to be missed.

Interrupts get the attention of a monitoring program by generating an interrupt. Hence less wasted resource and no missed events; assuming the interrupt wasn't masked (ignored).

If you want to search for a definition, qualify it with it's usage in computer science.

 

Dl324 you said it! I would like to use ISR or timed ISR, don't want to waste time polling eight pins. Will be doing Temp and other logging, I'm also using RTC and SD card. I'm looking for some direction and still want it simple! This is a learning thing with hardware and code. I hope you can see why a miss pulse det. is needed. I will look into grouped pin change!
Thanks again!

 

Polling means to check something when you get around to it. Interrupt means that the something will, well, interrupt what you are doing and want to be taken care of right now. For something slow like monitoring HVAC on/off times, polling would be my preferred method - the HVAC just doesn't turn on/off fast enough and the time to be logged doesn't have to be to the microsecond. When you consider that even a modest processor like Arduino is orders of magnitude faster than the process you are monitoring, polling would work.

Of course, this means that the software has to be up to the task. It is not uncommon to see things that require faster processing (keyboard buttons for example) to be missed in a polled environment when the program uses lots of delay() constructs but that is a software design problem, not a problem inherent to polling.

Your circuit looks like it monitors something running with the TIL113 optos, one per channel then uses the 556's as missing pulse detectors for the resulting 1/2 wave output? Do you need detection that fast? When faced with similar detection, I have just sampled the opto outputs, 1/2 wave and all. There are various approaches but one simple one would be to dispense with the 556's and sample the opto outputs directly. Wait up to 1/2 cycle (8.3ms) for the opto collector to go low. If it doesn't, the input is OFF, if it does, the input in ON. Repeat for all inputs and log the results.

You can get fancier but you probably don't need to.

Good luck.

EDIT: TS replied while I was typing. This not meant to be argumentative.

 

Edited to remove quoted draft (which was incomplete and a partial duplication)

In this context, polling is a continuous or timed event which may be too frequent, wasting compute resources, or not frequent enough, causing events to be missed.

Interrupts get the attention of a monitoring program by generating an interrupt. Hence less wasted resource and no missed events; assuming the interrupt wasn't masked (ignored).

If you want to search for a definition, qualify it with it's usage in computer science.

I was NOT searching for a definition. I asked you why you engaged in the practice. I suspect that you knew that but decided it would be better to educate me with the explanation that "Interrupts get the attention of a monitoring program by generating an interrupt." As though I must not know that even though I just got through responding to the author with a scheme that used interrupts without all of the hardware in the initial design and also provided a citation to you that you can configure the Arduino interrupt mode to trigger an interrupt for a rising and a falling edge.

Never mind any of that because it is more important for you to school me when I first wrote about such interrupts correctly 30 years ago, but still I have so much to learn and thanks to you, I learned something new today. Honestly, does everything have to be a confrontation? Could not you just have said, "I don't know", or, "it's just a convention to draw a distinction that is common in practice" or something less snippy by adding what I should do if I want to search for a definition when, obviously I was not searching for a definition.

 

I'm in a parking lot, but I would use the Arduino pin change interrupt. In the interrupt service routine, I would use the port manipulation commands to save the status of ALL inputs in one statement. Thus, the ISR is totally minimized and you are unlikely to miss a second change.

If this sounds interesting, I can follow up when I'm out of the car and home.