Sign in to follow this  
Followers 0
Jamey

Student advice

39 posts in this topic

Hi everyone!

I am new to PLCs and am baffled.

I have worked my way through the LADSIM PLC simulator questions and am baffled by the final one.

Almost all the problem has been solved - there is only one small part left.

 

There are 3 items to detect on a conveyor belt:

Assembled item, peg, and ring.

 

There are SPECIFIC sensors for assembled items and pegs.

HOWEVER, there is NO specific sensor for rings.

 

I need to understand HOW I can detect rings without a specific sensor!

 

I've included a plan of the machine.

IP3 = Assembled item detector.

IP8 = Detects metal items (so detects pegs and assembled items)

IP4 = Detects EVERYTHING - used to move the bitshift register.

 

IP5 = Detects ANYTHING in the reject area.

OP3 = Rejection piston.

I need to detect the ring - but how?

 

This is how it is supposed to function: https://www.youtube.com/watch?v=6YFHfiQCqBs

 

I have had sleepless nights over this!

Thank you for any help. It would be much appreciated.

 

 

SNIP Q.7 2.PNG

Edited by Jamey

Share this post


Link to post
Share on other sites

Think logically. If it's a ring, then it's something, right? Presumably the "anything" detector will see it but the "assembled object" and "peg" detectors won't...

Share this post


Link to post
Share on other sites

Thank you for taking the time to reply to my panicky question, Joe.

IP3 is set HIGH

IP4 is set HIGH

IP8 is set LOW

I wrote this line to input the data into the Bit Shift Register to track items.

RUNG 1

--------|/|3--------(Send Bit to BSR)

|-------|  |8--------|

 

IP3 = Detects assembled items.

IP8 = Detects assembled items AND pegs.

 

Since it is impossible to avoid this, it means ALL assembled items and pegs are labelled 1.

So, I had to write another line of code using IP3 to subsequently erase the 1 from Assembled items and change it a 0.

Therefore, this line of code DOES input the correct data into the Bit Shirt Register.

However, it does not detect rings.

 

WHEN I add another subrung to RUNG1 to detect rings:

--------|/|3--------(Send Bit to BSR)

|-------|  |8--------|

|-------|  |4--------|

 

It doesn't work as expected.

Now, it detects rings but the numbering in the array is wrong for all items.

Not sure why yet.

Edited by Jamey

Share this post


Link to post
Share on other sites

In your first post, you said IP8 detects pegs, but in your second post, it also detects assembled items.

It might help to draw a matrix listing the inputs down the left and the items to be detected across the top. Put a "1" or "0" in each field of the matrix. You can use that to identify the logic you need to detect each object.

Share this post


Link to post
Share on other sites

For the unchanged rung, the IP3 OR IP8 input 1 into memory location 15, for example, 1000 0000 0000 0000

Then, IP4, when triggered, pushes it forward, so, 0100 0000 0000 0000. So, it is now at memory location 14.

And so on for each new item.

Memory location 14 is the trigger to reject an item labelled 1 (faulty).

 

However, if I add --|/|4-- to detect rings it automatically produces 1100 0000 0000 0000 - regardless of item type.

This is fine for rings and pegs.

BUT it doesn't work for assembled items - they are supposed to remain 0.

 

Looking at it in operation, it initially operates normally:

Scanner inputs 1 in location 15.

IP4 shifts 1 to location 14.

BUT the new rung then causes location 15 to become 1!!!!!!!!!!!!

If the subsequent items are supposed to be labelled 1 (peg or ring) this is ok.

BUT if it is an assembled item and is supposed to be labelled 0 = it doesn't work.

 

Agh!

Edited by Jamey

Share this post


Link to post
Share on other sites

Apologies. Clarification:

IP3 = Detects assembled items.

IP8 = Detects metal items (so detects pegs and assembled items)

(An assembled item is formed from combining a peg and a ring.)

That's why, because everything is now labelled 1,  a line of code was needed to erase the 1 from the Bit Shift Register and convert it to 0.

