Communication Interfaces #
The MCF supports communication over raw TCP sockets or over Serial Port. In both cases, the communication protocol is ASCII based.
Command Syntax #
Each command contains printable characters terminated by Carriage Return (ASCII code 13).
The MCF replies with optional data report and mandatory prompt indicating that the command was accepted ([CR][LF] >) or not ([CR][LF]?).
The examples below illustrate the scenarios:
| AT300 | HOST | Comment |
|---|---|---|
| > | The controller sends prompt upon startup | |
| GET A,1 | The host issues command terminated with [CR] | |
| > | The controller indicates the command is accepted | |
| GTT A,1 | Incorrect command name | |
| ? | The controller indicates the command is rejected |
Host Synchronization #
The Host must always process the result of the first command before issuing a second one. The Host must sequence the motion command issued to the robot. A new motion command will only be accepted of the motion is completed. In order to sequence the motion commands, the host software has two options:
- Polling the robot status
- Wait for notification about the end of the motion
Each of the methods above has pros and cons: The notification approach is preferable if the host is not issuing any commands while the robot is in motion. Once the notification is received, the host must parse it in order to determine if the motion is completed successfully.
The waiting for notification is more efficient than the polling because the sequencing of the next motion command can happen immediately. The use of polling introduces lag in starting the next command. Statistically it is half of the polling cycle.