CNC Torch Table Log

From Open Source Ecology
Jump to: navigation, search

Main > Digital Fabrication > RepLab Tools > Torch Table


Links

2017-8 work is at D3D CNC Torch Table. Latest version is at CNC Torch Table Genealogy.

Oct 2017 - Workshop

Oct 2017 - Design + Prototyping

At 10 second frame interval - 25 fps video means about 4 hours (250 minutes) of print time per minute of time lapse video:

Oct 2017 - Metal Plastic Composite Design

Tue Sep 23, 2016

Re [1] - The spark ignitor can be driven from the heated bed output of Rambo. It is on a separate power rail that you can supply with 5V. You will need to use a separate 5V power supply since the one linked requires 3A. There is some chance of electromagnetic interference from the igniter causing issues with the electronics, but we will have to manage that if it occurs.

The sensor linked requires 24V, so we should be able to use your motor power supply for it (assuming you are using 24V). The outputs for it are 24V, I think an resistor voltage dividers should be sufficient to shift it to 5V that the Rambo or Arduino can use. This circuit will be close to the ignitor, so you could need some filters / diodes to protect these leads from charges generated.

The gas solenoid looks like it can be controlled from a 24V heater output no problem.

From my perspective it would be easier to just do it all on Rambo and not use the additional Arduino. I am probably biased though.


Tell me how to do it all with Rambo? Then we need more concern about messing up the signals with the spark ignitor, as well as running a more complicated program (with live feedback from the Torch Height Controller)?

For modularity - and first prototype - isn't it better to 'divide and conquer'? Then move to integration later as needed - but typically we like to keep things separate on principles of modularity.

Maybe the strategy for the spark ignitor is to stop all motion - and then run the ignitor - if that happens - no issues? What are the spark-sensitive signals that you can think of in this system?

Or maybe even do wireless isolation - are you familiar with wireless CNC like this - http://irnas.eu/goodenoughcnc/2016/05/26/toslink-cnc-v2 ?

Fri Jun 5, 2015

Discussion with Goodenoughcnc.eu - Luka Mustafa from IRNAS

