shawnhimself
Member
Guys I have a monoblock that tracks a bottle through the machine using shift registers and an encoder. We typically have a reject system on the discharge of this monoblock tied to this shift register and encoder, making the rejection pretty standard.
This current setup however has a standalone reject system (10-12' away from the discharge) on a separate CompactLogix processor and conveyor encoder.
I sometimes get a reject slug of 3-4 bottles when only 1 bottle is actually bad, which leads me to believe that a the output is failing to unlatch under certain circumstances.
I did find that the total scan time for the master plc is around 30ms while the slave plc is around 4ms. Also it is using a discrete output fired from the master plc to the slave plc, saying hey...good/bad bottle coming at you. It seems kind of counter intuitive to track bottles from one plc to the next when the scan times are so far apart then adding the time for the output/input process.
Do you feel this could be a problem? Mind you I did not design this setup so I can't provide too much background on the reasoning or theory behind this. But I'd like to kick around some ideas on how to shore this up.
My initial idea would be to do this via MSG or P/C over ethernet rather than discrete signals, then put the time sensitive tracking in a separate periodic task. Again, thoughts?
Thanks, always.
This current setup however has a standalone reject system (10-12' away from the discharge) on a separate CompactLogix processor and conveyor encoder.
I sometimes get a reject slug of 3-4 bottles when only 1 bottle is actually bad, which leads me to believe that a the output is failing to unlatch under certain circumstances.
I did find that the total scan time for the master plc is around 30ms while the slave plc is around 4ms. Also it is using a discrete output fired from the master plc to the slave plc, saying hey...good/bad bottle coming at you. It seems kind of counter intuitive to track bottles from one plc to the next when the scan times are so far apart then adding the time for the output/input process.
Do you feel this could be a problem? Mind you I did not design this setup so I can't provide too much background on the reasoning or theory behind this. But I'd like to kick around some ideas on how to shore this up.
My initial idea would be to do this via MSG or P/C over ethernet rather than discrete signals, then put the time sensitive tracking in a separate periodic task. Again, thoughts?
Thanks, always.