First up, let me say how happy I am that someone else is reading the docs!
We don’t generally go into it in the docs as most people never think like this.
‘The chart runs, the comm handle works, life is good’ is the norm.
I’m still interested in why you even thought to ask the question…
Ok, that answer is not going to help…much…
The EPIC is a quad core processor, so charts are spread across all 4 cores. Thus time slices sort of go out the window. You still need delays, that does not change, but the notion of a single (core) round robin like you had in SNAP pac (or LCM4) is gone.
“Get Number of Characters Waiting,” has no delay, so if you call that instruction in a tight loop, regardless of communications type, you risk burning a lot of CPU cycles waiting for characters, if COMs are slow.
If they are fast, it is not so much of an issue. (300 baud vs 19k2). So depending on the baud rate, you may want a delay in there to free up a time slice.
On the other hand, an Ethernet Open, if it doesn’t succeed at first, uses a suspend chart up to the length of the COM handle’s timeout value; same goes for waiting for a character.
Serial. When it comes to getting characters, the controller has to poll for them, and doesn’t suspend the chart. Till you get them, it is going to take every time slice.
Hope that helps.