Tracking Product - Two PLCs

shawnhimself

Member
shawnhimself
Join Date
Oct 2006
Location
LBC
Posts
84
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.
 
...it is using a discrete output fired from the master plc to the slave plc, saying hey...good/bad bottle coming at you.
Click to expand...
Once the slave PLC gets a bad-bottle signal, how long does it take to open the discharge gate? Is it more than 30 miliseconds? (This gate closing time could vary if a solenoid is used and the solenoid voltage supply is not always constant, for example if some other large load happens to come on at that time and cause the supply voltage to drop 15 or 20%).

Is there enough time between a bad bottle and the next good bottle for the gate to ALWAYS close under the worst conditions of low voltage, worn or jammed gate, and a bottle slightly out of position?
 
It's actually a segmented rejector. So... 10 solenoids and 10 segments. There is enough time between bottles because it will reject one just fine and close before the next bottle typically. It's these phantom slugs that are confusing me.
 
Last edited:
It's these phantom slugs that are confusing me.
Click to expand...
Then it is an intermittant problem, the hardest kind to troubleshoot.

Look for places where you could get induced voltage on your solenoid wires. Are these DC or AC solenoids?

Is there any higher-voltage wiring in the same bundle or tray with the bottle discharge solenoids?

Are the wires for the 10 segment solenoids in shielded cables or metal conduits?

...tracks a bottle through the machine using shift registers
Click to expand...
I remember the old LogixPro Bottle Line Simulator program. One of the common student errors in the bad-bottle discharge routine was not checking the "bad bottle bit" in the next bit-shift position AFTER the bad bottle had been discharged. (The bad-bottle bit was still in the next shift register position, even though the bottle was gone). This had to be done to count the bottle in the Reject Count. Also if the next bottle AFTER the last bad bottle is good, the discharge gate must be immediately closed. On the other hand, if there are two or more bad bottles in a row, the gate must be left open until all are rejected.
 
Last edited:
Yes unfortunately it's not something I can replicate, the WORST.

DC Mac solenoids, they are in a self contained unit, they run from the valve bank down to the panel so only about 10" are exposed. There is no high voltage in the panel or around the panel either.

The cables are not shielded, like I just mentioned they run from the valve into the panel using a strain relief.
 
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.
Click to expand...
At some point, you should somehow verify that your discharge solenoids are not "hanging open". If they are energize open-spring closed, then the springs could get weak and not always close a solenoid until much later (lazy solenoid or dragging solenoid). Sometimes the only sure way is to put in a new spare solenoid and see if the problem goes away. If you have 10, I don't know how you could isolate a slow-closing one in the bunch.

You can verify that the bit-shift register is calling for a bad bottle when a bad bottle is at the discharge gate. In Allen Bradley RSLogix you can actually open the bit file in the Data Monitor mode and watch as a bad-bottle bit is set to 1, then watch that "1" bit all the way to the bit-shift register position where the discharge gate is located. (I am sure that the CompactLogix version is similar). It the "1" does not make it to the gate position at the right time, then the bit-shift register has a slight position error.
 
Last edited:
shawnhimself said:
Yes unfortunately it's not something I can replicate, the WORST.

DC Mac solenoids, they are in a self contained unit, they run from the valve bank down to the panel so only about 10" are exposed. There is no high voltage in the panel or around the panel either.

The cables are not shielded, like I just mentioned they run from the valve into the panel using a strain relief.
Click to expand...
OOOOH! Red Flag!
Do the solenoids have a reverse diode across the coil??? Those valves can generated a horrendous spike on the DC power supply when the coils turn off!!
 
OOOOH! Red Flag!
Do the solenoids have a reverse diode across the coil??? Those valves can generated a horrendous spike on the DC power supply when the coils turn off!!
Click to expand...
A large spike to the DC power supply could then keep any open solenoid energized longer than normal, perhaps causing an extra bottle or two to slip through.

A lot of those ultra-high-speed gates work by giving a voltage pulse of a certain voltage and duration to a solenoid coil to trigger the gate. If the pulse is higher-than-normal voltage, the gate could stay open longer.
 
Last edited:
I could see that if one or two of them stayed active but when this happens all 10 stay energized. That's what lead me to believe the handoff from plc to plc was not always happening the way it should.
 
All 10? Un-Oh! That is probably not relay drag and not induced voltage not a voltage spike.

It would be difficult for us to help you with the hand-off from PLC to PLC. There are so many variables involved in that. Comm speed is the first thing that comes to mind. If there are times when your PLC comm network slows down, that might cause the problem.
 
Lancie1 said:
All 10? Un-Oh! That is probably not relay drag and not induced voltage not a voltage spike.

