Are charts suspended during communication commands?

There are several commands that can cause charts to be suspended (i.e. Suspend Chart, Call Chart, etc.).

When a chart executes a communication command, is it suspended until the operation completes? If not, what happens to its time slice – does it busy wait or perform some sort of delay?

It depends.
It depends on the type of comm handle.
It depends on the command used.
it depends on if its an EPIC or a SNAP PAC.

Are you having trouble with throughput? What product are we talking about? What commands are you using? FTP? Serial? Ethernet?

I was looking for where the “it depends” is documented.

Right now, we are developing logic for the Groov, and we are using Listen, Accept and Open communication commands, the Transmit and Receive commands (for tables, strings and characters). We have TCP and Serial communication channels. We are also using some of the test commands (Communication Open?, Get Number of Characters Waiting).

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.

I am asking these questions because I am a software engineer, not a programmer :slight_smile: Programmers might be happy with “I got it running on my box for my tests, I am happy”, engineers realize that the system itself needs to meet target specifications…

We have a system that uses communication channels to control devices that are connected to the controller over ethernet and serial connections. For each of these devices, we have a “driver” chart for that device handles the device communications. I want to make sure that these drivers doing things as efficiently.

1 Like

It sounds like you are looped waiting for characters because there is no delay in the chart as Beno mentioned.