PLC Program Monitoring

[Gordo26 0]

Hi all, I'm having some difficulty determining the cause of an issue I'm having. I have proximity switches that control the motion of a conveyor motor and often times metal shavings will cause faults to arise in our system. These proximity switches also control when data is being sent down the line to the next station. I get a couple of faults occur at one time and then I also happen to lose data. In retracing the events I can't seem to wrap my head around how I'm actually losing the data. Much worse I can't recreate the problem because that would cause downtime. So I need to find an alternative way of finding the actual cause of my data loss. I'm not looking for someone to solve my problem(would require way too much information) but I was wondering if anyone has run into problems with PLC programming where they couldn't actually see how a problem was happening, and if so, how they overcame the problem. Is there any type of diagnostic tools available in CX-Programmer where I might be able to simulate a problem and then watch the order of how everything happens? I've been told my order of operation may be a problem as well, but I can't seem to see it! Thanks, Gordo

[Andy_P 7]

Pretty hard to give much more than a general answer, but a few suggestions: Debounce the proxy switches. Make sure the switch is on (or off) for a constant amount of time before acting upon it. When the proxy switches are triggered you could latch a memory. This flag can be used to trigger all the things that the proxy switch would do, but will be immune to flickering switches. You could use this in conjuction with any debounce timer. Set up counters for each proximity switch. These counters don't have to control anything, just record how many times the switches were actuated. Be sure to make the pulses from the proxy switches one-shots. You may find that one/some/all of your switches multiple trigger sometimes when you don't want or expect them to. Set up a counters for each data transfer event. As above, they don't need to control anything, but simply indicate how many times transfers have occurred. Every time you need to transfer data, you can transfer it where you need it to go, but also copy the data to a stack of some kind. (If the data is not too big.) That way you can see if any 'blank' data is being transmitted, or none at all, etc.

[PMCR 66]

Andy_P had some great suggestions! I do exactly as he suggested, and create counters (or simply ++ (Binary Increment instruction) on different memory locations) to look for inconsistencies in data from sensors. The other thing that you can use, if you have any way of trapping for data loss in the PLC, is the Data Trace function. This is like an oscilloscope in the PLC, with the capabilites of being triggered. If you can setup a 'trigger' even, you can use the Data Trace function with a negative sample delay (look back in time) to help track down the problem. Below is a link to a technote on the Data Trace function. http://forums.mrplc.com/index.php?app=downloads&showfile=822

[Gordo26 0]

Thanks a ton guys, I really appreciate. The Data Trace Tool looks extremely powerful and useful. Right now I'm trying to simulate some situations using CX-Simulator, trying to see if I can duplicate the problem in some way. The debounce on the prox's should be also very useful as it might even negate my problems all together. I'm going to set up something with the Data Trace Tool and see if I can view what's happening right at the point of the issue and really see what's happening. Again, thanks so much for your help, I've only been in the field 6 months (finished school in June 2011), so I apologize for any newbie type questions. Gordo26

[Andy_P 7]

Don't worry about newbie questions. We all have to start somewhere. Whether or not you have a problem like this, you always have to bear in mind how things physically work in the real world. For example: If you turn on an output for a single scan of the program and expect a relay that is connected to this output to energise and do it's thing, then you will most likely find that it won't. (Depends of course on the cycle time of the PLC and the relay in question though.) A chain or belt driven item may well have an amount of backlash in the system, so that when you energise the drive, nothing actually moves until this backlash is taken up. Probably not much, but would be noticeable by the PLC if you expect a sensor to be uncovered the instant you energise the drive. Also be aware of how a PLC scan works. In simple terms it generally it follows the "Read the inputs, scan the program, write to the outputs" sequence. This means that you could toggle an output on and off a thousand times during the scan cycle of the program, but it is the state of this output at the end of the program scan that will get written to the actual physical output. In other words, a device connected to to this output will do precisely nothing at all if it is always turned off at then end of your program. Anyhow, I'll stop rambling now. Good luck with solving your problem!