-
Notifications
You must be signed in to change notification settings - Fork 85
status errors
JamesNewton edited this page Oct 11, 2019
·
12 revisions
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.after 2019/10/11 only sets high bits in the error code so it will not interfere with the standard error codes as long as the returned error is bitwise anded with 255. E.g.error_code = status_error & 255;
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. |
+2^10 | Firmware - Gateware Mismatch: since 2019/08/16 StepAngles branch. When the INPUT_OFFSET in DexRun.c firmware 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. See Issue 68 for more information. 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. This simply sets the 10th bit in the error code. |
+2^27 | SPAN_ERROR_CODE After 2019/10/11 StepAngles branch errors recieved from SPAN servo, address 1 Joint 7. Read the errors.log file for details. |
+2^28 | ROLL_ERROR_CODE after 2019/10/11 StepAngles branch errors recieved from ROLL servo, address 3 Joint 6. Read the errors.log file for details. |
+2^29 |
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 |
+2^30 |
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. After 2019/10/11 StepAngles branch Change from 665 to +2^29. |
To search the Wiki, use the main search box in the black bar at the top, then select WiKi to filter the results or go to https://github.com/HaddingtonDynamics/Dexter/search?type=Wikis&q= and then add your search terms to the end of the URL.
To report errors, or request additional data, please chat with us on discord and/or raise a new issue