ladder progam

need help with the attached assignment a few pointers

Post your go at the logic and you will get plenty of help....

We prefer to help learn.. ask your questions so we may help guide you with the pointers you seek. Unless you ask we don't know what you are looking for or where your knowledge limits are.

Looks like my trainer https://www.plccable.com/miniature-...-detection-electrical-training-allen-bradley/

Tim's videos may help you... https://www.youtube.com/playlist?list=PLUi5cdVq3wTD2xI3KgtmjTDpourWwxYP5

Try making a program and someone here will tell you what you did wrong... odds are they will not tell you what you have done right but if it works its right

For any given homework assignment or task at work, you must consider these instructions as the customers specifications.
1. read the specifications several times.
2. write down your understanding of what you read in a step by step fashion.
3. review what you wrote down and see if it makes since, modify if necessary.
4. Get with the mechanical designer and discuss the project openly and honestly. When your opinions differ in regards to an operation, discuss it, don't ignore it.
there must be a reason for a difference of opinion. modify your instructions and i/o to accomodate the mechanical design if necessary.
YOU BOTH MUST be in agreement on all points of operation before going to step 4.
5. step through your notes again this time, you are the one following the instructions. In other words, you are the plc. Write down on paper the events you are doing.
For example, turn on hydraulic motor 1, write down hydraulic motor 1 on. If a sensor is needed, write that down.
6. continue through the instructions. When you turn off the motor, mark a line thru it.
7. go through your instructions with all the sensors, motor aux. contacts, outputs documented. Modify if necessary.
8. repeat step 6 until no changes are made.
9. Try to group your data words into some organized fashion. The more programs you write, the more organized you become
10. write the plc program using your notes in a step by step manner.
10A Over half way through writing the program you WILL realize a different/better way of doing something you are almost done writing
(or a new spec will require it) and you will completely rewrite it
10B It WILL happen more than once.
Note: 10A and 10B aded to list. thanks Aabeck, member plcs.net forum

11. DOCUMENT EVERYTHING!!! You may remember things today, but in 5 years and hundreds of programs later, you won't
remember, especially at 2 am, so DOCUMENT EVERYTHING. use easy to understand tags and rung comments.
12. MAINTENANCE is your best friend and your worst enemy.
if you work with them and find out what they can do, write the program where they can trouble shoot the program. they will be able to fix the problem and everyone will be happy.
BUT
if you write the program to where you are the only one who understands what is going on, maintenance can't fix the issue, the machine is down, production is down,
management hears about it, your boss hears about it, then you hear about it - rewrite the program or else. you get calls all hours of the day and night.
this still holds true, a machine can cost a billion dollars, but it's not worth 10 cents if maintenance cannot trouble shoot the issue and fix the issue.
everyone has their own style of programming and you must develop your own way as well.

13. when the customer is in your shop and brings maintenance, discuss thngs with them, let them see your code, be open.
if they make suggestions, write them down, don't ignore them. their ideas may save you days of programming.

14. install the program and leave in program mode if possible so you can to debug your i/o
15. when writing your instruction manual(s), use your notes from step 9. Use easy to understand English language. specify the i/o, timers, counters, outputs when possible.
this will help maintenance even more to see what is going on.
16. Question for you, when is a machine and plc the most dangerous and why?
When it’s first powered on – when power is first applied to a machine, you don’t know how things are wired.
When you energize the plc outputs, you don’t know how they are wired.
When the plc is put into run mode the first time, it will do what you told it to do, NOT what you wanted it to do.
17. debug the program.
Remember, the program will always do what you told it to do, NOT what you wanted it to do.
18. IF you can ask a what if this happens type of question, YOU MUST have an answer, EVEN IF its a 1 in a million change.
that what if situation will happen in the first 30 minutes of production runoff in front of the customer.

this is the best advice I can give anyone.
if others has more / better suggestions, feel free to post
James

To get started, develop a Start/Stop control for the conveyor motor.

