What I have been doing if I don't know the instruction is to read the actual Allen Bradley reference manual it explains everything. Also if you are completely lost do the logixpro exercises. All you need to know about sub routines, is that is just a way to keep the program organized. B3 internal relays, and N7 holds an integer value. If I don't understand a concept I search this website for threads with the same topic. Then when I think I understood the topic I tried to write a small program in logixpro, don't be afraid to burn that batch mixer motor or flood the screen
Please help me!!!
- Thread starter twilightfan9337
- Start date
twilightfan9337
Member
OP
I have been working on this a lot and here is where i'm at. It looks right to me but still the very first line will not work. When i press the start button it will not fill and i'm am not sure why. (i have most of it in lad 2 and once it is working will move things into their subroutines). also im not sure if the custom display and entering value will work when it gets to that part. Please help with these problems and if u see anything else wrong. thanks!
Changed the stop to XIC. That should get you started and latch the output.
Rung 0 and rung 21 are using the same Output address O:2/1. This is normally not allowed and is called double-coil syndrome. Rung 21 will overrule whatever is happening in rung 0. I would just delete rung 21 temporarily to test. The timer bits in rung 11 should use the /TT bit to go true when the timer is timing. Once you get rung 0 straightened out you will need to turn off the fill pump with the counter that sets the level. There's more but this should help.
Last edited:
I would suggest designing a flowchart of your process first, is easier to write a program once you have a clear mind of what, and when is suppose to happen. It will also help in keeping the program organized, keep a list of all I/O that way you don't run into duplicating outputs.
http://logicnet.dk/DiagramDesigner/
An actual washer machine you can stop at any time.
http://logicnet.dk/DiagramDesigner/
An actual washer machine you can stop at any time.
Last edited:
Twilightfan,
I am looking at your last program, "Final 2", and here are some comments on the obvious errors:
Each rung should have a comment and each bit should have its symbol labeled.
You did not follow this instruction. You did not add comments to each rung that explain what that rung is supposed to do. This is a basic common student mistake (write the logic first, then try to figure out how it works!) If you do not know what the rung does, it is unllikely that you will accidentlly make it work.
In this program, latch bits were used as flags to mark the cycle.
You should use "flags" for each step: FILL, AGITATE, DRAIN. These will help you to stay organized and avoid another common error (duplicate outputs).
Remember, do not duplicate outputs.
You have used duplicate outputs. You need to figure out a way to avoid that. A common method is to use substitue relays in subroutines, then use those relays in parallel branches to control your ONE-time occurance of each pump and agitatior output.
I am looking at your last program, "Final 2", and here are some comments on the obvious errors:
Each rung should have a comment and each bit should have its symbol labeled.
You did not follow this instruction. You did not add comments to each rung that explain what that rung is supposed to do. This is a basic common student mistake (write the logic first, then try to figure out how it works!) If you do not know what the rung does, it is unllikely that you will accidentlly make it work.
In this program, latch bits were used as flags to mark the cycle.
You should use "flags" for each step: FILL, AGITATE, DRAIN. These will help you to stay organized and avoid another common error (duplicate outputs).
Remember, do not duplicate outputs.
You have used duplicate outputs. You need to figure out a way to avoid that. A common method is to use substitue relays in subroutines, then use those relays in parallel branches to control your ONE-time occurance of each pump and agitatior output.
Last edited:
simple method I seem to repeat...........
OK, I will tell how I would suggest that you write the program.
1 Setup the hardware config. Take all the inputs and outputs and assign them a variable name and label or tag or whatever it is called in your software.
2 Once all the I/O is defined, then begin with a simple block diagram of the machine function. I usually see this in my head while I read the spec, some people are fanatics about making this a flow chart or drawing pictures. Whatever method works for you. Determine the general type of program you want to use. Some but not all processes work well as a state machine, some processes are horrible in a state machine. I met one person who forced everything into a state machine format. Decide now.
3 Break the big machine into small sections.
Put clothes in, add water and detergent, rotate, drain, spin, add water, rotate, drain, spin, remove clothes.
You also have a small , medium and large load size. Write a simple program that only runs a small load. Then look at what is different to run a medium and large load. Guess what? A lot of the small load stuff can be used in the other load sizes , sometimes with minor changes, sometimes with no changes.
In Step7 I look at all the machine functions and when I see a common set of repeated actions, I make those into reusable function blocks, in AB I would do the same with subroutines.
4 Make a simple program for each load size that works. Then move the logic of each into the same program. (or just write a new one) This will require some editing to avoid the multi coil issue and you could use subroutines.
Subroutines are nice and clean, but if you condition the whole subroutine with a bit(like I know you will want to), be aware that nothing in the subroutine is updated if the subroutine is not called. Anything left on, will stay on.
There will also be common logic that may be duplicated in each. You will see this because you just did it three times. Drain is drain, doesn't matter what the size load is. Drain until the water is gone. Or if you do not have a level sensor, drain for some time. You can use a different time for each load size, I would not. Use a time that will drain the load with the most water, add some to it and use that for all loads. It is not critical. Fill will also be similar. When to stop filling could be different for each load, but it could be level related.
If you have a level then the load size doesn't matter. Adding detergent and other things will also be similar and will not need to be repeated in each load size.
5 Debug, reduce, see what you can delete out or simplify without losing functionality. ( most people I have worked with skip this step )
6 Write a good comment for each section, most people enjoy a small comment on each line or rung, and a big comment for each idea or section of code.
I don't generally comment heavily until I know the code works. No sense wasting time documenting something I delete 2 days later. Simple comments during development, as much comments as you can before it ships.
7 Add additional documentation to the project for a big picture over all view, either in a separate text file or in the beginning or end of the program, just in case someone has no idea what this thing is supposed to do.
8 Try to make it not work. Push small and large selections at the same time, or push all 3 load sizes before the cycle has completed. Try to trick the machine into failure mode.( most people I have worked with skip this step )
9 Read the whole thing from start to finish and see if anything looks out of place. This is just a quick proof read.
As for what all this "means", you need a good book / PDF/ website and some time to comprehend what you have read.
there are a bunch of references on the web........Google it.
You need to understand simple data types: boolean, integer, float, string. How are they different, how are they used in compares and math blocks, etc.
PLCs are really simple if you approach it with a calm mind. (except maybe Step7, it helps to be a little insane to begin with there)
The PLC is, at its core, a box of relays. You can open one and see the relays if you like. Some use transistors but it is very similar. Some have analog in and out, which is just a way to reduce some non binary event to a number.
Analog input connected to a level indicator gives you a number for how full a tank is.
Analog out connected to a motor drive will convert your analog output number into some motor speed.
A switch input will make a boolean bit a one or zero.
A boolean output will change the on off state of some device like a light.
It sounds like your web course is not providing you with the level of training you need. You may need more instruction or consider a more interesting career path that suits your personality and capabilities. This is not for everyone, it can be tedious at times.
If you enjoy puzzles and logic games and machines, this is a good career for you. If you don't get math, logic and how stuff works, maybe it is not for you.
I say this because sometimes people get stuck thinking they have to do something. You don't have to do this. Maybe something else would be less stressful and more rewarding?
OK, I will tell how I would suggest that you write the program.
1 Setup the hardware config. Take all the inputs and outputs and assign them a variable name and label or tag or whatever it is called in your software.
2 Once all the I/O is defined, then begin with a simple block diagram of the machine function. I usually see this in my head while I read the spec, some people are fanatics about making this a flow chart or drawing pictures. Whatever method works for you. Determine the general type of program you want to use. Some but not all processes work well as a state machine, some processes are horrible in a state machine. I met one person who forced everything into a state machine format. Decide now.
3 Break the big machine into small sections.
Put clothes in, add water and detergent, rotate, drain, spin, add water, rotate, drain, spin, remove clothes.
You also have a small , medium and large load size. Write a simple program that only runs a small load. Then look at what is different to run a medium and large load. Guess what? A lot of the small load stuff can be used in the other load sizes , sometimes with minor changes, sometimes with no changes.
In Step7 I look at all the machine functions and when I see a common set of repeated actions, I make those into reusable function blocks, in AB I would do the same with subroutines.
4 Make a simple program for each load size that works. Then move the logic of each into the same program. (or just write a new one) This will require some editing to avoid the multi coil issue and you could use subroutines.
Subroutines are nice and clean, but if you condition the whole subroutine with a bit(like I know you will want to), be aware that nothing in the subroutine is updated if the subroutine is not called. Anything left on, will stay on.
There will also be common logic that may be duplicated in each. You will see this because you just did it three times. Drain is drain, doesn't matter what the size load is. Drain until the water is gone. Or if you do not have a level sensor, drain for some time. You can use a different time for each load size, I would not. Use a time that will drain the load with the most water, add some to it and use that for all loads. It is not critical. Fill will also be similar. When to stop filling could be different for each load, but it could be level related.
If you have a level then the load size doesn't matter. Adding detergent and other things will also be similar and will not need to be repeated in each load size.
5 Debug, reduce, see what you can delete out or simplify without losing functionality. ( most people I have worked with skip this step )
6 Write a good comment for each section, most people enjoy a small comment on each line or rung, and a big comment for each idea or section of code.
I don't generally comment heavily until I know the code works. No sense wasting time documenting something I delete 2 days later. Simple comments during development, as much comments as you can before it ships.
7 Add additional documentation to the project for a big picture over all view, either in a separate text file or in the beginning or end of the program, just in case someone has no idea what this thing is supposed to do.
8 Try to make it not work. Push small and large selections at the same time, or push all 3 load sizes before the cycle has completed. Try to trick the machine into failure mode.( most people I have worked with skip this step )
9 Read the whole thing from start to finish and see if anything looks out of place. This is just a quick proof read.
As for what all this "means", you need a good book / PDF/ website and some time to comprehend what you have read.
there are a bunch of references on the web........Google it.
You need to understand simple data types: boolean, integer, float, string. How are they different, how are they used in compares and math blocks, etc.
PLCs are really simple if you approach it with a calm mind. (except maybe Step7, it helps to be a little insane to begin with there)
The PLC is, at its core, a box of relays. You can open one and see the relays if you like. Some use transistors but it is very similar. Some have analog in and out, which is just a way to reduce some non binary event to a number.
Analog input connected to a level indicator gives you a number for how full a tank is.
Analog out connected to a motor drive will convert your analog output number into some motor speed.
A switch input will make a boolean bit a one or zero.
A boolean output will change the on off state of some device like a light.
It sounds like your web course is not providing you with the level of training you need. You may need more instruction or consider a more interesting career path that suits your personality and capabilities. This is not for everyone, it can be tedious at times.
If you enjoy puzzles and logic games and machines, this is a good career for you. If you don't get math, logic and how stuff works, maybe it is not for you.
I say this because sometimes people get stuck thinking they have to do something. You don't have to do this. Maybe something else would be less stressful and more rewarding?
Yes, well, if you know how it is supposed to work, you don't have to worry about IF it will work. Not having a clear idea of how it SHOULD work is the major problem for students, and even more experienced new guys. If you cannot write a clear description in a rung comment, you have fairly well screwed yourself and then you will have to redo a bunch of rungs 2 days later. I recommend that students start with the rung comment, then make the rung action match what the comment says.
The other method is to place the cart before the horse, throw in some vague and uncertain logic, and hope it runs okay, then change it 2 days later when you see you are not getting anywhere! Without a clear direction, you are just screwing around hoping to hit on the right solution (out of infinite possibilities).
Anyway, it really doesn't matter what you and I think about rung comments. If Twilightfan wants to graduate, this is the instructor's requiremnt:
From reading this, I don't think you realize the situation.
The student must use an exisiting LogixPro simulator set-up (created for an entirely different batch mixing problem) to simulate a washing machine. All the possible cycles are predefined and cannot be changed by the instructor or the student (if they use this particular simulator). There is no spin cycle, for example. There are fill, mix, and drain steps, normally used in the LogixPro Batch Mix Student Exercise to pump two measured recipe ingredients into a tank, heat and mix them, then pump out the resulting batch. All the inputs, outputs, level switches, selector switches, operator controls, and indicator lights are pre-defined.
This exercise is simply using the exisiting Batch-Mix structure to loosely define a washing machine, and it has severe limitations on how the program logic can be structured. For anyone to help twilightfan very much, you will have to first learn the LogixPro Batch Mix exercise.
Last edited:
oh geez........when will the universal translator get built?
Oh Lancie Lancie Lancie.........we are not in a classroom out here.
It seems that I have failed to arrange my words in such a way as to eliminate the possibility that someone might misunderstand my intended communication.
I will lay out a common scenario that happens to me so you can tell me where I am going wrong.
Step1 receive and read spec.
Step2 inspect hardware chosen by someone else that is supposed to be sufficient to accomplish the task, and of course has the lowest cost.
Step3 think about how to make the hardware do what the spec requests.
Step4 identify problem areas and ask for clarification from designer and customer. Because, you know, I just don't get it.
Step5 begin writing software following the steps I outlined above(see previous post).
Step6 the spec changes, designer discovers some error / edit / revision, etc...
Subroutine "corrective action"
At this point, I delete the work I have just spent a week or more on (including all those spiffy comments) and start that section over with the revised spec.
Step7 I get to a point where I discover that the machine, as defined, will not do some bit or it is just barely able to fulfill the spec most of the time.
Call a meeting, push some words around, force management to make a decision, then push for the solution to be ordered sooner , then push for information, then push for the new design update, then guess what..........
call "corrective action"
This can even happen more than once on a line.
Ok now all is well and you can even stay on schedule by changing your end of day to 9pm.
Step8 The customer submits a change order........oh boy.
call "corrective action"
This can continue for some time.
See where this is going?
Now following a "comment everything upfront" method ,I would have used a lot of time commenting everything for nothing.
Now to be clear, it sounds like my minimal comment would satisfy your idea of a starting point comment, so we could be having an argugreement on that point.
When I go back and comment after everything is working, I am referring to comments that do more than just read the logic in English.
That to me is a DUH comment.
What I add is "why" this is being done and sometimes I find it helpful to add where the data originates, and where it goes, which can not always be found with a search function. I also explain any indirect addressing or other information that might make it easier for someone else to see exactly what is happening in a few minutes.
Because I have spent weeks decoding PLC programs written by
"psuedo-commenters" who think a simple rung description is enough. Or even better no comment at all.
Now if you spend most of your career programing conveyors and waste water systems, this all sounds rather excessive.
Sure I can read the spec and write a comment and then write a rung of logic, is that enough? not really. Is it always that simple? rarely. Will it all change in a few days? most likely.
No that's the major problem for everyone.
Some machines are sufficiently complex that the true function in exhaustive detail is revealed when the implementation of what the customer thought they were asking for meets the hardware that the designer thinks should do what he understands the customer to want.
The machine isn't done until it runs in production for a couple of months.
At THAT point the drawings can be finalized, the spec can be revised to reflect the true condition of the machine, and the final comments can be written with accurate detail.But by then no one is even paying attention.
Anyone who doubts the previous statment is not aware of the full cycle.
In a class room, you are dealing with a very simple version of a limited reality.
In a classroom:
We have a conveyor with 3 boxes and PLC X with Y outputs. This same hardware has been used for several classes and we have developed our project questions to address this hardware. (what can I do with this hardware?)
There is a definite solution to each challenge and all variables are known and accounted for. Nothing will be added or removed. The question will not change during the test. The due date will not change. You will not be pulled off of this project and put on something else twice in the next couple of weeks.
If it works that way in your world, you are missing all the fun.
And Lancie, really, stow the angry old man condescension.
Oh Lancie Lancie Lancie.........we are not in a classroom out here.
It seems that I have failed to arrange my words in such a way as to eliminate the possibility that someone might misunderstand my intended communication.
I will lay out a common scenario that happens to me so you can tell me where I am going wrong.
Step1 receive and read spec.
Step2 inspect hardware chosen by someone else that is supposed to be sufficient to accomplish the task, and of course has the lowest cost.
Step3 think about how to make the hardware do what the spec requests.
Step4 identify problem areas and ask for clarification from designer and customer. Because, you know, I just don't get it.
Step5 begin writing software following the steps I outlined above(see previous post).
Step6 the spec changes, designer discovers some error / edit / revision, etc...
Subroutine "corrective action"
At this point, I delete the work I have just spent a week or more on (including all those spiffy comments) and start that section over with the revised spec.
Step7 I get to a point where I discover that the machine, as defined, will not do some bit or it is just barely able to fulfill the spec most of the time.
Call a meeting, push some words around, force management to make a decision, then push for the solution to be ordered sooner , then push for information, then push for the new design update, then guess what..........
call "corrective action"
This can even happen more than once on a line.
Ok now all is well and you can even stay on schedule by changing your end of day to 9pm.
Step8 The customer submits a change order........oh boy.
call "corrective action"
This can continue for some time.
See where this is going?
Now following a "comment everything upfront" method ,I would have used a lot of time commenting everything for nothing.
Now to be clear, it sounds like my minimal comment would satisfy your idea of a starting point comment, so we could be having an argugreement on that point.
When I go back and comment after everything is working, I am referring to comments that do more than just read the logic in English.
That to me is a DUH comment.
What I add is "why" this is being done and sometimes I find it helpful to add where the data originates, and where it goes, which can not always be found with a search function. I also explain any indirect addressing or other information that might make it easier for someone else to see exactly what is happening in a few minutes.
Because I have spent weeks decoding PLC programs written by
"psuedo-commenters" who think a simple rung description is enough. Or even better no comment at all.
Now if you spend most of your career programing conveyors and waste water systems, this all sounds rather excessive.
Sure I can read the spec and write a comment and then write a rung of logic, is that enough? not really. Is it always that simple? rarely. Will it all change in a few days? most likely.
No that's the major problem for everyone.
Some machines are sufficiently complex that the true function in exhaustive detail is revealed when the implementation of what the customer thought they were asking for meets the hardware that the designer thinks should do what he understands the customer to want.
The machine isn't done until it runs in production for a couple of months.
At THAT point the drawings can be finalized, the spec can be revised to reflect the true condition of the machine, and the final comments can be written with accurate detail.But by then no one is even paying attention.
Anyone who doubts the previous statment is not aware of the full cycle.
In a class room, you are dealing with a very simple version of a limited reality.
In a classroom:
We have a conveyor with 3 boxes and PLC X with Y outputs. This same hardware has been used for several classes and we have developed our project questions to address this hardware. (what can I do with this hardware?)
There is a definite solution to each challenge and all variables are known and accounted for. Nothing will be added or removed. The question will not change during the test. The due date will not change. You will not be pulled off of this project and put on something else twice in the next couple of weeks.
If it works that way in your world, you are missing all the fun.
And Lancie, really, stow the angry old man condescension.
Twilightfans are people too.
No need to be the old guy unmasked at the end of Scooby Doo.
"From reading this, I don't think you realize the situation."
I get it, what you missed was most of my point. I was generalizing the functions to explain a method of work not trying to solve his class work specifically.
"For anyone to help twilightfan very much, you will have to first learn the LogixPro Batch Mix exercise."
Nope, not true. I was attempting to shed some light on the general process of writing code for any machine with any PLC. I was intentionally NOT being specific.
I am not trying to help him DO the project. I was attempting to lay out an approach that he could use to address his project from a less intimidating perspective.
You seem to be stuck on the task at hand, that is his problem to solve.
I am addressing the greater issue of HOW to solve the problem and any other problem.
No need to be the old guy unmasked at the end of Scooby Doo.
"From reading this, I don't think you realize the situation."
I get it, what you missed was most of my point. I was generalizing the functions to explain a method of work not trying to solve his class work specifically.
"For anyone to help twilightfan very much, you will have to first learn the LogixPro Batch Mix exercise."
Nope, not true. I was attempting to shed some light on the general process of writing code for any machine with any PLC. I was intentionally NOT being specific.
I am not trying to help him DO the project. I was attempting to lay out an approach that he could use to address his project from a less intimidating perspective.
You seem to be stuck on the task at hand, that is his problem to solve.
I am addressing the greater issue of HOW to solve the problem and any other problem.
I am an old man, but what made you think that I was angry? Not at all! When I get angry, I stay off this site. Still, I have the right to express my opinion. If you don't like it, you do not have to read it.
I am not and you must not be either, but the person requesting help said that he was. How you going to help him solve class problems by applying industrial methods?
Last edited:
Similar Topics
please help me . I have to make this ladder diagram and I can’t figure it out :(
HOW to communicate with OPTIX and Mitsubishi's Q Series PLC?? PLEASE HELP ME
Hello,
I am trying to get a Yokogawa Hart pressure Transmitter and a Rosemount Temp Transmitter to read on a 1769-IF4 module on an L33ERM...
Please help me, I have solve many week but still not solve it.
I found trouble of factory talk studio when I set tag by browse address of OPC...
Hello Everyone, i Have im my Industry a Endress & Hauser Promag400
this has a screen that constantly have that error, it says to wait, somebody...
