SI'm more of a watch you do it or we go through steps together type way.
Let's reverse it slightly, you do something and then post it here, say what you want it to do, what it actually does*, and if the two are different then why you think that is so, and ask for comments and suggestions.
TL;DR
* "The only thing worse than a program not doing what I want it to do is when it does exactly what I told it to do."
Because the first thing I as a learning programmer needs to fix in my mind with absolute certainty is that I have to get stupid, as stupid as the computer. Because it does not matter a whit what I
want the computer to do, it only matters what I
tell it to do. I have spent over forty years doing this and I have found only one compiler bug, and I was surprised when I found that one. Whenever the computer is not doing what I want, I always look at my code and think like the computer; sometimes it takes a few seconds, sometimes a few days, sometimes it takes a whole 'nuther project of debugging and monitoring code to what the bits are doing, but I have only once been disappointed with the assumption that the mistake was in my code.
Your preferred approach for learning is fine for this task, but there is not a back and forth in this forum format, so how are you going to write the next program?
What I can tell you is what I already said, that the pieces of the program compose a model for the pieces of the world it is modeling. If you are blocked by the whole problem, take a small piece of it, and code that up. Then take another piece and code that up. Sometimes one piece of code interacts with another piece, so the previous pieces needs to be modified, or perhaps even completely rewritten using a different approach.
E.g start a timer TON an input becomes 1: that can be done on one rung:
- your previous example shows you know how to do that,
- and parky has also given an example of that;
- don't worry about the duration of the TON
- and instead set it for five seconds,
- you can fix that later
Now that it's coded:
- run it on the PLC500 emulator,
- watch what happens to the bits of the TON instruction,
- compare what you see with the flow charts and descriptions in the logix 5000 manual; memorize every piece of that behavior (.TT, .EN, .DN, .ACC etc.), because it will never change.
I am not trying to be snarky or difficult here, but you aspire to become part of an industry that controls and moves heavy objects; it would be irresponsible of the folks on this forum to do the work for you.
Did you watch Ron's videos? Personally, I get such a feeling of peace and security every time he utters the phrase "look for a 1."
Another great and simple resource is
Patterns of Ladder Logic Programming; we all use those over and over.
And here is summat for nought. You showed some of your code from a previous exercise, and the first rung looked like this:
Would you be surprised that it could be coded a bit more simply:
N.B. It might be a bit better make the [OTE O:2/0] be the last branch, after the [XIC T4:0/DN MOV 2 N8:0] branch.
N.B. This assumes the rung 1 is the only rung that changes N7:0 from 1 to something else.
N.B. There are some subtle differences in edge cases, but for the bulk of operations the behavior of both rungs will be the same.
So, what was my first clue that that could be simplified? The ONS (One-shot instruction) feeding the OTL (latch) and CTU (count-up) instructions.
- A latch instruction does not need a one-shot in front of it; when the logic feeding the latch goes from false-to-true the output is assigned a 1, and that 1 stays there until another output removes it.
- A count-up instruction maintains it's own rising-edge detector (see the behavior of bit C5:0/CU in the CTU flow charts; it is equivalent to the B3:0/0 in your ONS).
).
