status errors

Errors that occur on Dexter are communicated in the next returned packet.

• Most oplets will return a status with a standard error code (see list below)
• Read From Robot and Write To Robot as well as the RunFile SetParameter command deal with file IO and so return the standard Linux error numbers and NOT any of the errors below. E.g. an error code of 2 with an 'r' or 'W' oplet means there is "No such file or directory"; it does NOT mean "Bad Request".
• The Monitor can override any of the above, replacing the status error with a number in the 600-699 range. In that case, it is possible that a prior error may be overwritten. E.g. If a monitor error occurs during a Read From Robot or Write To Robot which also generated an error, that error would be lost. Any such operation should be restarted once the monitor error is resolved.

Standard Dexter Error Codes

Note: These do NOT apply to Read From Robot and Write To Robot

No	Description
0	No error
1	Unknown Most often returned when the requested oplet or sub command is not known. This is most likely to occur because the firmware on the robot is out of date, and it should be updated.
2	Bad Request The request was incorrectly formatted. In practice, this means there was no ';' at the end of the last socket data. Any other malformation is unlikely to be detected.
3?	Firmware - Gateware Mismatch The DexRun.c firmware and xillydemo.bit gateware files do not match. See Issue 68 for more information. Note: This error code is not yet implemented
665	Boundary error A joint was commanded to move past the boundary set for it, Read the errors.log file for details. There are high and low boundary settings for each joint: J#Boundry(High
666	Monitor error Raw encoder position or velocity exceeded, Read the errors.log file for details. If the error was velocity related, the robot will be switched into open loop mode from any closed loop mode under the assumption that the cause is a bad encoder. There are SetParmeter settings for RawEncoderErrorLimits and RawVelocityLimits
+1024	FPGA - Firmware Mismatch proposed When the INPUT_OFFSET in DexRun.c doesn't match the number of ports in the FPGA's mapped address as specified in the XILLYDEMO.BIT file, those two parts can't work together. In this case, rather than just shutting down, the firmware could "fake" a mapped memory array, and continue running. But no motion would be possible; only non-hardware commands can execute. e.g. write_to_robot for updating the files. We need to let the users know there is a continuing issue while still transmitting other error messages (such as an incorrect folder name when attempting to update firmware). To accomplish both, we add a value to all returned errors. If there is no error, we return 1024. If there is an error code of 1, we return 1025.