analog input signal buffering

I need to buffer an analog input signal. Why, you ask? Basically because my boss told me so, but the 3rd party input device signal is irratic.

So, without further justification, here is what I have come up with so far.

Option #1.
set up a self resetting timer, so that when it goes done, I take a sample. every 5 samples for example, I take the average.

Option #2
I take a sample every time the input changes, and then take an average every time the timer goes done.

Option #3
feel free, cuz I can't think of a third option at this time.


Any help would be greatly appreciated.

Thanks in advance

---
two brain cells shy of losing my programming position
---

hmm

I am starting to think (oh there's a scary thought), that I may want to take samples often, to try and reduce the error. Yet take the average less often, to slow down the change in the display. I think that this would favor option #2. The only question, do I bother waiting for the AI input to change, or do I take samples based off of so many scans, or so much time. Maybe a combination of options 1 and 2 using two timers eh?

By erratic, do you mean something like spikes or noise? If so, another approach might be to "filter out" the noise. IOW, sample continuously, but if the signal changes too rapidly, ignore that particular sample. Something as simple as a compare instruction could be used. Compare the new sample to the previous sample, and if the difference is greater than some value you've set, don't transfer the value. Or only allow the value to be increased/decreased by a preset value. Sort of a "smoothing" effect...

Totally unrelated to you problem, but along the lines of this "smoothing", reminded me of a program I did a while ago. It may help explain this "smoothing" I'm describing...

Overview... An indexing machine that transferred product on nests through a hot stamping unit (actually 3, but let's keep it at 1 for this example). The main drive was a barrel-cam drive (AKA Camco), which provided an index, dwell, index, dwell, etc. motion with the motor running continuous, though the motor was stopped every cycle to allow a longer dwell time so the stamper could cycle (The stamping was performed during this dwell time). Therefore, the stamper's cycle time dictated the overall cycle time of the machine (parts per minute).

Since the nests were loaded by hand, the operator loading product would occasionally miss a nest, and when this empty nest reached the stamping station, the stamping cycle was inhibited. This caused the machine to speed up for that cycle, since the stamper didn't cycle.

This made it extremely difficult for an operator to load the nests, because the machine would speed up when the operator wasn't expecting it, causing them to miss even MORE nests as they got "out of rhythm" with the machine.

Simple solution was to stick a timer in the program to simulate the stamper's cycle time when the stamper wasn't cycling. BUT, the stamper's cycle time was adjusted quite often to achieve a "good" stamp as environmental conditions changed (or when they changed products).

I used the most recent "real" cycle time of the stamper as the preset of this timer, so it would "learn" any changes that were made. This worked fine, unless someone made a drastic change to the stamper's cycle time. Not a problem if the time INCREASED, as the machine would just slow down, but if the cycle time was DECREASED, the machine would speed up instantly, once again confusing the poor operator loading nests.

The final solution was to "smooth out" the transition to the faster speed. Note: I used both the "real" stamper's cycle time AND the timer to inhibit the main indexer cycle. Both had to have finished before allowing an index. When the stamper's cycle time was shorter than the current preset of the timer, I only allowed the timer's preset to decrease by 0.1 second each cycle. This way it S-L-O-W-L-Y crept up to the new, faster speed. Since the speed of the machine increased so slowly, the operator was able to adjust to the speed easily. In fact, it increased so slowly that I think some operators didn't even realize that it was running faster!

For those who watched "I Love Lucy", think of the "Lucy at the chocolate factory" episode...

Hope this helps!

beerchug

-Eric

I like to go Hi Tech as much as the next guy...but can't you go old school and just place a 100mf cap across the analog signal?

Try this. It is code for a digital filter for an automationdirect plc but can be modified for any plc.

http://forum1.automationdirect.com/board/Forum1/HTML/000368.html

Here's a link to the old forum where Peter and I discussed low pass filters.

http://www.plcs.net/dcforum/DCForumID1/2730.html

Hope this helps

Now filters and buffers are good when you need them, and you have some excellent suggestions from others on how to proceed. But you might want to check this out first (paraphrased from a previous post by drewcrew6):

found that the ... power supply negative was Floating around and not tied to ground so I tried grounding at that point also. As soon as i installed that ground the all the [input signals] stabilized and has been running with no problem.

Click to expand...

If the offending 3rd party input device is a "four-wire" transmitter, then it is (in effect) a little power supply - in and of itself. Sometimes just grounding the negative or "low" side of its output signal makes an erratic PLC input clear up like magic. Even if the input device is a "two-wire" transmitter, you need to make sure that whatever power supply it's using isn't "floating" at some potential which is different from that which the PLC input module sees. If you're skittish about just slapping a HARDWIRE GROUND on an instrumentation signal this way, try grounding it through something like a 10K resistor. The basic idea is to give the instrumentation "power supply" a path (other than through the PLC input channel) through which to bleed off any stray noise signals.

If this "grounding" doesn't work, then some type of filtering or buffering arrangement is the logical next step.