User Manual and Operating Guide

2. The Barco Projection Protocol
Sending and receiving a c ommand
A command which is sent to the device will consist of a request. A c omm and which is received by the client will consist of a res ponse.
Requests mus t be sent in the Barco Projection Pr otocol format: each request needs to be structured in the correct way before it is
sent to the device. Responses are also sent in the Barco Projection P rotocol format.
Keep in mind that:
• For Ethernet c omm unication, the Device ad dress must be set to 0.
• A correct Checksu m must be generated for the c omm and.
After a request has been sent to the device, the acknowledgement of the request must be read first. A fter the request has been
acknowledged, the response from the device (if applicable) can be expected.
Example 1: The client wants to know the type of the devic e. It send s the following command: projector type, read. The device will
acknowledge (ACK) the request and then send the response which contains the device type.
Client
Device
(1) projector type, read - request
(2) ACK
(3) projector type, read - response
Image 2-2
Example 1
Example 2: The client sends an unknown comma nd. The device doesn’t recogn
ize the comm and and sends a NACK.
Client
Device
(1) unknown command
(2) NACK
Image 2-3
Example 2
How to handle failing communication?
When a sender fails to send a command, or a receiver fails to return the expected response (ACK, NACK or response), some steps
must be followed to handle this failing commun ication.
There are 2 possible failures:
• Co mm unication link problems: if the sending of the commands itself doesn’t work, it will be because the c omm unication is
broken (e.g. the receiver is disconnected from the network).
• An swer back problems: when commands can be sent out but no response is sent back, it m eans that the communication link
is OK but the receiver is unable to answer back .
Each type of failure needs another way of handling.
Handling com mu nication link problems
As communica tion link problems will most likely have a physical reason (cable disconnected, hub down, device dow n, … ), the user
must be notified and mus t be as ked for his feedback. In most cases there will be a us er intervention needed to correct this problem
(connect the cable, reboot the hub, restart the device, …).
The actual implem entation of this should be described in the specifications of the application.
Handling an swer back problems
Answer back problem s sh ould be addressed in another way. When a receiver fails to answer back it might be that it is currently too
busy to ans wer back. T he application software should implement s ome simple m echanism s to avoid problem s when this occurs:
1. Timeout waiting: the application should wait for a limited amount of time for an answer (e.g. max 10 seconds). This ensures
that the app lication can react when a comm and do esn’t get answere d in time.
2. Retry waiting: if the timeout expires, one can retry waiting for the answer. By do ing this, the user has the opportunity to ca ncel
the action. If ne eded, the retry can even be repeated several times.
3. Retry sending: when a comm and doe s not get answered after the timout waiting and retry waiting, the comm and is considered
to be lost in action and the application s
hould send the com mand again.
This mechanism follows the sequence of the steps: first the timeout waiting is used, then the retry waiting and finally the retry
sending. If all of these steps fail, there might be a m ajor problem with the receiver. In this case the user should be notified o f these
problems so that he can check the status of the receiver.
R5905746 COMMAND CATALOG 06/01/2014
7