1,068
edits
Equipment/Staubli/gdmux: Difference between revisions
From London Hackspace Wiki
no edit summary
mNo edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
To make good use of the Staubli [[Project:Staubli_Robot_Arm|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. | To make good use of the Staubli [[Project:Staubli_Robot_Arm|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. | ||
===Challenges=== | === System diagram === | ||
<graphviz border='frame' format='svg' > | |||
digraph rfboard{ | |||
rankdir=LR; | |||
size="8,5!"; | |||
cam_sw [label="Cam software",shape=box]; | |||
printrun [label="Printrun",shape=box]; | |||
grbl [label="Grbl",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"]; | |||
cam_sw -> grbl [label="g-code"]; | |||
printrun -> serial_demux [label="serial"]; | |||
grbl -> serial_demux [label="serial"]; | |||
serial_demux -> robot_arm [label="move commands"]; | |||
serial_demux -> 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 [http://www1.adept.com/main/KE/DATA/V%20Plus/V%20Language%20Reference/signal_i.html 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 | * 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 [http://www1.adept.com/main/KE/DATA/V%20Plus/V%20Language%20Reference/signal_i.html 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. | ** 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. | ||
