Difference between revisions of "Equipment/Staubli/gdmux"

Latest revision as of 22:27, 21 April 2014

What?

To make good use of the Staubli robot arm we need to write an g-code interpreter (i.e. demultiplexer) to allow non-programmers to use it efficiently, by utilizing off the shelf CAM software (like CamBam+)

Status?

15-APR-2014 First actuation performed, video here

System diagram

digraph rfboard{
  rankdir=LR;
  size="8,5!";
  
  cam_sw [label="Cam software",shape=box];
  printrun [label="Printrun/Grbl/etc.",shape=box];
  serial_demux [label="Serial de-multiplexer",shape=box];
  misc_elec [label="misc electronics",shape=box];
  robot_arm [label="Robot Arm controller",shape=box];
  
  cam_sw -> printrun [label="g-code"];
  printrun -> serial_demux [label="serial"];
  serial_demux -> robot_arm [label="move commands"];
  serial_demux -> misc_elec [label="misc commands"];

}

</graphviz>

Code

Github Repository

Challenges

G-code standards often have tool specific inline variations. E.g. for 3D printing there's E###, which is the rate of extrusion, whereas for CNC applications there's F### which is the spindle speed. The issues arises as the CS7 controller does the motion planning and inverse kinematics, and although the controller has GPIO they are not 5v TTL and have to be controlled with awkward V+ code. The alternative is to intercept the gcode on a separate micro-controller and either proxy the motion only g-code to the controller or alternatively
- I vote we write the GCode interpreter on a separate microcontroller board, which then spits out V+ MOVE commands to the CS7 over a serial port. There are lots of existing open source GCode interpreters (like this one https://github.com/grbl/grbl) which run on Arduino and RPi, and are written in C/C++. Writing it in V+ will be painful :-) Also, we could interface the feed motors, steppers, etc, directly to the microcontroller, rather than trying to drive them with the CS7 GPIO - Jon.
  - Yes coding the g-code interpreter would be much easier on it's own uC board (we have a tegra2 with serial on it for this purpose, donated by tgreer). The issue with Grbl is that it talks directly to the serial port and just spits g-code at it (the CS7 will still have to interpret that). This also makes making branching off the controller to do spindle/extruder control trickier as you'd have to hook into the grbl code or make a virtual serial port that you parse for F or E codes and then pass the movement codes to the real port.
Choose whether or not to implement arc motion as per G03 and G02. i.e. To use procedural motion or not:

DURATION 0.5 ALWAYS
FOR angle = start TO last STEP angle.step
    x = radius*COS(angle)+x.center
    y = radius*SIN(angle)+y.center
    MOVE TRANS(x, y, 0, 0, 180, 0)
END

Using the likes of LinuxCNC would be even trickier as we already have an kinematics-able controller, also LinuxCNC is designed for near direct motor control making serial port tricky to use as per following.

Electronics

In addition to the CS7 controller itself extra electronics needs to be added in order to allow for a range of potential uses for the arm. For example with 3d printing, we not only need an extruder output but also nozzle temperature control (input+output) as well as heated bed temperature control. As gdmux runs on a single board computer (currently a RPi) inside the CS7 controller we need a reliable way to link it to the outside world. Given the distances involved (a few metres) inter-chip transport protocols such as I2C and SPI (which come free with an RPI) are not suitable. RS232 can handle the distance but is only point to point as such 2 lines will be requires (in addition to the 2 lines going to the CS7 controller!). The most viable approach is a CANbus as it's a bus topology (so can connect the base of the arm and the extruder),it works up to relatively long distances however it requires a controller and a transceiver ship on each device on the bus.

digraph electronics{
  rankdir=LR;
  size="8,5!";
  
  term [label="CS7 term",shape=box];
  data [label="CS7 data",shape=box];
  rpi [label="Raspberry Pi",shape=box];
  arm_base [label="Arm base electronics",shape=box];
  end_effector [label="End effector electronics",shape=box];
  
  rpi -> term [label="serial" dir="both"];
  rpi -> data [label="serial" dir="both"];
  rpi -> arm_base [label="CAN" dir="both"];
  rpi -> end_effector [label="CAN"  dir="both"];
  arm_base -> end_effector [label="CAN"  dir="both"];

}