Consecutive Faults

This is a program I wrote for testing fuel level sender units that we manufacture. This is a life test that runs for 100K cycles and records up to 10 'out of tolerance' readings for each UUT. The engineers believe that I have made the test too sensitive. They would prefer that a failure in only recorded if the consecutive out of tolerance measurements are recorded for each UUT. The problem is that I can only record one reading for each out of tolerance event -- until the analog input goes back within range and then back out (which would be a true-false-true histogram the way I have the LIM set up). The counter only increments if a false to true transition is made; therefore, if a UUT does go bad, and stays bad, I will only get one measurement. I thought about using the scan toggle bit -- but I'm not sure if that'll work. Is there any way I can make this thing record one bad reading (which should be the average of the 3) only if the reading is out of tolerance for 3 consecutive scans? Then repeat this until 10 out of tolerance readings are recorded?

Sorry,

Forgot to mention that rung 63 is what I'm interested in -- hate to make you guys look for what I'm talking about.

ronboom said:

The counter only increments if a false to true transition is made; therefore, if a UUT does go bad, and stays bad, I will only get one measurement.

Click to expand...

Instead of a counter, use the ADD instruction to make a 'homebrew counter'. I'm pretty sure that ADD doesn't look for transitions. It will preform the ADD every scan when the preceding conditions are TRUE. Therefore, you will increment this 'homebrew counter' each scan that the UUT gives a bad reading.

IOW, replace CTU C5:8 with ADD, and pick a place to store the value (i.e. N7:0). That will be your 'Source A' and 'Destination', use "1" as your 'Source B'. Then, replace your XIO C5:8/DN with GEQ (Greater than or equal to). 'Source A' will be your N7:0 value, and 'Source B' will be "10".

You'll have to do this for each limit test, using a different storage location for each 'homebrew counter'.

But wait a bit before bothering with my method... Someone will probably chime in with an easier solution...



-Eric

Look at this

No guaruntees that this is a final finished product, but check it out for my idea.

I commented my section, it's rungs 63-66.

Marc

You can make the counter count for each scan that its rung is true by placing an unconditional unlatch of the counter's .CU bit in a new rung just before the counter.

CroCop,

Thank you so much! It is really great to get such quick support to problems! I definitely like your idea and will try it out tomorrow or Thursday (in Detroit Wednesday). I don't do PLC programming for a living, but they do make my life a lot easier. I'm the validation test guy. I am working on a new fuel sender tester that induces slosh per a MIL spec. The tester will be PLC based with a PanelView as the operator interface (as I'm sure you've figured out this program is as well). The test is basically a teeter totter fixture which holds a 135 gallon fuel tank (heavy truck). The test is supposed to be performed at a rate of 1,500 cycles / hour. The timing will be dependent on proportional hydraulic valves. I may need help with some PID instructions (never had to use them) to keep the cycle rate as close as possible to 25 cycles per minute. I plan to have the PanelView display the last cycle time (mS), cycles completed in the last 60 seconds, and cycles completed in the last hour. Let me know if you're willing to help out.

ronboom,

change the order of the set bits. The third one should be first in the rungs, followed by the second, then the first. Other wise the limit will be made on the first, then the first will be on, and the limit will be made on the second, etc.

I forgot to go in reverse to accomodate the scan procedure.

I was just looking at that and had the same thought. Will do.

Yeah, I just threw it together while watching the first season of 24 on DVD. I'll be glad to help with anything ya post, I love this stuff. Good times.

CroCop,


I had to tinker with this a bit; but I think it is working now. It didn't like the latched bits being used for the OSRs as well. It also had computational errors so I summed everything in a floating point and then divided that & put it back into an integer. I know it's been a while but I just got everything caught up and had a chance to play with it.

Thanks for all of your help.
Ron