(I've now corrected the original post.)

Thankfully, this works.

Edited by Jamey

Share this post


Link to post
Share on other sites
Quote

It might help to draw a matrix listing the inputs down the left and the items to be detected across the top. Put a "1" or "0" in each field of the matrix. You can use that to identify the logic you need to detect each object.

I'm not sure how to do this because of the difference between HIGH and LOW states.

        Assembled Item | Peg | Ring

IP3             1                      0         0

IP8             1                      1         0

IP4             1                      1         1

[Corrected matrix after advice from Joe]

IP3 is set as HIGH; so to be detected, for an Assembled item, the logic state needs to change to 0?

IP8 is set as LOW; so to be detected, for a Peg, the logic state needs to change to 1?

IP4 is set as HIGH; so to be detected, for a Ring, the logic state needs to change to 0?

Edited by Jamey

Share this post


Link to post
Share on other sites

Put a "1" under each object that each input will detect and a "0" if it won't. If IP4 detects everything, IP3 only detects assemblies and IP8 only detects pegs, this is pretty straightforward to sort out.

 

 

Edited by Joe E.

Share this post


Link to post
Share on other sites

Matrix of inputs.

Assembled Item | Peg | Ring

IP3             1               0        0

IP8             1               1        0

IP4             1               1        1

Edited by Jamey

Share this post


Link to post
Share on other sites

Detecting Assembled Items and Pegs is not a problem.

Detecting Rings is a problem.

 

For the reasons outlined above, simply putting --| |4-- onto RUNG 1 doesn't work.

Share this post


Link to post
Share on other sites

So, in your logic, you can detect each part by exactly matching the states of ALL 3 inputs in each rung/branch. IOW, if all 3 inputs are ON, you have an assembled item. If IP4 is on AND the other 2 are OFF, you have a ring and NOT a peg or assembly. You have to check the state of all 3 inputs for each object.

Share this post


Link to post
Share on other sites
6 minutes ago, Joe E. said:

So, in your logic, you can detect each part by exactly matching the states of ALL 3 inputs in each rung/branch. IOW, if all 3 inputs are ON, you have an assembled item. If IP4 is on AND the other 2 are OFF, you have a ring and NOT a peg or assembly. You have to check the state of all 3 inputs for each object.

This Rung identifies Assembled items AND Pegs (but not rings).

1 hour ago, Jamey said:

RUNG 1

--------|/|3--------(Send Bit to BSR)

|-------|  |8--------|

So, if you change it to include --| |4-- you can detect rings.

1 hour ago, Jamey said:

--------|/|3--------(Send Bit to BSR)

|-------|  |8--------|

|-------|  |4--------|

HOWEVER, as explained above, the sequence in the Bit Shift Register is now incorrect.

I suspect it may be due to double counting - IP4 is now being used twice on different lines (a) to identify rings and input 1, and (b) to Bit Shift the bits in the register for each new item.

48 minutes ago, Jamey said:

For the unchanged rung, the IP3 OR IP8 input 1 into memory location 15, for example, 1000 0000 0000 0000

Then, IP4, when triggered, pushes it forward, so, 0100 0000 0000 0000. So, it is now at memory location 14.

And so on for each new item.

Memory location 14 is the trigger to reject an item labelled 1 (faulty).

 

However, if I add --|/|4-- to detect rings it automatically produces 1100 0000 0000 0000 - regardless of item type.

This is fine for rings and pegs.

BUT it doesn't work for assembled items - they are supposed to remain 0.

 

Looking at it in operation, it initially operates normally:

Scanner inputs 1 in location 15.

IP4 shifts 1 to location 14.

BUT the new rung then causes location 15 to become 1!!!!!!!!!!!!

If the subsequent items are supposed to be labelled 1 (peg or ring) this is ok.

BUT if it is an assembled item and is supposed to be labelled 0 = it doesn't work.

 

Edited by Jamey

Share this post


Link to post
Share on other sites

A pic of the code is clearer.

 

part 1.PNG

Share this post


Link to post
Share on other sites

IP4 is used twice for different purposes:

Rung 11 - to identify a Ring and input '1' into the register.

Rung 13 - to bit shift the items in the register, for example:

1000 0000 0000 0000 to 0100 0000 0000 0000.

Edited by Jamey

Share this post


Link to post
Share on other sites

You're right, it's a lot easier to see in the screenshot.

If rung 11 is intended to detect a ring, your conditions should be in series, not in parallel. That rung will be true if IP3 is OFF, OR IP8 is ON OR IP4 is OFF. I suspect that IP3 and IP4 will be off most of the time and only turn on when something shows up.

Instead, to detect a ring, you need IP3 to be OFF, AND IP4 to be ON, AND IP8 to be off.

IP8 is on only when a peg is present, so you can use it alone. Same with IP3 and assemblies. The only one you need all 3 sensors for is the ring.

Share this post


Link to post
Share on other sites

Rung 11 is intended to identify individually:

  • assembled items,
  • pegs, and
  • rings.

They all generate a 1.

1 triggers the rejection piston (OP3).

Because assembled items aren't supposed to be rejected (!) there is a line of code which changes their 1 to a 0 thereby avoiding rejection.

 

Share this post


Link to post
Share on other sites

Rung 11 does differentiate between all three item types.

However, it introduces errors into the Bit Shift Register.

Here, I discussed the operation of Rung 11 with and without IP4:

1 hour ago, Jamey said:

For the original rung 11 (without IP4), the IP3 or IP8 input 1 into memory location 15, for example, 1000 0000 0000 0000

Then, on rung 13, IP4 when triggered, pushes it forward, so, 0100 0000 0000 0000. So, it is now at memory location 14.

And so on for each new item.

Memory location 14 is the trigger to reject an item labelled 1 (faulty).

 

However, if I add --|/|4-- to detect rings it automatically produces 1100 0000 0000 0000 - regardless of item type.

This is fine for rings and pegs.

BUT it doesn't work for assembled items - they are supposed to remain 0.

 

Looking at it in operation, it initially operates normally:

Scanner inputs 1 in location 15.

IP4 shifts 1 to location 14.

BUT the new rung then causes location 15 to become 1!!!!!!!!!!!!

If the subsequent items are supposed to be labelled 1 (peg or ring) this is ok.

BUT if it is an assembled item and is supposed to be labelled 0 = it doesn't work.

 

Edited by Jamey

Share this post


Link to post
Share on other sites

The problem is:

Although, I can now identify and differentiate each type of item because I use IP4:

It introduces errors into the register (outlined in previous post).

Edited by Jamey

Share this post


Link to post
Share on other sites

I'm not sure how the shift register works in this software, so I didn't dig much into troubleshooting it. Are you tracking each of the 3 things (peg, ring, assembly) with its own register? If so:

If IP3 = 1, track an assembly
if IP8 = 1, track a peg
If IP4 = 1 AND IP3 and IP8 are BOTH 0, track a ring.

If you just need to track items to be rejected (lone pegs and lone rings, but not assemblies, right?) then it's even simpler. You would use IP4 AND NOT IP3 to set the reject bit in the register. This would set the bit to track anything that's not an assembly.

You can still trigger the shift with IP4 since it turns on for all of the items. Just be careful that you set the bit and shift the bits in the right order.

Share this post


Link to post
Share on other sites

1 = reject

0 = not reject

I've written the code to put the first scanned item in location 15 (MSB).

Then, when the item reaches IP4, rung 13 triggers a bit shift.

In this software, each bit shift trigger moves EVERYTHING in the register one position to the right.

 

Pics below.

 

This is for the code that only identifies assembled items and pegs.

It does NOT identify rings.

However, what it does identify is correctly recorded and ordered in the register.

 

Rung 11.PNG

BS 1.PNG

BS 2.PNG

BS 3.PNG

BS 4.PNG

Edited by Jamey

Share this post


Link to post
Share on other sites

In the above 4 pics, you can see the changes in the register.

pic 1. Register is 0000 0000 0000 0000. Nothing has been scanned and identified.

pic 2. Register is 1000 0000 0000 0000. Peg has been scanned and identified by IP8. Bit 1 is input into location 15 (MSB).

pic 3. Register is 0100 0000 0000 0000. Peg has been scanned by IP4. This SHIFTS all bits to the right (via Rung 13).

pic 4. Register is 0100 0000 0000 0000. Item rejected by piston OP3. No affect on register.

This is how it is supposed to work.

Edited by Jamey

Share this post


Link to post
Share on other sites

What is the device between IP3 and IP4? Is it a gate? Or a light barrier? How many parts could be in the system at a time?

 

Share this post


Link to post
Share on other sites

When I use the Rung 11 that identifies only assembled items and pegs - the register keeps an accurate record.

When I use the Rung 11 that identifies EVERYTHING by using IP4 - the register does NOT keep an accurate record.

In the latter case, I think there is double counting caused by using IP4 on two rungs (11 and 13).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0