With apologies in advance for offering “more-than-you-ever-wanted-to-know-about-flashers” - I’ll stick in my opinion. (Why kill when you can overkill?) Some of this got pre-posted while I was typing – so extra apologies to Kim Gold and to Operaghost for reiterating some of their ideas.
John, May I suggest that you stick with the SECOND construction of your "flasher" - and look where it can lead you ...
Suppose that someday the boss wants to collect some data every XXX seconds. Use your first rung (second example) and all you have to do is adjust the timer's preset to set up the required period. Then use the timer's done bit on a separate rung to "trigger" the data collection. In other words, the construction you have shown for your first rung, is a text-book example of a TRIGGER for a "repetitious cycle". There are many, many, many uses for this. And if you came up with this solution on your own, congratulations are certainly in order.
The second rung is good - but would be a little better if you were to delete the enable bit contact. (As per Kim Gold). This contact is superfluous - a fancy word for "it doesn't buy you anything". But hold on, don't take my word for it - let's use it as a learning exercise. Modify the rung by adding an unconditional branch right around the enable bit contact. That's the ladder logic equivalent of an electrician's "hot wire - jumper it out" test connection. Now retry the operation of your flasher. If it works just as well (with the branch), then you'll have PROVEN that the contact is indeed superfluous (and more importantly, possibly learned a useful troubleshooting technique in the process). You can now delete the superfluous contact and the branch with confidence. Some programmers leave the "jumper branch" in their programs for days or weeks - just to make sure that something they THINK is extra - actually is. Later they come back and clean up by deleting the extra junk and their "test jumpers". On the other hand, if the test proves that they were wrong, they can easily put the questionable contacts back in service by simply deleting the "jumper" branch. This, of course, is much easier and quicker than re-entering a bunch of deleted contacts.
Next, why did you use a LESS THAN comparison rather than a GREATER THAN the way most students do? Just luck or sheer genius? Think about this: instead of entering the constant value 50 for Source B, suppose that you entered N7:0 for a VARIABLE location. Now enter 50 into N7:0 and you've got exactly the same flashing pattern as before. But watch what happens when you put 20 into N7:0. Now your flashing bit is 20% ON and 80% OFF. Try putting 80 in N7:0. Now you've got 80% ON and 20% OFF. That's why I personally like the LESS THAN approach. With the GREATER THAN I have to "invert" the value I enter - in other words, for 10% on, I have to enter 90 at N7:0. I like the straight-forward advantage of the LESS THAN for my flashers. (OG obviously has me beat in the math arena).
Next lesson: Let's suppose that you have an electric range at home - as opposed to a gas one. Let's further suppose that to increase or decrease the heat for a pot of beans, you turn a knob - as opposed to pushing a series of buttons. Most modern ranges work this way. Now set the heat to about halfway and put your ear close to the knob. That click....click....click.... that you hear is a "time proportional signal" generated by the burner switch. Set a different heat and you'll hear a different pattern - for example: ............click..click..........click..click............click..click....... The switch is just turning the heating element off and on in different PROPORTIONS of time. See where I'm going with this? Replace your flashing lamp bulb with the heating element on your range. Now the PLC can control the temperature of your pot of beans just by varying the value in N7:0. In another lesson we'll find out how to scale the output of a PID block from 0 to 100 and aim it at N7:0. Hook up a thermocouple as a temperature input to the PLC and we'll be ready to control the temperature of the pot of beans in fine style. And your excellent "flashing lamp" solution is an integral part of that.
Next lesson: suppose that we need an alarm light for a "boiler pressure too high" condition. You COULD just turn the light ON for an alarm - or even flash it when the pressure gets too high. But how about this? Mathematically scale the pressure signal and send it to N7:0. Now the operator can look at the flashing pattern of the alarm lamp (a LITTLE BIT on - or a WHOLE LOT on, etc.) - and get a fair idea of just HOW MUCH too high the pressure has become. True, the scaling part of this might be a lesson for another day - but the "flashing lamp" exercise will come in very handy down the road.
The scariest part of all this is: most people just "figure it out" on their own - usually using two timers - and go away happy with a "flashing lamp". There's a lot more educational juice hidden in most of these little "beginner" exercises. I commend you on having squeezed this one beyond what the rep told you "had" to do.
Want more flasher fun? Investigate bits S:42/0 or S:42/1, etc. How about T4:0.ACC/4, etc.? How about S:4/4, etc.? Suppose that for our "boiler pressure too high" flashing lamp exercise above, we want the lamp to stay COMPLETELY on when N7:0 reaches 100. Specifically, absolutely NO FLICKER is acceptable.
Offline until Tuesday – a safe and enjoyable Labor Day to all -