Filter
Top Products
2. The Barco Projection Protocol
Sending and receiving a command
A command which is sent tothe device will consist ofa request. A command whichis received by the client willconsist ofa response.
Requests must be sent in the B arco Projection Protocol format: each reque st needs to be structured in the correct wa y before it is
sent to the d e vice. Responses are also sent in the Barco Projection Protocol forma t.
Keep in mind that:
• For Ethernet comm unication, the Device address must be set to 0.
• A correct Checksum must be generated for the command.
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 re sponse from the device (if applicable) can be e xpected.
Example 1: T he client wants to know the type of the device. It sends the following command: pr ojector type, read. The device will
acknowledge (ACK) the r equest 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: T he client sends an unknown comma nd. The device doesn’t recogn
ize the command 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 hand le this failing communication.
There are 2 possible failures:
• Co mm unication link problems: if the sending of the commands itself d oesn’t work, it will be because the communication is
broken (e.g. the receiver is disconnected from the network).
• An swer back problems: when commands ca n be sent out but no response is sent back, it means that the commu nication link
is OK but the receiver is unable to answer back.
Each type of failure needs another way of handling.
Handling communication link problems
As communication link problems will most likely have a phy sical reas on (cable disconnected, hub down, device down, …), the user
must be notified and must be as ked for his feedback. In mos t cases there will be a user intervention needed to correct this problem
(connect the cable, reboot the hub, restart the device, …).
The actual implementation of this should be described in the s pecific ations of the application.
Handling answer back problems
Answer back problems should be addres sed in another wa y. When a receiver fails to answer back it m ight be that it is currently too
busy to ans wer back . The application software should implement s ome sim ple m echanisms to avoid problems when this occurs:
1. Timeout waiting: the application should wait for a limited am ount of time for an answer ( e.g. m ax 10 seconds). This ensures
that the application can react when a comm and doesn’t get answered in time.
2. Retry waiting: if the timeout expires, one can retry waiting for the answer. By doing this, the user has the opportunity to cancel
the ac tion. If needed, the retry can even be repeated several times.
3. Retry sending: when a command does not get answered after the timout waiting andre try waiting, the command is considered
to be lost in action and the application s
hould s end the com mand again.
This mechanism follows the sequence of the steps: first the timeout waiting is used, then the retry waiting and fina lly the retry
sending. If all of these steps fail, there m ight 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