This is remarkably similar to the project I did in third term of trade school. (1992). Follow James' guide. Lay out a sequence of events. Break the logic into smaller sections - motor on when? motor off when? cylinder extends when? cylinder retracts when? If your this far along in your training, I'm sure you can do it. It can seem a little overwhelming at first. But aas I say, divide it into separate sections then knit them together. Show us what you come up with...there are great teachers on this site...they won't do your homework for you, but are glad to assess and provide pointers when needed...

James Mcquade said:

...
10. write the plc program using your notes in a step by step manner.
10A Over half way through writing the program you WILL realize a different/better way of doing something you are almost done writing
(or a new spec will require it) and you will completely rewrite it
10B It WILL happen more than once.
...

Click to expand...

It is incredibly useful to think in this manner as suggested by JamesM: it is one of the essential pieces, specifically humility, of an "agile" approach.

Another aspect of this is that, when faced with an overwhelming task and perhaps being frozen not knowing where to start, you are free to instead solve a single piece of the problem at a time, knowing that nothing is set in stone down the road. Then you solve another piece, and another, and then you start connecting them, etc. I often don't know I am done until I ask myself "what's next" and the answer is "nothing." If one piece won't work with another, then it's only a small change to try a different approach for one or both pieces.

For example, from the problem statement, there will be a period of time, call it "pushing now," when all the steps are focused on pushing a labelled box into the chute. Calculating and having a bit that is 0 outside that period and is 1 during that period might be useful. E.g. when it is 0, the conveyor motor can run and the cylinder is inactive, and when it is 1 the motor should be stopped and the cylinder sequence can be followed.

• that period is triggered (STARTed) by the photocell reading a label, which changes an input (call it LABEL_FOUND) from 0 to 1;
• that period is completed (STOPed) when the cylinder completes its retraction, which changes another input (call it RETRACTED) from 0 to 1;
• sometime during that period, well before it completes, the label will be pushed out of view of the photocell and input LABEL_FOUND, which started the period, will change from 1 back to 0, but you will still want the steps in that period to continue.
• These events suggest something like the Start-Stop pattern, with LABEL_FOUND as the Start contact and RETRACTED as Stop contact; the seal-in contact of the output bit will maintain the output bit as 1 even after the label leaves the field of view of the photocell.
• However, at the start of the period, the RETRACTED bit will initially be 1, which means it must somehow stop the period when it is 1 at the end, but not keep the period from starting when it is 1 at the start. So the raw RETRACTED input cannot be the Stop contact.

That is a typical thought process; the point is to keep poking around solving the small problems. In the end there may be better ways to signify "pushing now," but following that thought process, and seeing its weakness*, makes it easier to either to add some logic that eliminates the weakness of that approach, or to think of an alternate approach that accomplishes the same thing. Whatever approach you take, the problem of when to run the motor and when to turn it off will be solved, and you will be closer to the end of the task than when you started.



* RETRACTED needs to be ignored at the start and noticed at the end




P.S. Note that JamesM's point 5 also fits into this incremental approach: write down the sensors as the need arises; the problem statement asks for a list of these, but until you know your approach and have thought about the process, you will not, even CAN not, know what sensors are needed.

I think I'm only re-iterating what has been already said.
First configure your I/O for example you have x number of inputs for push buttons, sensors, solenoids, motor(s), lamps.
Give them symbols like Start_Button, Stop_Button, Pusher_Fwd_Sensor Conveyor_Motor etc. or what ever makes sense for the symbols of the I/O.
What ones need to be N/O or N/C as an input i.e. is it on when not covered or energised or is it off.
Write down the steps required to run this for example the conveyor will run when the start button is pressed, the pusher is in the retract position and stop when stop button pressed or when x boxes have been diverted (you may want to add some error checking for example if the pusher did not retract when told to, stop the system.
The pusher will be activated when certain conditions are met (this is your logic to control the pusher).
Also any internal bits used ensure you give them Symbols (names) not just the actual addresses. Comment rungs of code explaining what they do.
Good luck.