Traditionally PLCs updated outputs and inputs before/after program execution. This ensured a stable set of inputs to act on in the program. Modern controllers have started to go to asynchronous updates to inputs and outputs. Not knowing which one PAC Control uses could lead to some odd edge case problems.
For the local chassis, are I/O points updated as part of the Host Task in the Round Robin or are they updated asynchronously as the Charts call them? For example, if output1 is triggered by Chart1, and Chart 5 checks Input1 which is a feedback caused by output1, is it conceivable that Input1 could be set within one Round Robin? This assumes the hardware responds fast enough…
Perhaps a more important scenario would be: Chart1 reads and responds to Input1 which causes Input 1 to change. Chart 5 also reads input1 and would expect to see the same value Chart1 saw, but may not if the input is updated asynchronously?
Great, thanks! I had reviewed the Optimizing document that was linked to and was beginning to gather that everything is about as real time as it can possibly be. It is certainly not a problem and actually Allen Bradley even runs a PAC vs. a PLC now from a I/O perspective. It is something that needs to be kept in mind when timing is crucial.
I gained some good insight into program execution by stepping slowly through the code. I was probably overthinking the more free-form timing used by PAC Control. My strategy is to include delay length in a Chart based on whether the Chart supports any other logic. if Chart A needs a value developed in Chart B I just make sure Chart B has 1/2 the delay as Chart A so that the value will be “fresh” each time Chart A runs.
