Torch Table Build - Revision history

Ryan Lutz: Redirected page to CNC Torch Table/Manufacturing Instructions

2011-08-20T00:10:50Z

Redirected page to CNC Torch Table/Manufacturing Instructions

← Older revision		Revision as of 00:10, 20 August 2011
Line 1:		Line 1:
	~~{{delete}}~~		#redirect [[CNC Torch Table/Manufacturing Instructions]]

Ryan Lutz: Replaced content with "{{delete}}"

2011-08-20T00:07:00Z

Replaced content with "{{delete}}"

Show changes

LuisOntanon: /* Plasma Cutter Interference Problems */

2011-06-21T12:58:36Z

Plasma Cutter Interference Problems

← Older revision		Revision as of 12:58, 21 June 2011
Line 224:		Line 224:
	</blockquote>		</blockquote>

	From LuisOntanon		From [[User:LuisOntanon\|LuisOntanon]]
	<blockquote>		<blockquote>
	Using a motor driven by pneumatic piston(s) could allow to shield away the controller and not have interference (Pneumatic pistons do not suffer interference) and can yield up a very precise movement.		Using a motor driven by pneumatic piston(s) could allow to shield away the controller and not have interference (Pneumatic pistons do not suffer interference) and can yield up a very precise movement.

LuisOntanon at 12:56, 21 June 2011

2011-06-21T12:56:40Z

← Older revision		Revision as of 12:56, 21 June 2011
Line 227:		Line 227:
	<blockquote>		<blockquote>
	Using a motor driven by pneumatic piston(s) could allow to shield away the controller and not have interference (Pneumatic pistons do not suffer interference) and can yield up a very precise movement.		Using a motor driven by pneumatic piston(s) could allow to shield away the controller and not have interference (Pneumatic pistons do not suffer interference) and can yield up a very precise movement.
	[[Image:~~XXX~~.~~jpg~~]]		[[Image:TorchTablePneumaticMotion.png]]
	</blockquote>		</blockquote>

LuisOntanon at 12:53, 21 June 2011

2011-06-21T12:53:15Z

← Older revision		Revision as of 12:53, 21 June 2011
Line 227:		Line 227:
	<blockquote>		<blockquote>
	Using a motor driven by pneumatic piston(s) could allow to shield away the controller and not have interference (Pneumatic pistons do not suffer interference) and can yield up a very precise movement.		Using a motor driven by pneumatic piston(s) could allow to shield away the controller and not have interference (Pneumatic pistons do not suffer interference) and can yield up a very precise movement.
			[[Image:XXX.jpg]]
	</blockquote>		</blockquote>

LuisOntanon: /* Plasma Cutter Interference Problems */

2011-06-21T12:51:24Z

Plasma Cutter Interference Problems

← Older revision		Revision as of 12:51, 21 June 2011
Line 222:		Line 222:
	You need to shield all motor controller cables and be sure the ground or drain is earth grounded on one side only. What type of motors are you using? Steppers, servo … Some of these motors require some high end wires with separated shielded twisted pairs and they run the motor power wires separately from the position feedback wires to reduce the possibility of problems. The generator may be causing the issue when it reacts to the surge demand thus causing a rapid fluctuation in power. Can you hook a recording meter or scope to it to monitor the output current and frequency? To further isolate the controls side of your system you may need to run a low cost one to one transformer on the incoming power side. I have used this method for servo driven systems when there seemed to be no other way to mitigate dirty power or outside interferences. Do you have any wiring diagrams or pictures of your system? Do you only get the feedback problem when the arc fires with the motion stationary and/or moving? Can you start the arc manually then power up the controls side to see if you have positive control after the start? Sounds like a great project you have going on here. Hope we can help.		You need to shield all motor controller cables and be sure the ground or drain is earth grounded on one side only. What type of motors are you using? Steppers, servo … Some of these motors require some high end wires with separated shielded twisted pairs and they run the motor power wires separately from the position feedback wires to reduce the possibility of problems. The generator may be causing the issue when it reacts to the surge demand thus causing a rapid fluctuation in power. Can you hook a recording meter or scope to it to monitor the output current and frequency? To further isolate the controls side of your system you may need to run a low cost one to one transformer on the incoming power side. I have used this method for servo driven systems when there seemed to be no other way to mitigate dirty power or outside interferences. Do you have any wiring diagrams or pictures of your system? Do you only get the feedback problem when the arc fires with the motion stationary and/or moving? Can you start the arc manually then power up the controls side to see if you have positive control after the start? Sounds like a great project you have going on here. Hope we can help.
	Wayne		Wayne
			</blockquote>

			From LuisOntanon
			<blockquote>
			Using a motor driven by pneumatic piston(s) could allow to shield away the controller and not have interference (Pneumatic pistons do not suffer interference) and can yield up a very precise movement.

	</blockquote>		</blockquote>

