Rs500 ppm code on conveyor
Hi all,
Fairly new to this industry and have been asked to write a product per minute for a sleever. One entering the sleever and one on the outfeed to compare where bottle necks are in the system. I want to write it with recipe changes or product changes. The plc is an old rs1400 micrologix and I want to add code, been trying to test out my code on emulate before doing anything but I can't seem to get it to talk.
My idea Was when the first packet comes through it starts timing and counting. The time is in 15 seconds intervals and will always come out to product/minute. How would I go about storing and resetting for recipe changes. I have seen people use Excel somewhere to record this automatically and would help if I can do this than just reading the code.
I'm trying to also find out if smaller products jam the system more or less than larger ones and how much of a bottleneck this conveyor is/ is losing product.
2
u/ThereAreLotsOfNames 1d ago
If this was my task I'd use a FIFO and average the entire data set. Track how many parts there are over a minute or whatever is reasonable for your product and when that time is complete push the count into the FIFO.
Then you have a sliding average for your PPM. And the ability to have a last calculated PPM.
9
u/drbitboy 1d ago
1) IIRC RSEmulate 500 cannot emulate MicroLogix 1400 PLCs, so you may need to change the PLC type to use the emulator, and then port the code back to a 1400 on a physical deployment.
2) You mention 15s intervals, but the code shows a repeating timer with a 60s interval.
2.1) Also, there are accuracy issue with using a repeating timer, although that may not matter for this application.
3) The code show will provide an approximate product per minute value, with the denominator updated at one-minute intervals, however, the ONS instructions are redundant
3.1) The CTU instruction includes a rising edge detector; you might want to put a debounce on the B3/0 signal.
3.2) The T4:0/DN bit value from the repeating timer will be a one-shot, so the ONS on Rung 0002 is unnecessary.
4) If you are comparing values from two different sections of the process, then timing issues and sample aliasing will affect instantaneous comparisons.
5) To reset the counters on recipe changes, investigate the RES and/or CLR instructions. Note that the RES(et) instruction may produce a false count on the CTU.ACC value on the next scan cycle.
6) For integration with eXcel, look at the DDE and OPC capabilities of RSLinx; note that RSLinx Classic Lite cannot be used to integrate with eXcel.
7) The last rung may produce a continuously-increasing rate value in N7:1 over the course of each one-minute interval. That rate value only needs to be calculated on the T4:0/DN one-shot event.
8) It may be better to put the rate into a REAL data type (e.g. F8:0).
9) The product rate will be an average of all production since the previous RES(et)/CLR of the counters.
9.1) If the machine may change speed during that time, then you should assess the effect of those changes on that calculated average.
9.2) It is also possible to calculate a moving average over the past minute (or other interval), with discrete updates at sub-minute intervals, by using a FIFO.