Background

The following figure, taken from the CIFX API Manual (cifX API), shows the standard sequence for starting the bus communication, including the previous configuration of the protocol stack.

The configuration itself depends on the protocol stack used and is therefore not specified here.

Handles & Channels

The figure above, shows the standard sequence for starting the bus communication. The first step is to load the driver via xDriverOpen () (0) and open the channel using xChannelOpen () (1).

Both functions generate handles, that are required in the further course of the application.

The handles must therefore be retained during runtime of the application but must also be terminated before terminating the application via the respective close functions (4 & 5).

The channel handle generated by xChannelOpen (), refers to the start address of Channel [n] on the Dual-Port-Memory (DPM).

A channel works as an access point for communication via the protocol stack. A detailed description of the different sections of the DPM can be found in the Dual-port memory interface manual.

Cyclic Data-Transfer

If the bus is ON, the process data can be received or sent via the various mechanisms, see section (A). The simplest and recommended method is to use the xChannelIORead () and xChannelIOWrite () functions.

They take on the correct addressing at the DPM and follow the handshake requirements. Each channel of the DPM has a process data area for input and output data.

The process data is always organized as a byte array and passed as such in the function parameters. Using offset and length parameters, the process image can be freely addressed.

The application is responsible for the interpretation of the byte stream. There is no function for passing other data types

Communication States

On the DPM in the Common Status Block and Common Control Block, various state machines are defined that represent the current status of the device as well as the bus stack.

The "Change of State" as well as the "Communication State" register provide information about current statuses of the device or allow the application to influence them.

For more detailed information, refer to the Dual-port memory interface manual to trigger or retrieve the necessary flags is the use of the functions xChannelHostState () (2) and the xChannelBusState () (3).

Activating the bus via the xChannelBusState () function is subject to a certain time delay. therefore, for the call of the function, a sufficiently large timeout should be scheduled. However, if the functions return error 0x800C0021 "COM-flag not set", this does not necessarily mean a failure.

Since the process continues in the background, the bus can still be activated at a later time.

Note: If during this process an xChannelIO function or xChannelBusState () is called again, it will respond with the error mentioned above.

For repeated calls, the function will return the status "OK" and correct the user data as soon as the bus is online.

Stack-Configuration

There are different ways to configure the protocol stack.

The configuration itself is protocol-independent and therefore not specified in the illustration. If the configuration is carried out by means of file download (for example SYCON.net), section (B) can be ignored.

SYCON.net - "Start of bus communication"

Most COMSOL Devices (for example CIFX or netHOST) allow automatic start of communication as soon as the device is ready to communicate.

However, this depends on the configuration of the Start of bus communication flag.

Applicatively, this flag is set through the protocol API configuration packages. Alternatively, the setting can also be made via DTM (SYCON.net).