wnkook,
I certainly agree with the idea of programming in a "forward fashion". It is more natural to read forward in a listing to follow the process, plus there are other benefits, at least from a programmers' point of view.
The alternate method, to which you inferred, is what I call "Advance to the Rear". The idea behind the "Advance to the Rear" scheme is to ensure that down-line portions of the process are ready to accept material/input from up-line portions of the process. That is a good thing... however...
The programmer has to mentally synchronize actual material flow forward through the physical process while moving in reverse through the logical process.
That is, if you want to "see" material flowing through the program, you have to start at the end of the program and work your way back to the top... well, almost. The programmer has to remember to "finish the scan" before "Advancing to the Rear" to the next (previous) rung.
For example, if the program is currently processing material with Rung-50, at Station-6, and Rung-50 produces a signal for the next physical station, Station-7 (Rung-49 being the logical location associated with Station-7), then the programmer must "finish the scan", which might or might not involve changes in the status of other conditions, and then proceed, from the top of the ladder, to Rung-49, which, again, might or might not involve changes in the status of other conditions. Rung-49 then reacts to the flag from Rung-50 plus any other changes in conditions that have occurred.
The problem, of course, is that it becomes too tedious to go through the mental exercise of "finishing the scan" and re-running the scan into ladder. PLC's are great for doing tedious work... we are not.
The programmer will simply tend to move his eyes up one rung to the previous rung. However, having done so, the programmer will have ignored any and all other rungs that might have an influence on that rung. Upon examining the rung, the programmer will then have to "seek" the status for each condition.
On the other hand, if Station-7 is covered in the next rung, Rung-51, then the programmer can simply move down to that rung, carrying status with him knowing that all of the current status is, in fact, current. If there has been any change in the status of any condition, it occurred in Rung-50.
That's not to say that, with respect to the conditions examined in Rung-51, several conditions haven't changed since the last time Rung-51 was examined... but, all conditions are as they were upon entry into this particular ladder scan plus any changes that have been carried forward through the previous 50 rungs.
This means, when the programmer moves from Rung-50 to Rung-51, he has all of the latest status in-hand.
Any Alarm information that was developed in the previous scan is available immediately to all stations in the current scan.
Now, it might seem that it would be better to have Alarm information available to the previous station immediately... within the same scan. But then, that would mean developing the program using the "Advance to the Rear" method, which would, of course, precipitate the problems described above.
Demand-Side vs. Supply-Side
Too often, programs are written in a "Supply-Side" fashion. That is, an up-line station in the process shoves material down the throat of a down-line station in the process and says... "Here. Hope you can handle it!" While the down-line station is choking on the previous material, the up-line station continues to say "Here. Hope you can handle it!"
The "Demand-Side" method "CALLS" for material to be passed down-line. That is, a down-line station in the process has to explicitly "Call" for material from the previous station in the process. The down-line station "calls" only when it is ready to receive and handle material. If it's not ready, then a "call-flag" is not posted. If a particular station is not "calling" for material, then the previous station "holds" any material that it might have.
If properly co-ordinated, this method can produce a "controlled crash stop" when problems develop down-line. That is, when an up-line station "sees" that there is a problem down-line, the up-line station can perform a "controlled crash stop" into a "known good restart situation" - at least, with respect to the particular station. This precludes "clearing the system for restart". Certainly the station that has the jam, fault, whatever, has to be cleared, or fixed... but the rest of the system comes to an orderly stop which allows for an immediate restart as soon as the problem is resolved.
As far as providing information that identifies "point of failure"...
I'm a proponent for using "English" (or whatever your chosen language) to initiate, track and report on the current status, in each step, of each module, in the process. That includes explicit timed failures.
If an action hasn't occurred, as expected, when expected, then explicitly identify that particular problem.
For example, If "Run Motor-1" & NOT "Motor-1 AUX" for 2-Seconds, then latch "Motor-1 Faulted" until "Reset" or "Auto OFF" or whatever.
If a fault occurs, disable the system, in the appropriate manner, but maintain AUTO so as to allow viewing of all current alarms. Then at Auto OFF, reset all alarms. That will at least give operators or maintenance will have the opportunity to view the particular fault before they clear the problem area.
I generally use dedicated relay bits for tracking the various stages of a sub-process and the particular alarms associated with the process.
That is, I can certainly indicate the particular action the PLC is trying to perform at this location. If there is a problem, and if I can rationalize the cause of a particular problem then, I indicate that particular cause.
For example, Too Soon, Too Late, Not Loaded, Still Loaded, Not ON, Not OFF, etc.
IF there is enough input information for the PLC then, anything that I can rationalize, as a viewer of the process, can be rationalized by the processor.
After all, "we", as real observers, with our inherent input capability, can SEE everything... the PLC, however, might not be able to "SEE" everything. If there are not enough sensors to give POSITIVE indications to the PLC then, the least that can be done is, work with the idea of "I (the processor), based on previous activities, think such-n-such should have happened by now".
At the very least, you can make the PLC think what should be happening!