Problem with external interrupts (B0-B2) on 18f452

[cncmachineguy]

Tom, for some reason, I am having trouble pisturing you magnet/sensor setup. Is it possible for the magnet to fire the int, but none of the 3 IF conditions are met? Is there anyway you can make a quick sketch showing the relationship of the magnets sensors, and pully? Doesn't need to be fancy, just a visual. Or even a picture might do it.

[TDuman]

Hi Bert,
Attached is sketch I drew in Paint.
Regards
Tom

[cncmachineguy]

That helps a ton.

so I don't know if my approach is flawed, I have something wrong in the code, or there is some hardware problem.

It may be a little of each. But first lets attack the hardware. I don't think you need the "R" signal. you can get the counts from the A or B. Now, the reason I want to drop it, besides making the code a little simpler, is I fear you may have some overlap in the fields. This could be why you get the wierd stuff with rising or falling edge trigger. Do you have access to a scope to actually watch B and R to see in B dies before R rises?

[TDuman]

Hi Bert,
I could have sworn that I replied to your last post last week.
I fact, I was anxiously awaiting your response and was checking 2 or three times a day, but never got one.
Then on Friday, I checked this forum again, and my reply was not there. (Maybe it was never there, but I would have sworn that I did see it)
Anyway, since there was no response, I figured you lost interest.
My respose to your last post July 26 was the following (as best as I can remember):

We have put the contraption on a scope and can cleanly see that the pulse finishes before the next one starts. The voltage on all pins is 5 volts and drops to zero when the magnet passes the sensor.
And besides, I am turning the wheel very, very slowly, to watch what I get in the interrupt registers.
I believe that I do need all three signals to tell which direction the wheel is turning. With only A & B, the sequence of signal would always be A-B-A-B-A-B, now matter which direction the wheel is traveling.
With three signals A,B, & R, The sequence would be A-B-R-A-B-R-A-B-R going in one direction, but A-R-B-A-R-B-A-R-B in the reverse direction.

We have an older version of this same contraption, that seems to work perfectly. However, I can't get my hands on the source code to see how it was done. That model was before my time, years ago.

regards
Tom

[cncmachineguy]

I usually never lose intrest in this type stuff. I have come to notice more often then not the OP will either resolve their problem or give up without ever posting about it. Thanks for checking again, I am sorry your post was lost. ANYWAY,

I will have to go back and look at the code again. I must admit I don't remember how I thought you could lose the R, I think I must have been thinking the A & B magnet fields would crossover and be more like a encoder output.

But now we at least know for sure it is not the hardware, so that variable is out of the question. I need to re=read the thread but will post something in a little bit.

[cncmachineguy]

Alright first things first. If it were me, I would put the timer check first, that way if an interrupt occurs, and it is not the timer, it MUST be a portb interrupt. That way you can lose the big 3 way or check.

Next up on my chopping block are the 3 IF's. is there any way for more then 1 int flag to be high at the same time? and if there is, you will do nothing in the ISR because of the AND checks. I would think you will have the correct results by simply checking each flag, 1 at a time and doing whatever there. These 2 things may not improve your current problem, but will certainly have bearing when that wheel gets going.

Now last, I realize the LCD part is just while debugging, but put it before the b port checks. this way you will do the "long" time stuff, then inc the counts based on int flags, then clear the flags. As it now, there is a possibility the int gets called for "b", by the time you get to checking, R flag is now set also. both counts should get updated but they won't. then you clear all 3 flags, so 1 could get missed.

Thats all for now, See if any of this helps.

[mackrackit]

I have not studied the problem but I will put in a couple of things.
1- ON INTERRUPT is not the best for time sensitive operations, ASM types are what you need. This is because ON INTs will not happen instantaneously, they will wait for other things to finish.

2- No matter what type of interrupt you use, you will want to get in and out of the ISR as quick as possible. Set a flag or set a AR while in the ISR and act on that in the main routine.

ASM interrupts are a bit difficult at times so Darrel gave us Instant Ints.
http://www.picbasic.co.uk/forum/show...ant+interrupts

[TDuman]

All of the responses I have received are very much appreciated.
I have gotten past accounting for the pulses, and I have been able to measure time and distance accurately (so it seems) thanks to the help from you all and from the engineers at my client.
We are getting ready to ship the first one, but now I have another problem that has been dogging me intermitently throughout this development project.
The system measures time and revolutions of a pulley that is lowering a device on a cable. The main display (two 7-segment LEDs) shows distance-out on one display bank, and the rate at which it is going out or returning on the other display bank. Whenever the system is reset, it increments an event counter (cast#), and resets the counters and elapsed time to zero. Intermittently, it will reset on it's own. As part of the start-up code it increments the cast# and resets all counters to zero. Since that is what seems to be happening, I conclude that it is actually restarting from the beginning. As an example, I started a test two days ago. It ran for about 10 minutes and reset, then ran for about 5 minutes and reset again. But since then it has been running for about 52 hours without a problem.
I have thought that perhaps this is being triggered from a power problem, so I burned the chip with the "brown-out reset" feature disabled. That seems to improve it somewhat but not eliminate the problem altogether.
I am looking for advice as to what (programming or hardware) would trigger this.

I also have another problem.
The main display, as I mentioned, is a pair of 7-segment LEDs (two banks of four) . But I also have a serial LCD (2 lines of 16 characters) that I use for debugging. The system also transmits logging data to a PC via a comm port. In the code, a variable (DEBUGMODE) is set to either zero of 1 to control which display to use (either the LEDs or the debug display, but not both.
During the current test (and one time in a prior test) the LED display froze (distance and rate not changing), but I could tell that the system was still running from the data coming into the PC, (distance, rate, and elapsed time). The debug mode was set off so there should not have been anything on the debug display. But on a hunch, I connected it while the system was wtill running without interrupting it. Sure enough, it is displaying data as if it is in debug mode (accounting for why the the main LED displays were not updating). I conclude from this that my DEBUGMODE variable somehow got changed. It is set only once at the beginning of the program, and then is only used in IF/THEN statements. So what can cause this to happen? I can program around this problem, but my concern is why is it happening, and what else could be happening that I don't know about?

TDuman