Controller - [6] http://irnas.eu/2015/06/04/good-eough-cnc-plasma/ - [7]

  • Get 1.5" and 4" tubing
  • Try 1.2 m first
  • Koruza - 1.2m long - do
  • [3] x 6" of large tubing
  • [30] M8x120 thread on whole thread
  • [20] Bearing 608zz - 30-40 cents ea - [8] - 8x22x7 mm - *Flanged 8 mm bearings from China are $1
  • [10] F608Z (same as before with washer - [9]

Z axist

  • [4] LM12uu linear bearings - [10] - [11] - [12]
  • SS 12 mm rod - length I can choose about 1 foot - 8" minimum gives 1 cm movement
  • Threaded rod - same length as linear rog - M6 gives 1 mm per turn - for drive.
  • M8 nuts and washers - m8x20 mm - need a tap for M8
  • Some 3D printed parts

Steppers

  • [3] Nema 23 - ideally with 6.35mm shaft - Stepper Motor Nema23 (SY57STH56)
  • + 1 Nema 17 or just keep 4 of the Nema 23
  • Belts&pulleys - htt5
  • Htd5 - [13] - need [3] x 1.2M
  • GT2 pulleys and belts - stretches, not reinforced
  • Cables from drivers to controllers. No end stops now.


Electronics

  • Planet - CNC controller - use any cables
  • 4 wire - 0.35mm - solder to motor, screw terminal to board

Oct. 21, 2012

This project is beyond my electronics knowledge. But when i was planning on building a Plaz table a while back from a kit my research concluded that CandCNC.com was the best way to go. I've been following his message board for a couple years and all his end users are very happy and amazed at the quality and low cost. His digital torch height control really seems to be impressive an unmatched for less then 10x the $. You don't have to have torch height control to get started cutting, but you have to plan for it because you quickly decide its a necessity. I have one of his 5 axis servo kits waiting until i have more room for a table, if you have any questions just ask. And if you decide to put an oxyfuel torch on it i have some machine-style torches and regulators you can have. Keep up the awesome progress. -LoadTest

Oct. 19, 2012

Darren

I love this idea,

Static compensation would be easy enough to map out deviance and do a best fit approximation between start and end of each line. Dynamic compensation would be a little more involved; only if someone had a line on cheap linear scales. What are your thoughts on where this compensation is performed? If it is done on the PC side you would have a lot more move commands to transmit; a lot of little slightly adjusted lines making up the one long line. If it is done on the Arduino that wouldn't be a problem, but I question the muscle of the atmel uController. What were you thinking about methods of implementing this?

Cheers,

Darren



Chuck

If I remember correctly, it was a flat plate with four bolt holes.

Chuck


Oct. 18, 2012

Chuck

I'd be interested to see the torch table serve a second purpose as a layout & marking tool.

There are plenty of metal parts that involve classic layout techniques like machinist's square, scribe, center punch, and steel measuring tape. With just one or two tools (e.g. a scribe and a spot drill) mounted on the XYZ table we could automate a lot of this.

I have seen the accuracy of the torch table spec'd at 1/32 inch, but I think we can do better, especially if we calibrate it and incorporate software compensation for machine structural inaccuracy. I think 0.005-0.010 may be achievable.

A very useful addition (for both standard torch cutting and for an automatic layout tool) would be a rugged touch probe that can be used to pick up the edges of a part. Clever code should take a part that is not laid square on the bed and rotate the coordinate system to match it.

One bottom line is to make sure the tool (torch) mount is a nice modular interface. Which I suspect it is, though I haven't seen the pictures yet.

Thoughts?

Chuck

Oct. 16, 2012

Chuck

Starting to cook here, check the video:

This sounds better after changing to the series winding connection on the X steppers.

Important request to Darren

Please connect the X2 AND gate in the *step* line, not the *enable* line. I found that gating the enable causes the X2 motor to jump up to a half-step (8 microsteps) between enabled/disabled conditions, which wreaks havoc with the X1-X2 homing action.

Alpha-quality code is at https://github.com/chuck-h/grbl .

Oct. 13, 2012

Chuck

Hi Darren,

I've got an X1-X2 test bed now! I have to make a cut/jumper on the interface board so I can independently enable X2, then I can work up some new grbl homing code.

http://opensourceecology.org/wiki/CNC_Torch_Table_Control_Overview#Test_mule

I am getting quite a bit of noise, the microstepping doesn't seem perfectly even. I should try with different current levels.

Possible issue: grbl seems to disable the drivers at the end of a move, which will cause the stepper to drop into its nearest magnetic detent. When drivers are re-enabled I believe we should pull back into the previous microstep location, but I think there is a potential for losing position with this logic if we happen to stop at an ambiguous phase. I am going to check whether I see this problem. Any way steppernug could go to "idle current level" instead of full shutdown?

Oct. 5, 2012

Yoonseo

Control for torch and plasma cutter- digital high to activate relay would suffice.

Z axis should operate the same as the X and Y axes (move in response to interpreted gcode). For incremental dev's sake, I think we can table the arc voltage feedback.

Start-of-cut should be based on the gcode CAM prep, yup. For versatility's sake. Vann has previously made some gcode edit code that revises the gcode file for oxyacetylene cutting. http://opensourceecology.org/wiki/Gcode_Preheat

Gctrl is a GUI gcode streamer/jogger/homer already out there, so i think we're good on this part. http://opensourceecology.org/wiki/Gctrl

Will get you picture soon. Smartphone is having issues charging.

Oh- also, I'd love to get the details on how to modify the GRBL code for other project purposes- the challenge is getting the intention correctly mapped to the right change. Ex. how to change which pins are for which step/dir for which axes.

Cheers,

Yoonseo


Chuck

This would drive an off-board SSR? Or should we put a heavier duty driver on board (e.g. open drain power mosfet)?

Any need for regulated 12V to come off the board?

BTW I was thinking 24/28V for motor supply, what about you?

Cheers,

Chuck

Oct. 2, 2012

Chuck

I've been looking at the grbl code but haven't done much beyond making it talk to the StepperNug board. Repo at https://github.com/chuck-h/grbl.

I have a 4-drive StepperNug kit and 4 stepping motors but I haven't yet assembled a "mule" for functional testing. I am not expecting to build a full-scale torch table at my location.

I am planning to adapt the code to work with double home switches on the x axis so that the two motors can be sync'd repeatably at startup.

Open questions for me

  • what control outputs are required for the torch?
 *gas torch
  plasma cutter
  • what do we need to do with z axis?
 *preprogrammed (G-code) moves?
 *arc voltage height control for plasma cutter?
  • What do we want to do for start-of-cut
 *build a custom G-code into the grbl interpreter?
 *push it back to CAM prep?
  • What sort of interactive manual controls are needed
 *grbl is primarily a non-interactive G-code interpreter
 *x,y,z jog functions
 *home all function
 *pick up zero reference from part

YK> The mechanical side of the torch table is near completion. A snapshot of current status would be very helpful!

Cheers, Chuck


Darren

Hey Chuck,

I like your idea of using a port expander off of the I2C to sense and interrupt for limit switches. If you want to design around that for your dual X-Axis I think it would be great. Adds a lot more flexibility... As long as someone is willing to code it :) (Looking at you Chuck)

I was going to send some of those port expander signals to the expansion ports as well and I think adding the voltage sense for z-height adjustment as a module for that port is a good idea. I don't think everyone will want that voltage sense (Circuit Mill doesn't need that for example.)

Do you think we are going to be able to fit all of this into the Atmel part?

Cheers,

Darren