ExecTime busting the execTimeout parameter

[pdeschenes]

Hi,

We are experiencing an intermittent issue with a MC050-110 busting the configured execTimeout parameter by a large factor. We've set the execTimeOut to 10ms, the execTimeWork is measured at 5ms and the ExecTime is measured most of the time at the execTimeOut. We cannot find the source of the problem, but so far it seems to happen when we are connected to the service tool. We've seen the ExecTime creep up to 40ms while the timeout was set to 10ms and the ExecTimeWork still measured at 5ms. This problem seems to appear at random, it can take 2 minutes of uptime or 4 hours.

Obvioulsy, this causes a good amount of timing issues and only a reboot seems to fix the issue.

Does anyone have an idea of what could causse such an issue?

Thanks.

[FluidPowerTom]

That's a pretty sizeable increase.  Is the program pretty large, and there's maybe some very intensive logic that only happens periodically? 

I'd recommend making a test program and disabling/deleting chunks of your logic and trying to zero in on what is causing it.

[pdeschenes]

It doesn't seem related to the logic per say. With further testing we found out that it happens pretty much only when we are connected through the service tool.

We have a pretty extensive service application and we don't know if the tool updates the whole application constantly or only the active page.



If I look at the image and analyze our time measurements, I can see that the exectimework is steady and within the timeout we've set. However, I assume the gray section is fluctuating due to the number of updates needed due to our service application. This doesn't explain why the ExecTimeOut is not respected though, I would have assumed that even though the Applog/NV is intensive, the ExecTimeOut would've kept the loop time at its set value.

[Neil]

If you add the Get Time component (x2) to your program, making them the first and last thing the program scans. (your code fits between them)
Then subtract one from the other with a check point, this would be a better representation what's happening in your program.

[pdeschenes]

This is something that we've done before posting here. We've measured the execution time at a lot of places in our program and also the execution time of the whole program as you suggested.

Nothing could explain the massive disparity between the reported exectime and exectimeout, the measured times during the scans were under the reported execworktime as expected.


This is not a deal breaker as it seems to be happening only when using the service tool, however it's a bit baffling as we're not able to pinpoint the culprit.