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?
Have you made sure that you don't have bounces - many short pulses maybe us long that may not be visible with your normal timing on the scope?
Or may the pulses have slow flanks, so that you see one flank but your processor picks up multiple pulses from overlayed noise?
Let your processor emit info about found pulses on a digital pin, and display the input signal on one channel and your detection on another channel.
Hello Per, The input signals are required to remain stable for at least 10 milliseconds (but the software only executes that test every 20 milliseconds - you see how wonderful this legacy software actually is :-)....). Looking at the scope's captures I don't see serious fluctuations. The signal is nice and rectangular. the range of the measurement is something like this: anything above 7,2v is error, as well as below 500mv. voltage above 5,5v is high, the rest low. no problems there.
Per, thanks for your advice. I will look into it Monday!
great idea, it is a Namur sensor whose reading are fed into a digital input as well. so this will be very easy indeed!
Tamir; It sounds to me that your code has some debounce software that is sensitive to the pulse RPM(width). You stated a previous target did not exhibit the same problem. Was it running slower? Does your software have debounce code? Bradford
Al, The previous target did not generate 6 pulses upon completion of a whole rotation - but only one which was and still is enough. the funny thing is that the longer the signal, the bigger the counters error: at 600 RPM the error is always 4, at 800 RPM it is always 2, but non at 1000 RPM or even 1200 RPM! The pulses are getting narrower, or course, at high RPM (saw that at the scope captures) but never shorter than 120 ms. yes, the software has debounce - effectively it requires signals to remain stable for 20 ms. all the signals I saw on the scope capture where at least 120 ms. but the software should respond only to transitions - 6 rising edges are needed. I guess the most difficult part is that: 1. I don't see a fundamental mistake. 2. in the lab is rocks. 3. it works at 1000 RPM even though there is no direct connection between the that RPM and the sensor's shaft. 4. the machines in question are all over the planet but non is available to me. sounds familiar? :-)
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).