WAM Arm – User’s Manual
www.barrett.com
© 2008 Barrett Technology®, Inc.
Document: D1001, Version: AH.00
51 of 80
i)
Attach the Puck serial cable to the safety board to verify that the safety puck is
functional. Could it have overheated?
2.
You are accessing data outside of the program’s memory space (not likely with standard
example programs).
Solution(s):
a)
Use gdb to determine the offending line of source code.
Problem:
The pendants do not initialize when the WAM power supply is turned on
Reason(s):
1.
The safety board fuse is blown
Solution(s):
a)
Remove, test, and replace the fuse on the safety board
2.
There is no power
Solution(s):
a)
Check for proper voltage at the source (wall or battery)
b)
Check for any custom current-limiting circuits you may be using
c)
Check the output voltage of the power supply (should be 48 VDC, nominal)
3.
There is some other electrical problem
Solution(s):
a)
Contact Barrett for repair
Problem:
The pendant initialization sequence is incorrect when the WAM power supply is
turned on
Reason(s):
1.
The Data/Clock/Latch signals to the pendants are weak
Solution(s):
a)
Make sure both pendant cables are plugged securely into the WAM
2.
There is some other electrical problem
Solution(s):
a)
Contact Barrett for repair
Problem:
Some joints have resistive braking, some do not. The angles that btdiag returns for
the joints without resistive braking are incorrect. This is easiest to check for at the
home position.
Reason(s):
1.
The Pucks without resistive braking are not powering up correctly. NOTE: It is normal to
have no resistive braking in all joints after turning on the WAM and pressing Shift-Idle, but
before you launch a WAM control program.
Solution(s):
a)
Check for a broken CANbus or power wire, usually in a connector near the Puck.
b)
Check for a loose CANbus or power crimp in the connectors near the Puck.
c)
Check for a loose CANbus or power wire at the Puck itself.
d)
Check the syslog for clues (compare it with the syslog above)
e)
Contact Barrett for repair
Problem:
Joint readings “bounce” from reasonable/actual values to values that are
not/cannot be true and back again.
Reason(s):
1.
Realtime control violation
Solution(s):
a)
Make sure the control loop avoids system calls that are incompatible with realtime
control: No UI such as printf() or getch(), no I/O such as read() or write()- just about
anything except for loops and pure math.
b)
Make sure your total WAM control loop time, including the WAMCallback(), does not
exceed the time allowed by the control rate. Keep in mind that the data time-of-flight
