Equipment/Staubli/gdmux

What?

To make good use of the Staubli robot arm we need to write an g-code interpreter to allow non-programmers to use it efficiently, by utilizing off the shelf CAM software.

System diagram

<graphviz border='frame' format='svg' >

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

}

</graphviz>

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.

Useful links

• g-code refference
• List of cam software and converters from Shapeoko
• CamBam+ - popular,customizable but non-free CAM software package
• The NIST RS274NGC Interpreter The actual gcode standard.