SLC 500 execution time suggestions

I've got a future project on a 537 rail system each rail uses 9 input and 4 output not including other I/O. This will end up being an extremely large program so scan cycles can become an issue. I've found several ways already to save on execution times such as uses extended loops instead of nested loops. Looking for other ideas on execution time savers. There is no specialy I/O modules and the app is all discrete I/O the only mathematics will involve counting per rail probably use indirect addressing for this to save on counters. Already have a copy of the SLC 500 reference manual and looking at different instructions and their execution lengths any other suggestions would be appreciated

one question I do have so far is whats the differents between false and true execution times?

Indirect addressing is expensive in terms of scan time. If scan time is a concern I would avoid indirect addressing.

All it takes is one false to make a branch false. As sooon as the logic engine determines that a branch is false it will stop evaluating other instructions. Think you logic through from that standpoint. Put the items most likely to be false to the left of a branch/rung. If, for example, you have 5 permissives that are usually true and one trigger condition, put the trigger to the left.

The CPT instruction is relatively expensive. If all you have to do is a simple operation, use the simple instruction.

Keith

your portion on the false is a strong consideration and I will definetely strive to do this looking at how the execution times work this certainly makes sense. One thing I should mention is no two rails will be operating at the same time in this the rails will be sequential. However memory to handle so many I/O points and keep track of how many products have been indexed on each rail may be more problems than its worth. I may simplify this by usage of a full rail switch rather than a count to save on the indirect addressing. I'm also considering panel view to reduce I/O counts this panel will eliminate the need for mechanical switches as to which rails are in service and can or cannot be used. However I will try to poll the panelview to PLC at a reduced rate

If you can group your I/O and rails so that you can look at an input card word to determine if a group of Rails is dormant and have that group in a subroutine that can be scanned or skipped according to the input configuration then you can make the program only scan the groups that are in use. Be sure to put in management to handle turning on/off outputs when the subroutine is being disabled.

I would set an active bit for the subroutine that goes false only when all outputs are properly handled in each subroutine.

I beleive that should be simple enough by placing the rail selector code on the left this will make the statement false following Kamenges advise. The grouping of the rails is also good advise as it not only aids in the scan times but also in the troubleshooting down the road. With the suggestions already provided its starting to sound like this will be easier to keep a good scan time that I first surmised

A corollary to kamenges' post above is: In a series of branches, place the conditions most likely to be TRUE in the top branch. The reason is that when the engine finds a true branch it 'knows' any remaining branches are irrelevant and skips them.