DexRun DDE communications

Dexter <=> DDE (or other) communications:

DDE, and other applications communicate with Dexter via raw sockets, over an Ethernet link on port 50000. The DexRun firmware accepts ASCII command "oplets" and responds with BINARY status.

Wait for status after sending each oplet:

After each "oplet" is sent, the host application must wait for the status to be returned before sending the next oplet. Even if the status is ignored (not parsed) it is critical to wait for the status to be returned before continuing. In most cases, status will be returned almost instantly, but in some cases, it may take several seconds to process and return. Sending multiple oplets without waiting for a return status can result in unpredictable operation.

Data Format

Fields are separated by space (but could be comma) and the request is terminated by a ';' (semicolon).

Header

• ​job_id: Mapped to an actual job object. There can be many jobs and this number indexes the job the data came from.
• instruction id: Index of the instruction in the jobs do_list array. e.g. In a Job with 4 instructions, the id will be 4 for the last instruction.
• start: Time (in milliseconds since Jan 1, 1970) when the instruction was started.
• end: Time the instruction ended. Since the instruction hasn't ended, its end time is "undefined."
• instruction: The command / oplet / instruction to be executed.

for example, 1 2 1528438131 undefined g ; will return a status update. This is job 1, the 2nd instruction of the job, it was sent on Friday, June 8, 2018 6:08:51 AM GMT, the end time is unknown, and the oplet is 'g'.

Dexter does not check or use this "header" information, it simply returns it to the host. All of the header data is included in response packets sent back to DDE from Dexter:

• The ID's and Oplet allow DDE to know what that response is to.
• The times are useful tools for debugging. We can know the timing of an instruction to compare it with other instructions in the job as well as instructions from other jobs. In a post-mortem analysis of two cooperating jobs, you can see which instructions (from both jobs) happened first.​

The DexRun code is implemented in several different ways which are selected by the second command line argument.

• ./DexRun # 1 # uses StartServerSocket which is a generic server interface.
• ./DexRun # 2 # uses StartClientSocket which is a generic client interface.
• ./DexRun # 3 # uses StartServerSocketDDE which is a special server interface for DDE. By default, Dexter starts DexRun in this mode.

StartServerSocketDDE uses a larger 256 byte buffer (the others are 64 bytes) but only 128 bytes is sent by DDE. When a new packet is received, it is processed by ProcessServerReceiveDataDDE which:

• Expects to see at least 4 spaces at the start (will not start passing on data until 4 spaces are seen and removed). This is done to strip off the header data and return just the actual message payload.
• Expects to see a 0x3B "delimiter" or flag at some point in the data. 0X3B is a ';' (semicolon). This is replace with a NULL and is the terminator for the payload. The code, does NOT however, stop when it sees a semicolon. ALL semicolons will be replaced with NULL. Any semicolon in the data must be escaped (e.g. as added for the write_to_robot implementation).

The ParseInput routine then tokenizes the payload input via the standard C strtok function using " ," (space or comma) as the delimiter. The first token is expected to be the the command / oplet / instruction. This is converted from a letter to an enumerated value by HashInputCMD. Then a switch continues the parsing of the command according to that value.

Every command sent by DDE is then replied to via ProcessServerSendDataDDE which again strtok's the (cleaned up) command from the recieved data and then simply returns it as an integer in an array along with some time information, an error code, and the current robot status.

The DDE code is in socket.js. Data is sent via send, and recieved via on_recieve which is setup as the socket response handler.