It would be difficult for us to help you with the hand-off from PLC to PLC. There are so many variables involved in that. Comm speed is the first thing that comes to mind. If there are times when your PLC comm network slows down, that might cause the problem.
Click to expand...


I was just hoping there was some obvious detail I was overlooking. I appreciate the help! Looks like I'll require some downtime to run some tests and do troubleshooting in the program. I also need to check the relays between the machines, we typically use solid state but it wouldn't be out of the question for the bad bottle relay to be mechanical.
 
Perhaps the reject sensor is being affected by heat or moisture either in the air or from the bottles. I had a similar problem years ago sensing uncured bricks that were not sliced properly (doubles and ends).
 
Last edited:
shawnhimself said:
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?
Click to expand...

If you're already suspect timing issues with the hand-off of good/bad bottle signals, don't add another variable into the mix by using explicit messaging or p/c tags. It's hard to beat the speed of light, so I wouldn't jump to bypassing the discrete signals.

One good step to take may be to set-up tracking logic in the master and slave plc. Count good and bad bottle output signals from master and good/bad input signals into slave per shift.
See if the totals add up. If you have more output signals in your master than in the slave, then you have a wiring problem between the two plcs.

Do you have a sensor to count bottles that actually go down the reject chute/gate? If so, count the # of times the reject gate(s) are fired, and the # of bottles that pass the sensor. If sensor count > solenoid trigger count, then you have a coil or valve problem, or a mechanical problem on the gate.

You could also build a FIFO queue of reject gate solenoid "on" times, have it hold several hundred values. Every time the reject gate output is fired, run a timer when output is on. In the rung above the timer, use a one-shot after an xio of the output to move the timer accumulated value into your queue. That way you can go back and see patterns to how long the solenoid should be on. This will show you if the coil is actually being told to be on for those 3-4 bottle slugs, or if it is just getting a normal one-bottle pulse, but the gate is staying open for whatever reason.

Good luck to you.

Cheers,
Dustin

🍻
 
bmacattack33 said:
If you're already suspect timing issues with the hand-off of good/bad bottle signals, don't add another variable into the mix by using explicit messaging or p/c tags. It's hard to beat the speed of light, so I wouldn't jump to bypassing the discrete signals.

One good step to take may be to set-up tracking logic in the master and slave plc. Count good and bad bottle output signals from master and good/bad input signals into slave per shift.
See if the totals add up. If you have more output signals in your master than in the slave, then you have a wiring problem between the two plcs.

Do you have a sensor to count bottles that actually go down the reject chute/gate? If so, count the # of times the reject gate(s) are fired, and the # of bottles that pass the sensor. If sensor count > solenoid trigger count, then you have a coil or valve problem, or a mechanical problem on the gate.

You could also build a FIFO queue of reject gate solenoid "on" times, have it hold several hundred values. Every time the reject gate output is fired, run a timer when output is on. In the rung above the timer, use a one-shot after an xio of the output to move the timer accumulated value into your queue. That way you can go back and see patterns to how long the solenoid should be on. This will show you if the coil is actually being told to be on for those 3-4 bottle slugs, or if it is just getting a normal one-bottle pulse, but the gate is staying open for whatever reason.

Good luck to you.

Cheers,
Dustin

🍻
Click to expand...

There is a sensor that signals when the reject lane is full, I could use this to count actual rejects as they pass down the lane. I'll set up the troubleshooting logic tomorrow with that included. Thanks for the reminder of keeping it simple, I get over zealous at times with my solutions! 🔨
 
I totally understand the over-zealous thing, I get accused of that quite often myself! :ROFLMAO:

Let us know how it turns out!

Cheers,
Dustin

🍻
 

Similar Topics

P
Product Tracking Problem
Hey Folks. Using RSL5K on V21 I'm working on a little project here. Proving to be a bit of a challenge. I have a production line that is an...
2
Replies
17
Views
3,885
alive15
A
W
Continuous Product Tracking
Scenario: Two different cutting machines drills material and put that on two different stock piles. The stock piles can have more than one cut...
Replies
2
Views
1,442
gclshortt
gclshortt
MartB
RSLogix 5000 Product tracking
Product tracking based on time and position. I'll be using a 1769-L16ER-BB1B processor. There will also be an HMI involved, but it will be for...
2
Replies
24
Views
18,316
MartB
MartB
L
Conveyor Product Tracking
I'm a newbie to tracking concept. I have assigned a project to handle product tracking. Product should be delivered to destination without any...
Replies
10
Views
9,817
PeterW
P
P
Product Tracking with a ML1500
Gents: I have an application coming up that I would like to get some opinions on. I have a conveyor that will be running 100FPM that I will need...
Replies
14
Views
6,187
OkiePC
OkiePC
Back
Top Bottom