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?
Come again?
Sorry, but your problem description is just too confused to be analysed. Let's see:
1) You open your description talking about some ADC value, but then it's never mentioned again. Why?
2) What on earth is/are "a 3 counters"?
3) So you have counters that are supposed to be incremented by one after six pulses --- how? I.e. what actually does your software do with each of those pulses?
4) What is that waveform: 6 flanks, or 6 pulses?
5) Just how many shafts are there in this contraption, anyway?
6) This: 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. is sort-a self-contradictory: "you" never "see" more than 6 pulses --- yet by what could be understood from your description, your software clearly does see more.
Summing it up, I'm pretty sure that you posted here too soon. You really need to run tests from inside the software, on the real metal, before you can even begin to speculate about reasons of the problem.
Hans, Thanks for your reply. Here are the answers to your questions. I really feel like one of these anchors grading the eurovision songs :-)
1. the ADC's reading is fed to the processor both via a channel and a digital input. The conversion are indeed interrupt driven but I don't think that these conversions are the problem in this case. maybe i'm wrong - anyway I was going to guard the ADC's values in this case just to be sure.
2. the only significance of the counter is the fact that they are located at the same place in the program, so it helped to convince me that it goes wrong at that point.
3. the old hardware was generating one pulse only - a pulse not a flank, sorry for that - which is enough actually. the sensor was placed where it is now for mechanical reasons beyond my influence. I only need one, truly, but I have to know WHY this goes wrong. the guy who wrote it just decided to collect all the pulses that the sensor generated until the shaft stopped. no big deal.
4. see 3.
5. many =:0, but only 2 of interest: the PTO (actual RPM of the entire machine) and a secondary that generated the pulses on my sensor. there is a gearbox in between.
6. The scope captures that I got from the field seem to confirm that no more than 6 pulses are generated, and I have an eye witness to confirm no excessive rotation. clearly, something does create more pulses but I cannot see them via a scope! the software is not flawless, but why then can't I make it happen in the lab?
I will have other people run tests at the field using a debug version. in the mean time if anybody has a bright idea - don't be shy!
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).