Elifarley: /* Linux CNC */ Added link to LinuxCNC

2011-04-14T11:20:13Z

Linux CNC: Added link to LinuxCNC

← Older revision		Revision as of 11:20, 14 April 2011
Line 387:		Line 387:

	==Linux CNC==		==Linux CNC==
	[[~~http://linuxcnc.org/~~ LinuxCNC]]		[[LinuxCNC]]
	===The Setup===		===The Setup===
	We are as of Sept. 4, 2009 using an IBM ThinkPad laptop graciously donated to the cause by Inga. It has the latest EMC2 installed		We are as of Sept. 4, 2009 using an IBM ThinkPad laptop graciously donated to the cause by Inga. It has the latest EMC2 installed

Elifarley: Added links to EMC2 and G-code; Other changes.

2011-04-14T11:07:31Z

Added links to EMC2 and G-code; Other changes.

← Older revision		Revision as of 11:07, 14 April 2011
Line 289:		Line 289:
	=Motor Control=		=Motor Control=

	==G Code==		==G-Code==
	Or how I actually tell the Torch Table to move.		Or how I actually tell the Torch Table to move.

	G ~~Code~~ is a loose standard. That means if you take some other G Code that you did not write, there is a good chance it will not work. The reason is that each G Code interpreter, be it EMC2, RepRap motherboard, or fancy six axis robotic arm controller were all produced for a specific job which require a specific tool path, on a specific machine. Now if you're a computer scientest or programmer, you're going "wait a minute, why don't they just make the language more intelligent, add in a required machine descriptor and abstract the tool path away from the user which forces users to hand craft each part they want to make!" Which is a valid point, and I would encourage someone to come up with a better language, because G Code sucks.		[[G-code]] is a loose standard. That means if you take some other G Code that you did not write, there is a good chance it will not work. The reason is that each G Code interpreter, be it [[EMC2]], RepRap motherboard, or fancy six axis robotic arm controller were all produced for a specific job which require a specific tool path, on a specific machine. Now if you're a computer scientest or programmer, you're going "wait a minute, why don't they just make the language more intelligent, add in a required machine descriptor and abstract the tool path away from the user which forces users to hand craft each part they want to make!" Which is a valid point, and I would encourage someone to come up with a better language, because G Code sucks.

	===G ~~Code~~, ala EMC2===		===G-code, ala EMC2===
	Or how prototype 1 is put together.		Or how prototype 1 is put together.

	[http://linuxcnc.org/docs/html/gcode.html ~~link to~~ EMC2 ~~gcode quick lookup guide~~]		* EMC2 [[G-code]] quick lookup guide - http://linuxcnc.org/docs/html/gcode.html
			* Invaluable [[EMC2]] user generated documentation wiki - http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl
	[http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl ~~invaluable emc2 user generated documentation wiki]~~		* EMC2 G-code guide with regards to using a plasma cutter - http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Plasma

	[http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Plasma ~~Link to EMC2 gcode guide with regards to using a plasma cutter]~~
	Because we don't have an "arc stable, good to cut" we will use a delay instead which means that we'll have to find someplace on the material we can "burn into" while the arc stabilizes. This will have to be hand coded to some extent I am afraid.		Because we don't have an "arc stable, good to cut" we will use a delay instead which means that we'll have to find someplace on the material we can "burn into" while the arc stabilizes. This will have to be hand coded to some extent I am afraid.

	[http://www.linuxcnc.org/docs/2.3/html/gcode_overview.html ~~There is a lot of good information in the manual which will be nessisary to hand craft g~~ code]		There is a lot of good information in the manual which will be nessisary to hand craft G-code - [http://www.linuxcnc.org/docs/2.3/html/gcode_overview.html G-code overview]


	The other option is to use a program to generate g code from a drawing or cad software. The problem with this is that it usually does a point by point move, where a human operator could use a loop and arc move instead to achieve the same results. Furthermore, because there is no guarantee that they conform to the same g code standards as your controller, it is likely that any g code that is automatically generated will need to be tweaked first. If it isn't apparent yet, g code is time intensive to produce. Its saving grace is that once you have it, you can run the same program over and over again.		The other option is to use a program to generate g code from a drawing or cad software. The problem with this is that it usually does a point by point move, where a human operator could use a loop and arc move instead to achieve the same results. Furthermore, because there is no guarantee that they conform to the same g code standards as your controller, it is likely that any g code that is automatically generated will need to be tweaked first. If it isn't apparent yet, g code is time intensive to produce. Its saving grace is that once you have it, you can run the same program over and over again.

	Lets take a look at the below file that was generated using [http://www.inkscape.org/ Inkscape] and this [http://bitbucket.org/jst/inkscape-gcode/overview/ plugin]		Lets take a look at the below file that was generated using [http://www.inkscape.org/ Inkscape] and this [http://bitbucket.org/jst/inkscape-gcode/overview/ G-code plugin]

	<pre>		<pre>

Marie.Byleen at 15:38, 21 January 2011

2011-01-21T15:38:07Z

← Older revision		Revision as of 15:38, 21 January 2011
Line 1:		Line 1:
			{{Template:Category=Torch Table}}

	See [http://openfarmtech.org/weblog/?p=1424 corresponding blog post].		See [http://openfarmtech.org/weblog/?p=1424 corresponding blog post].

WikiSysop: /* RepRap */

2010-07-26T09:36:41Z

RepRap

← Older revision		Revision as of 09:36, 26 July 2010
Line 381:		Line 381:
	==RepRap==		==RepRap==
	The RepRap project uses 12v stepper boards. These are roughly comparable with the Xylotex stepper control package. The difference is that Xylotex can step at 1/8th of a 1.8 degree step per pulse, and RepRap can step at 1/4th of a 1.8 degree step per pulse. Xylotex also has a total higher wattage potential at 24V 2A, but RepRap which runs at 12V 2A should be enough to hit the optimal energy density of the stepper motors. The only thing I would add would be a heat sink and a fan to the RepRap stepper driver so we can work the motor driver harder. Version 2 will most likely try to either incorporate a redesigned RepRap motor driver that can do 1/8th stepping or live with the standard 1/4th stepping. It is yet to be seen how useful 1/8th stepping is in practice. [http://reprap.org/bin/view/Main/Stepper_Motor_Driver_2_3]		The RepRap project uses 12v stepper boards. These are roughly comparable with the Xylotex stepper control package. The difference is that Xylotex can step at 1/8th of a 1.8 degree step per pulse, and RepRap can step at 1/4th of a 1.8 degree step per pulse. Xylotex also has a total higher wattage potential at 24V 2A, but RepRap which runs at 12V 2A should be enough to hit the optimal energy density of the stepper motors. The only thing I would add would be a heat sink and a fan to the RepRap stepper driver so we can work the motor driver harder. Version 2 will most likely try to either incorporate a redesigned RepRap motor driver that can do 1/8th stepping or live with the standard 1/4th stepping. It is yet to be seen how useful 1/8th stepping is in practice. [http://reprap.org/bin/view/Main/Stepper_Motor_Driver_2_3]

			===RepRap Response from Chris Palmer===
			Q. Chris, can the RepRap motherboard v1.1 suffice to handle these stepper motors for our torch table, or a smaller 4'x4' version of the same? We would like to transition away from the Xylotex closed source version. Lawrence commented on this point. What is your feedback on his comment?

			A. You need stepper driver boards in addition to the motherboard for any motors, so the motherboard will drive any stepper motors. Lawrence says the reprap stepper drivers are 1/4 step, but that is not true, they are half step. The V3 stepper drivers are 1/8 step, but I don't think anybody sells them yet, so you would have to get your own PCBs made. They will only do about 2A with good heatsinking, so you won't get the full torque. The chips are rated at 2.5A, but it is very hard to get that in practice. Reprap only needs about 1.5A, so is generally moving to smaller drivers, not bigger.

	==Linux CNC==		==Linux CNC==