Part rejection down line

[Bob O]

Thanks Berine but still the same.

Bob

 

[Allen Nelson]

Improvement #2

You are going to have another problem eventually (possibly already have, if you're getting faults about indirect addressing).

You are (inadvertantly) storing the entire history of every part ever made.

The first one is at N11:0. The second at N11:1. etc. Eventually, you will have made 255 parts, and exceed N11:255 (the limit of the file), and the processor will fault.

Another approach: Instead of using a counter (C5:11) to point to the unload location, shift the entire data table down by one instead.

The code for that (two branches):
COP #N11:1 #N11:0 128
SUB C5:4.ACC 1 C5:4.ACC

Put this (with a oneshot before it) in place of the Counter for C5:11.

By doing this, the value in C5:4.ACC will have the number of parts between PE2 and PE3. Then, N11:0 will always contain the value of the part AT PE3. Therefore, you would change your indirect address N11:[C5:11.ACC] to a simpler N11:0.

You'll also have to answer a question (and one which may be giving you some grief right now): Whether or not to reset C5:4.

If you do reset it, then you had better make sure that there are no parts on the line when you start up, otherwise you are going to be out of synch (and possibly put a negative value in the counter, although this can be coded around. In fact, such coding could be used to help synchronize the system, if parts run past PE3 without first being seen by PE2).

If you don't reset it, then you had better make sure that no one ever removes parts from the line, even when there's trouble, or you will be out of synch.

 

[Bob O]

Thanks Allen but still the same.

Bob

 

[electrified3]

Hey Bob,
Bernie nailed it on the head there.

In rung 10 replace I:1/3 with T4:17/DN, this is declaring a bad part to the wrong register as the counter has not yet indexed up in count as it is waiting for the debounce time, thus shifting the value to the wrong indirect register.

In rung 12 replace I:1/2 with T4:18/DN as it will be declaring a bad part on the wrong indexed register as the debounce time has not yet indexed the count up, so it would eject the wrong part possibly.

Sorry about that, I have made it my practice to involve debounce timers when using photo-eyes with fast moving parts on a conveyor as a slight flicker as it enters or exits the photo-eye can cause alot of grief in logic.

Do they ever shut down the machine with parts still on the exit conveyor there? Just as a ote by resetting the index registers and counters on cycle start all parts will be declared bad and ejected, it is the failsafe way to go, but just be aware of that circumstance.

 

[Bob O]

electrified3,

I added the timer DN to both rungs as bernie advised (but didn't delet the inputs) and I can see their place, but how does that cause me to eject the good and bad lid when its leading a bad one but not the other way. If I have a bad lid in front of a good lid I just eject the bad. Sorry, I am just pulling my hair out on something that shouldn't be as dificult as I am making it.

Thanks,
Little Bobby knocking on the Sh%$t Bus Door

 

[electrified3]

You still here Bob?

 

[electrified3]

I tried toexplain it better in PM Bob, hope it makes sence to you

 

[Terry Woods]

Bob...

What kinda AB critter (software) are you using?

BTW, electrified3...
Why not post on board instead of PM?

 

[electrified3]

Bob, are you using B3:1/7 as a test/disable bit? I see it in the parallel rungs of your eject ouput in rung 14?

 

[electrified3]

Sure, could do that, just saw PM after I responded to thread, will go back and copy it to here then also.

 

[electrified3]

Part 1
Hey Bob, sorry been out on the road for last few days, I looked at the thread and responded in there. Bernie nailed it there, the line part counters were not indexing before the good/bad part logic was detemined which would cause some weird results. Look at the reply in there and see if that makes sence to you, make the changes and let me know if the problem clears up for you.

FYI, email is @@@@@@@@@@@@@@@@@.com if you have trouble email me I generally check that no matter where I am at.

 

[electrified3]

Part 2
The problem I see was:
First scan after seeing part at PE 2
Wait 0.1 sec before indexing count up
Next rung "if a part is there":
If bad write 0 to N11:[parts counted]
If good write 1 to N11:[parts counted]
Disregard rest of logic for the moment

So a part was seen but counter does not index until debounce timer completes, so good/bad was sent to the wrong register as the parts count has not indexed and it was only looking for a part present not debounce timer done before making it's decision of good or bad part.
At the same time, after the part was under PE2 for 0.1 sec it then did index the counter up, then sent an additional good/bad part decision to the next register based on the part count now indexed up.
Solution, don't make a decision if good or bad until the debouce time has completed. Change PE2 input to timer done bit.

Later down in the logic, when parts were seen at PE3 the same kind of condition existed. Parts Out count did not index up until it was seen for 0.1 sec, but the good/bad decision next was made immediately next when PE3 was true before the count actually indexed up after 0.1 sec. Change PE3 Input to Timer done bit.

So if that makes sence to you might help to explain the bizarre results you were seeing.

Try the changes and see if it clears up the problem. I am pretty sure the indexing of the count vs the decision making may be the problem.

Good Luck


Is that better???????

 

[Bob O]

Terry,

Critter? I created some of it.

electrified3,

B3:1/7 is to disable other logix so that I can test this.

I don't understand a lot but how can it work one way and not the other? It works from a bad too good state (lid) but not from a good too bad state(lid) with a lid in the bad state. If there is no lid present in the bad state it works fine. The DVT fails if there is no lid because of the criterion I set up.

Thanks,
Bob

 

[electrified3]

Well I hope you can make sense of this, it is a bit confusing, was easy to break down, but difficult to put inot words, hopefully I don't confuse the hell out of you Bob.

Condition 1
Part 1 Bad, 2 Good, 3 Bad - Rejects all

Parts count “IN”

Part 1 enters PE2
C5:4/ACC = 0
Part good bad status recorded to N11:0 = “0” in this case
After 0.1 seconds C5:4/ACC index’s to 1
Part good bad status recorded to N11:1 = “0” in this case

Part 2 enters PE2
C5:4/ACC = 1
Part good bad status recorded to N11:1 = “1” in this case
After 0.1 seconds C5:4/ACC index’s to 2
Part good bad status recorded to N11:2 = “1” in this case

Part 3 enters PE2
C5:4/ACC = 2
Part good bad status recorded to N11:2 = “0” in this case
After 0.1 seconds C5:4/ACC index’s to 3
Part good bad status recorded to N11:3 = “0” in this case

Result
N11:0 =0
N11:1 =1
N11:2 =0
N11:3 =0

Parts count “OUT”

Part 1 enters PE3
C5:11/ACC=0
Part Good/Bad checked to N11:[ C5:11/ACC]
Value in N11: register is equal to 0 so eject command sent
Latch is set and held for 0.3 seconds to complete eject based on logic
After part under PE3 for 0.1 seconds C5:11/Acc = 1, but because latch is already set to eject it completes eject time

Part 2 enters PE3
C5:11/ACC=1
Part Good/Bad checked to N11:[ C5:11/ACC]
Value in N11: register is equal to 1 so eject command not sent
After 0.1 seconds C5:11/Acc = 2
Then part is still under PE3 so it then sees a value of 0 in N11:2 and then issues a command to eject the part
***Note: The eject command was delayed 0.1 seconds later than eject on part 1




Part 3 enters PE3
C5:11/ACC=2
Part Good/Bad checked to N11:[ C5:11/ACC]
Value in N11: register is equal to 1 so eject command not sent
After 0.1 seconds C5:11/Acc = 3
Then part is still under PE3 so it then sees a value of 0 and ejects the part
***Note: The eject command was delayed 0.1 seconds later than eject on part 1

Thus Part 1 Bad, Part 2 Good, Part 3 Bad, All Parts Rejected


Condition 2
Part 1 Good, 2 Bad, 3 Good - Rejects 1 & 2 But passes 3


Parts count “IN”

Part 1 enters PE2
C5:4/ACC = 0
Part good bad status recorded to N11:0 = “1” in this case
After 0.1 seconds C5:4/ACC index’s to 1
Part good bad status recorded to N11:1 = “1” in this case

Part 2 enters PE2
C5:4/ACC = 1
Part good bad status recorded to N11:1 = “0” in this case
After 0.1 seconds C5:4/ACC index’s to 2
Part good bad status recorded to N11:2 = “0” in this case

Part 3 enters PE2
C5:4/ACC = 2
Part good bad status recorded to N11:2 = “1” in this case
After 0.1 seconds C5:4/ACC index’s to 3
Part good bad status recorded to N11:3 = “1” in this case

Result
N11:0 =1
N11:1 =0
N11:2 =1
N11:3 =1

Parts count “OUT”

Part 1 enters PE3
C5:11/ACC=0
Part Good/Bad checked to N11:[ C5:11/ACC]
Value in N11: register is equal to 1 so eject command not sent
After 0.1 seconds C5:11/Acc = 1
Then part is still under PE3 so it then sees a value of 0 in N11:1 and then issues a command to eject the part


Part 2 enters PE3
C5:11/ACC=1
Part Good/Bad checked to N11:[ C5:11/ACC]
Value in N11: register is equal to 0 so eject command sent
After 0.1 seconds C5:11/Acc = 2
Then part is still under PE3 so it then sees a value of 1 in N11:2 but eject latch has been already set so eject is completed.

Part 3 enters PE3
C5:11/ACC=2
Part Good/Bad checked to N11:[ C5:11/ACC]
Value in N11: register is equal to 1 so eject command not sent
After 0.1 seconds C5:11/Acc = 3
Then part is still under PE3 but the status value is equal to 1 so it still does not eject that part and allows it to pass.

Thus Part 1 Bad, Part 2 Bad, Part 3 Good

So, as I stated earlier, by using your debounce timers in conjunction with your good part/bad part determination logic you will re-align your counter index logic to your decision making logic which should take care of the overlap which I believe is causing the problem.

 

[Terry Woods]

Bob,

I meant, what PLC Software are you using.