Using Add-On Instructions vs FOR Loops

There are multiple ways to skin a cat, but obviously there are some differences between using making Add-Ons and using a FOR loop to jump though repetitious logic:

Add-Ons:

- Seems less "transparent"
- Seamless passing of input / output parameters
- Everything is bundled into the control structure
- Executed on a per instruction basis, and instantized

FOR Loops:

- Require logic to handle passing of parameters to each instance, and potentially the use of multiple UDTs.
- A little more "transparent"
- Execution of the FOR loop must complete in full (unless a Break instruction is encountered).


I'm wondering when would it be appropriate to use one over the other? What is considered a "best" practice, or does it really depend on the coding style / philosophy?

For example, in the past I've encountered code that uses a FOR loop to index through logic for over 100 valves (an element of a custom Valve UDT was used for each increment of the index). Each increment of the FOR loop was a different valve.

On the other hand, in the same program, the analog scaling routines were made into an Add-On instruction, and there was a ladder that had 50 to 100 instances of the Add-On in a row to handle each analog signal.

Are there any major advantages / disadvantages of one method over another? What about effects on scan time?

In something like a Motion Control application where scan time is a major concern, would one be preferable over another?

I'd be interested to hear thoughts on this...

Thanks.

The single benefit of being able to monitor and troubleshoot a single instance is enough to justify the loss in any potential scan time.

In reality, processors have gotten so fast and memory so large, does it really impact the scan time? Can you observe the difference?

Additionally, the AOI allows for us to validate the instruction and keep the source code revision history. Where elsewise it would not be controlled. But then again, I am in a regulated environment where this is of significant benefit.

I forgot about not being able to view a single instance with the FOR loops. Good point.

I came from BioPharma prior to my current job, so I am very familiar with change control, regulations, and not being able to make small changes on the fly.

Unfortunately the history of the site I was at was such that they backed themselves into a corner by using the FOR loops the way they did. They ended up making a copy of each routine in the FOR loop to jump to for troubleshooting, in order to view a single instance.

Major draw back was that they now has 2 places to which they had to make updates , and often the two routines had small differences. Also, the PID loop was indexed as well, and you cannot view the pop-up screen of indexed PID loops (needed to edit the rung and pop in the instance you wanted to configure).

As far as version control goes, they actually validated and qualified the subroutines, exported them to an L5K file, and kept it checked into AssetCentre, but I agree it is far easier to handle as an add on.

With as many FOR loops as were used, they did run into issues with scan times being too long in certain instances, particularly when they were doing a lot of messaging over DH+ and Ethernet. But perhaps there wouldn't have been much of a difference if they had used AOIs instead.

kdcui - i think you pretty much answered your own question.

Multiple calls to one subroutine, or using a FOR loop, was historically, and usually, done to save repetitive coding of identical blocks of rungs, and at the same time gave the advantage that the same code executed for each instance "call".

As pointed out, trouble-shooting one instance is a nightmare, the technique of making a separate block for trouble-shooting was widely used, but it did mean you had to make a program and/or a tag value edit to enable the diagnosis on to another instance.

However, if there is a fault with one device, for example one valve is constantly going into alarm, then in actual fact there is no need to look into the PLC code at all ! All diagnosis can be achieved by monitoring the I/O LEDs, because the problem will not be in the PLC, it will be external.

In many cases, edits of a processor are simply "not allowed".

The AOI deals with all the critiscisms of the function code subroutine scenario, is an elegant piece of engineering, and is a dream to use.

If required the source code (the logic) of the AOI can be protected, so that no-one can disturb a tested and proven instruction.

I say well done RA.

Yeah, I probably answered myself
I tend to do that....

However, I haven't used much of the innate abilities of AOIs to protect source code, enabled version control, etc... I was overlooking these aspects of AOIs.

AOI's typically execute faster then subroutines as well. Significantly so, when using reference (InOut) parameters and lots of data.