CNC Torch Table Log
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