[PLC Scan Time (Enhanced Family)]

I haven't done any relative comparison. However, the programmer who triggered this post has generously provided the following feedback:

So the screen does affect scan time, but this suggests it relates more to the number of variables rather than the size of the screen. 4ms still looks pretty good for any general purpose PLC task.

Simon,

That is really great information to know. I would not have expected it to affect scan time to that degree. As you pointed out, most projects don't require a super fast scan time, so I hardly ever notice.

Thanks for the info!

Damian

[PLC Scan Time (Enhanced Family)]

Hi Simon,

One other trick to measure the scan time is to use the Interval function backards. If you Put the Interval End function in a subroutine that is scanned once every PLC update, and the Interval Start function just after that, it will include the entire scan time. If you want it to exclude the time spent executing ladder code, just put the End in the very first network, and the Start as the very last block executed.

Have you come up with any numbers regarding the speed of the V570 VS the V1040/V1210? I am curcious if the V1040 or V1210 might in fact run a bit slower than the V570 just due to having to manage the larger screens. However, I remember having heard it said that the Logic Controller and the HMI controller are two separate chips, so maybe that would leave the PLC scan time identical to the V570. That's assuming of course they used the same chip in all three, which also may or may not be true.

D

[FOSS Logic]

TM,

I think it is a great idea. Look forward to seeing it!

Damian

[Feelin' a little Loopy!]

Phil,

Great article. I think this feature is often overlooked because it is assumed that it isn't allowed.

Some also look at it unfavorably because if you are not careful with your coding you could create a lot of havoc. From my perspective, that is true no matter what your doing.

Hopefully some day Unitronics will address it in the documentation so that users can gain a better level of comfort with it.

[Feelin' a little Loopy!]

Hi Phil,Thanks for the post. This is of interest to me as I have come from a background of PC-based programming and it's always a brain-stretch to cross between that and PLC ladder logic.Whilst I generally agree with the usefulness of loops, my understanding of jumps in the Unitronics world is that they only jump forwards, not backwards. So the "jump back" actually causes the PLC to end the scan at the jump instruction and start the next scan at the jump label. So in the example of a loop, n interations would take n scans, and the other code in the program would not be executed during this time. If the code in the loop is short and the PLC is fast (like the V570) then this wil still execute reasonably well.This isn't confirmed knowledge, and the help file is not definitive on this point. A simple program could be used to test it, or if a Unitroics engineer is reading, it could be confirmed by revelation. Or maybe I am wrong all together...

Hi Simon, I have used this structure myself several times when it was necessary to complete a series of iterations within one scan. I can say with a large degree of certainty that it in fact does prolong the scan it is on and not simply start back at the jump label. In the old Forum you will see a topic call "Implementation of FOR loop" (or something like that) where I reference having actually made a test program that allowed me to determine the effect on scan time as iterations increased (or complexity of the loop). Although Unitronics does not explicitly state that "jumping back" is allowed it does not seem to prevent you from it. I suspect they may not advertise it because it opens the door to a lot of tech support headaches as it could easily be misused if the person implementing it does not take care writing the code or does not understand how the PLC processes the overhead and scan.