Hello all, I am in the midst of a very strange problem. the machine has a metal detector sensor connected to my processor via an ADC channel. it is working fine, otherwise errors would have appeared on the display. the sensor also generates the expected 6 flank waveform when the shaft turns the wheel that moves the metal targets in front of the sensor. the problem is a 3 counters, that are incremented by 1 after 6 pulses, are incremented by 2 or 4, depending on the RPM of another shaft (the PTO, lets call it the main shaft) that is connected to the above mentioned one via a gearbox. the sensors shaft always turns at the same speed. so the counters are incremented by 1 of the main shaft of turning at 1000 RPM, but by 2 if it turns at 800 RPM, and 4 if it turns at 600 RPM. this behavior is reproducible on the machine. I ran the software on a simulator, injected 6 pulses using a signal generator but I cannot reproduce it in the lab. the person(s) that wrote the software did leave so many holes when it comes to interrupt safety - this is no exception - but I don't feel this problem is related to that. I haven't sent out test software with extra logging yet - will do that next week - I was hoping for some ideas first... here is what I excluded: probably no EMC involved, sensor functioning, no tremors of the assembly, software that increments counters is only invoked when it should (I hope), and the counters are only incremented at one location. I never see more than 6 pulses in a row (I think - I didn't do the measurement, but the waveform looks good on the scope capture) even on a machine. Any ideas?
Does the debounce code make use of a timer that overflows at lower RPM, resulting in false detections?
Does the code depend on the time between the pulses, for example by containing dual-slope integration?
I got his email:
"I wanted to inform you that the problem with the sensor is solved. There was a parameter ill configured in the engineering menu that determines if the machine seeks 1 or 6 pulses. I forgot to check this parameter. false alarm. kind regards and thanks for your effort."
This is an example of why a well-working program can be helped by post-debug features.
Too many configuration options can lead to very exciting "bugs" that a customer reports in. Without knowing everything about what the customer has done - and the environment the customer has - it can be very hard to figure out if they have missconfigured, have broken external equipment or have really found a bug.
I try to select a processor that will allows me a reasonable amount of extra speed and code space for extra code to analyze, log or dump. The extra capacity is of course good to have through all stages of the product cycle, from initial coding until end-of-life (which seldom seems to happen).