Introduction
The BCC protocol is designed to have an efficient communication protocol between Robox devices and Robox development tools and applications.
See documentation BCC Protocol/31 for more detailed information.
Communication takes place through network interfaces that are defined as software applications or hardware devices that allow communication with Robox devices with different criteria than a local connection (e.g., RS232). Specific messages are used to manage these interfaces.
Client communication
Logical client registration
Since RTE 34.27.7, command handling for logical registration of a TCP/BCC client has been added. The purpose is to have the list of registered clients and information if the BCC message flow from the specific client is active or not.
The specification of BCC commands is available in the BCC/31 (Network handling) manual - see:
bccNetClientKasSessionBegin |
612 |
bccNetClientKasSessionEnd |
613 |
bccNetClientKasSessionInfo |
614 |
Registration is done by a BCC 612 command in which you specify:
•the maximum timeout to wait for messages from the client before considering the connection inactive
•a descriptive text of the client
If there are no contraindications, the client is registered by storing Ip address and Port from which the command was sent. Obviously, there cannot be multiple clients with the same Ip address and Port.
You can change the timeout value by giving the start command again with the same description (from the same Ip and Port).
RTE manages a list of 32 active clients. Clients are considered active if any BCC message (except bccNetClientKasSessionInfo) is received after the start command before the timeout expires. The timeout is reinitialized with each message.
If no messages are received before the timeout, the active connection bit is removed and the Latch bit 'lack of communication' is imposed. If communication resumes, the 'communication active' bit is set again. The Latch status bit 'lack of communication' is reset only by using the start command.
To remove a client from the list, the explicit BCC command to stop the same Ip address and Port must be given.
There is a BCC command to get information regarding the status of client registration on current address and port.
The complete list of registered clients is available using the R3 function bcc_get_tcp_clients_info() or the respective OB function getTcpClientsInfo().
BCC OOW (Only One Write) Mode
Since RTE 34.27.2, mode handling for BBC3 OOW (only one write) has been added for TCP clients only.
The specification of BCC commands is available in the BCC/31 (Device handling) manual - see:
bccOOWSessionBegin |
530 |
bccOOWSessionEnd |
531 |
bccOOWSessionQueryInfo |
532 |
When this mode is enabled, all write commands from BCC are rejected if they do not come from the TCP client that opened the write session.
In order for a client to open a write session, the following requirements must be present:
•the session must not already be opened by another TCP client
•if a BLACK_LIST (excluded list) is present, the client must not be on it
•if a WHITE_LIST (allowed list) is present, the client must be present there
The write session is closed by one of two ways:
•explicit command from the TCP client that owns the connection
•expiration of the timeout due to no messages from the TCP client that owns the connection.
Either only the Ip address or the Ip address plus TCP Port can be used as the TCP client ID. Therefore, only write messages that meet the requirements after ID verification will be accepted.
They are not subject to the limitations of the OOW mode, and therefore can write without limitation:
•TCP clients on the WILD_CARDS list
•communications that use channels other than TCP/IP (e.g., serial or usb)
To enable OOW mode, the non-empty file OOW.CFG must be loaded into flash. The file must reside on flash in the /FA/ directory.
In this file you can define the elements of the optional lists of:
•WILD_CARDS
•BLACK_LIST
•WHITE_LIST.
In each list item you specify:
•Ip address
•TCP Port (optional, if not present or equal to 0 all ports are assumed)
NOTE: This parameter is used only if TCP Port handling is enabled in the ID.
•mask (optional, if not present equals 255.255.255.255). This parameter is used to be able to specify a permitted TCP client group (e.g. if Ip 192.168.14.17 and mask 255.255.255.128, this implies that the specified address range is 192.168.14.0 to 192.169.14.127)
NOTE: The file is parsed at bootup, and after this stage it is not possible to change the lists.
Related arguments
Keywords
SYS_CFG_2.10 |
Enables the use of TCP port in the TCP client ID in the OOW session. NOTE: Use of Port in ID is contingent on this flag and the one set on the open request. |
Enable dump in report of OOW session open/close diagnostic messages |
|
By means of this keyword, the status of an OOW session can be monitored |
|
Contains the Ip address of the client with permission to write an OOW session |
|
Contains the TCP port of the client with write permission of an OOW session |