Open Source Ecology - User contributions [en]

James Slade Log

2014-05-15T15:02:17Z

Daniel Benamy: /* Tuesday Aug 27, 2013 */

{{TOC left}}
[[Image:James_Slade.jpg|500px|thumb|James "Bunny" Slade]]
{{Clear}}

=Saturday Sept 7, 2013=
Much left to do and not enough time to do it all.

CEB 2 is done and moved to the shed. Had a few issues, ranging from a stuttering cylinder to the drawer being welded in wrong. Videos here:

[http://youtu.be/Fw6xWZQKZpg Stuttering cylinder] This Issue was resolved by adding in a bypass hose for the shaker solenoid.

[http://youtu.be/YUX82fpBr5s Watching the system work]

[http://youtu.be/Dwu2PjK328o The drawer not retracting far enough]

[http://youtu.be/NTP0DUlfn-I Final walk through for this trip]

Also updated the code a bit and got it working perfectly for CEB 2 and 3.

I'll continue working on this project, just having to get back to my normal life for a little while. o/

=Friday Sept 6, 2013=
I leave here on Sunday and there's so much left to do. These controllers take me about 2 days to do from parts to full assembly. I am currently working on the button panel and will have it done today. Will then head to the shop and test the controllers on CEB 2. Should have CEB 2 done and moved by tonight. That leaves tomorrow to build CEB 3...

=Thursday Sept 5, 2013=
Spent today making some corrections to the controller doc I linked yesterday and made some changes to the button panel. Moved some colored wires around to make it easier to understand the document's pictures. Worked on CEB 3's controller the rest of the day. Still a little bit more to do on the button panel.

=Wednesday Sept 4, 2013=
Went to Sweiger today to get some materials for the CEB's. A new 2 3/4" DOM for the press foot on CEB 3. Then used previously was a little big and let the foot move around too much. Finished up the controller for CEB 2 today. Marcin and I documented its assemble as seen here:

[https://docs.google.com/drawings/d/1AxeT5boHsEPlywFx8O94khOHOpDnSFwuXK3kAgsHP1c/edit CEB Controller assembly]

=Tuesday Sept 3, 2013=
Spent today working on the controllers and a little bit of shop time. Nothing to major to report other than that.

=Friday Aug 30, 2013 thru Monday Sept 2, 2013=

Apologies, but this weekend was sort of a blur. Lots happened. From moving the CEB to the field, setting up up and running it. We pressed blocks and made some changes to the CEB drawer assembly. The drawer was able to shift and tore out the bearing. So we added in constraints to keep it centered. Video: [ http://youtu.be/VXkzoED9-rw CEB 3] This seems to be working quite well.

<html><iframe width="420" height="315" src="//www.youtube.com/embed/VXkzoED9-rw" frameborder="0" allowfullscreen></iframe></html>

CEB 2 now has its drawer working. Marcin and I spent most of Sunday working on it and seems like we have a good solution. The bearing mounts weren't done correctly but they still work. Will be adding in addition cylinder supports, like CEB 3.

Also currently working on the controllers for the remaining CEB's and documenting their assembly.

=Thursday Aug 29, 2013=
[http://www.youtube.com/watch?v=y918BFjbqEQ&feature=youtu.be The LifeTrac 4 hauling off CEB 3 to the field.]

Knocked out quite a bit of the punch list from yesterday. CEB 2 is close to done. Adding in the cam rollers tomorrow, manifold and the hopper assembly. Will test it and go from there.

=Wednesday Aug 28, 2013=
Have a punch list of things to get done:
*Add auxiliary spool to LifeTrac 4 to handle the 2nd power cube to drive the pulverizer.
*weld splines on pulverizer, repair 2 broken splines.
*Add motor plate to second pulverizer and hoses to get it operational.
*Update and test code on CEB 3
*relocate CEB 3 to the dirt mound for block press testing

CEB 2:
*Drill holes for cams and weld cam assembly together
*add cam assembly to machine and test drawer
*Center support arms and drill new holes or find other solution
*Test main cylinder
*check over all function with both cylinders active
*attach hopper and shaker, test shaker
*attach hydraulic manifold and verify they are assembled correctly
*run permanent hydraulic lines

CEB 1:
*Drill pin hole in main cylinder
*drill bolt holes in press foot
*remove welds from press foot
*Drill hole in press foot DOM to match main cylinder
*weld DOM to lower press foot
*bolts upper and lower press foot together and then attach to main cylinder via pin
*add welds to frame, lots needed
*reassemble frame and square it
*check over all support arms and frame
*attach cylinder to drawer
*assemble cams
*attach cams for drawer and test
*test main cylinder
*check over all function with both cylinders active
*attach hopper. Shy one shaker assembly. Can grab of CEB 2 to test.
*attach hydraulic manifold and verify they are assembled correctly
*run permanent hydraulic lines

Manifolds:
*verify proper assembly of solenoids to manifold
*install quick attaches
*install bypass assembly
*install pressure sensor
*install wiring
*make mounting plate

Controllers:
*fab and assemble remaining controllers- 2 days to do this
*build out button boxes with power and battery connections.
*upload code and test
*Attach to machines and test

=Tuesday Aug 27, 2013=
Zach updated the controller code to add in the shaker again, address the main cylinder bottoming out due to different stroke (8" versus 12") and switched the over extend from timed to percent. Going from default 100 to .05.

New code is here: https://github.com/OSE/ceb-controller/

*Added another power cube to the LifeTrac 4.
*Got 2 more power cubes working.
*Cleaned up the shop a bit.
*Worked on CEB 2, removed the hopper plate and tried adjusting the support arms in.
*Made some adjustments to CEB 3 pertaining to the PSI, adjusted it from 2000 to 2500.
*Had a meeting with Marcin and Katie. I'll be staying another week to keep going on the CEB machines.
*Discussed everything needed to run the brick presses by this weekend.

=Monday Aug 26, 2013=
Finally some celebrating today. It works.

Got new code to handle the additional knob for the drawer. Had some issues with the main cylinder running backwards, out of sync. Corrected that with a simple rewire of the solenoid. Got the pressure sensor adjusted to 2000 PSI and the bypass valve set to slightly higher. Had collisions with the drawer and main cylinder, which I expected. Was able to adjust that out with the code. Currently CEB 3 has the line of code "overextend_delay = 100" set to 210. This backed the main cylinder off enough for the drawer to slide through. The shaker still doesn't fire off as the code appears disabled for it. Zach said he'd have that correct tonight or tomorrow. I need to adjust some of the retract distance out of the main cylinder as its trying to pull down too far. Should be able to do this with the main cylinder knob. The CEB 3 is ready to handle some dirt now, so we can see how it compresses and ejects a real block.

[http://youtu.be/Pdk061qEKqQ Video of the CEB3 now]

<html><iframe width="420" height="315" src="//www.youtube.com/embed/Pdk061qEKqQ" frameborder="0" allowfullscreen></iframe></html>

Still have 2 machines to get done, but am currently focusing on getting a pulverizer running before this weekend. That will most likely be the focus of work this evening.

=Sunday Aug 25, 2013=
Things can't happen fast enough at this point...

Today I got the new power converter hooked up, new code verified, controller hooked up and fired the system up. Nothing worked again. After some serious reworking of the hydraulic manifold, turns out whomever assembled it originally had the shaker solenoid on backwards, which blocked all the flow through the manifold. This had caused many issues with the powercube I was using, some of the lines etc. So much wasted time due to that. Finally got that system properly setup, hooked up the controller again and this time, I got some action. However, the action I got was everything trying to work all at the same time. I shot a video of what was going on here:

[http://youtu.be/eYK24RqZaGY Controller issues]

Currently waiting on a response from Zach to get his opinion of what may be happening.

=Saturday Aug 24, 2013=
First thing that happened today when hooking up the controller was that nothing worked. After a bit of testing it was obvious I was missing something. Upon further inspection and talking with Zach it came to light I was missing several connections. The 5v from the Arduino to the relay board, all the ground connections from the relay board and was on the wrong pins of the relay board. Go all this corrected, some new code to handle the extra pot knob and went back to the shop. After getting it all hooked back up, nothing happened again. This time it turns out the 12v to 5v converter was no longer working. Got a new one setup for trials again tomorrow.

=Friday Aug 23, 2013=

I have everything setup to run on CEB 3. Right now I'm going to upload the code to the controller and see how it works before hooking it back up to the CEB.

[[File:James.7z|This is the 3d printer file for making the scaffolds]]

[[File:CEB_code.rar|This is a rar of the arduino code used currently to test the CEB]]

[http://youtu.be/eaCwHmgKhE4 Video of the CEB setup with controller]

=Thursday Aug 22, 2013=
Today I made major headway on the controller box. It took longer than I thought, but I have a working box.

[https://www.youtube.com/watch?v=NJU0cOOeAOY Here's the controller laid in the box]

I will be attaching this to a machine tomorrow and testing it.

=Wednesday Aug 21, 2013=
CEB 3 is going to visit the mill to have a hole bored through the main piston. Then I'll be adding in the press foot properly. Haven't done it yet, and instead focused on the electronics today.

[[File:Boxcon.jpg|400px|thumb|center|The controller box]]
Focused heavy on placement and had two scaffolds built on the 3d printer to hold the parts up. Have to go on a fastener run in the morning so I can attach everything. Will be getting parts enough for 3 controllers.

[ http://youtu.be/8idmx0u-2pQ Today's coverage of CEB 2]

Outside of that I took Gary to the airport today.

=Tuesday Aug 20, 2013=
Made a bit more progression on the CEB's. Managed to put parts from a couple non working mag drills together and make one work. Was able to drill most of the holes needed on CEB 2 with it and now have the frame standing up. The holes that were all torched previously don't line up with the attaching components. As an example, the support rails have pre drilled holes, but the holes on the frame were torched, and they don't line up at all. Basically all the torched holes were done on the frame and done very badly. Since they don't line up, I have to make all new holes once I get the machine square. Which wasn't done previously. Since so much material was torched out that leaves structural issues with drilling new holes. At this point I don't have that much faith that CEB 2 will function very well. It has a gap at the drawer level, which can lead to blocks with mushroom tops as the material can squeeze out when compressed. The blocks may not be totally square. We'll just have to see what comes out. I'll try and get some video of the specific issues for my next log update.

Spent most of my day on the above issue.

[ http://youtu.be/L5yD-t7GbeI Status update today]

=Monday Aug 19, 2013=
Trying to get a new mag drill, at a stand still on CEB 2 without. Going to focus on making every other part that I can today and get CEB 3 fully assembled.

John and Jonathan came to the shop today to learn welding and cutting. Both did very well so I put them to work a bit. :) Between the two they made 2 feet for one of the CEB's that was missing a pair. Also, tearing down 4 rail guides that had the wrong size holes drilled for the bearings.Drilling new holes and welding them back again. Finally they helped make some holes in one of the shaker units so it'll fit on multiple CEB's.

[http://youtu.be/I82SY0fqS6E Monday Update showing CEB 3 together and parts being reworked.]

[[File:JonathanJohn.jpeg|640px|thumb|center|Cutting holes]]

=Sunday Aug 18, 2013=
Didn't get much done in the shop, need a mag drill as all the ones here no longer work. Critical piece needs to be drilled out on CEB 2. Not something that can be placed on a drill press or just bored out. I imaging it could be just drilled or torched, but I like precision and don't want room for the frame to be able to shift under pressure.

Did work on the electronics layout a bit. Still in discussion with Zach Dwiel on the components needed as the press feet on these machine sits higher than the deck and the code doesn't account for that. He's going to write up some test code to see if we can get around it reworking the frame of the machine.

=Saturday Aug 17, 2013=
Updating spreadsheets, financial logs and getting the build plans for the CEB's from last November. The holes for the drawer rollers are too big at 3/4" they should be only 1/2" so will rework those. The top of one CEB so far has the removable crossbeams welded to the inner chamber which also has to be corrected. The drawers on all three are firmly stuck in the machines, so will be hooking up a power cube today to try and move the hydraulics to free these things up.

Today's videos thus far:

[http://youtu.be/9JIg0aGDJ_I CEB 1 press foot coming up too high]

[http://youtu.be/iiAs_1xTZL0 CEB 1 press foot has broke welds]

[http://youtu.be/YLa2RM_PnaY CEB 1 The bottom pin sits too high and is also barely attached for the weight it has to withstand]

[http://youtu.be/T_XEgQBBA6c CEB 2 the press foot is coming up really shy. Bad assembly]

[http://youtu.be/XXcp9g2LYn8 CEB 2 cut away of the action. You can see its just built incorrectly]

[http://youtu.be/lojKGoVc6jw CEB 2 press foot solution]

[http://youtu.be/6uHnMo6ieHM Printing a scaffold for the controller box]

[http://youtu.be/3mRzhBTbNIM CEB 3 status]

=Friday Aug 16, 2013=
Bought a box from the local hardware to use as a switch house for the CEB control toggles. Doesn't look like its going to work very well, will know after some further inspection and layout. Also got some rubberized spray to coat the plugs with for weather protection.

Will continue with the CEB move today and get the remaining parts in the shop and start setting the machines up. Will then inspect them.

[http://youtu.be/Tiaq-LKJBJI CEB initial inspection]

Got all the CEB's moved into the shop, setup most of one and ran into an issue with some bad welds. Will correct those and continue the assembly tomorrow.

=Thursday Aug 15, 2013=
Taking an inventory of electronics for the controls, calculating current expenses, look at the CEB's and determine a work area.

Laying out controller box. Using a Pelican 1060 box with a clear lid so we can see the LED's on the boards. This isn't a finished design, merely for observation while tweaking the over all design. Will also see if we can have a 3D printed scaffold of sorts for the components to screw into as space is very limited and I must suspend the components.

Moved the majority of the CEB's from the shed into the shop. Setup work space.

=Wednesday Aug 14, 2013=
Drove from Austin to Factor e Farm, 12+ hour journey.

=Tuesday Aug 13, 2013=
Went to Fry's Electronics in Austin to acquire parts for the controller. Picked up a crimp tool for the Molex connectors, some 2, and 6 pin Molex connectors, 3-1k ohm linear potentiometers, a rubber boot for a toggle switch and some extra screw down terminals.

=Friday Aug 10, 2013=
Ordering parts and finding alternative sites. Working with Katie on this.

=Thu Aug 8, 2013=
Work log at bottom of page.

Finalizing parts needed for initial controller build.

<html><iframe width=100% height='500' frameborder='0' src='https://docs.google.com/spreadsheet/pub?key=0ArpE5Y9PpJCXdG40QjhpSEE0ZkhmYVhnMFREQktBZFE&output=html&widget=true'></iframe></html>

[https://docs.google.com/a/opensourceecology.org/spreadsheet/ccc?key=0ArpE5Y9PpJCXdG40QjhpSEE0ZkhmYVhnMFREQktBZFE#gid=0 edit]

=Wed August 7 2013=
*[[Upverter]] - Google Doc for circuit design - free for open source project - [https://upverter.com/eda/#designId=2d958299ddd5a35c,tool=schematic Link to Schematic]:

<html><iframe src="https://upverter.com/zdwiel/2d958299ddd5a35c/Sumbandila-III/ " width=100% height=500> </iframe></html>

*Conference call with Zach.
*worked out a BOM for the controller
*have a schematic drawn for the circuit
*will compile the BOM tomorrow to get parts ordered.

*[[CEB_Hydraulic_Pressure_Switch]]

*[http://amzn.com/w/2QEXKOXRKA18V Amazon BOM]
*Future pressure sensor - continuous vs on/off - [http://www.digikey.ca/product-detail/en/M7139-05KPN-500000/223-1138-ND/3945787]

=Tue Aug 6 2013=

<html><img src="https://docs.google.com/drawings/d/1CRQYpuz20SKIikbOwQ791Eetug49pvSpkcwL_16zYtQ/pub?w=480&h=360"></html>

[https://docs.google.com/a/opensourceecology.org/drawings/d/1CRQYpuz20SKIikbOwQ791Eetug49pvSpkcwL_16zYtQ/edit edit]

==PCB Design==
*See [[CEB_Press/Manufacturing_Instructions/Detroit_Fab_Lab_Solenoid_Driver_v4]]
*See code - [https://github.com/OSE/ceb-controller/tree/master/dwielcode/CEBManual] - updated July 2013
*Design software runs in Wine on Ubuntu - [http://www.expresspcb.com/ExpressPCBHtm/Download.htm]
*Arduino - [http://www.amazon.com/computers-accessories/dp/B006H06TVG]
*Cable - [http://www.amazon.com/gp/product/B00A6SOGC4/ref=oh_details_o06_s00_i01?ie=UTF8&psc=1]
*Relay - [http://www.amazon.com/SainSmart-8-Channel-Relay-Module-Arduino/dp/B0057OC5WK/ref=sr_1_1?ie=UTF8&qid=1375287813&sr=8-1&keywords=relay+boards]
*12V to 5V supply - [http://www.amazon.com/HOSSEN%C2%AE-Converter-Power-Supply-Module/dp/B00A71CMDU/ref=sr_1_2?s=electronics&ie=UTF8&qid=1375834507&sr=1-2&keywords=12v+to+5v+power+supply]
*Buttons - [http://www.grainger.com/Grainger/pushbutton-complete-units/push-buttons/electrical/ecatalog/N-8e3]
*Code for Diecimila to Teensy - [https://github.com/OSE/ceb-controller/blob/master/dwielcode/CEBManual/CEBManual.h] - convert Diecimila to Teensy
*Real Terminals - [http://www.amazon.com/Screw-Connector-Electric-Barrier-Terminal/dp/B005EPE9ZS/ref=sr_1_10?s=electronics&ie=UTF8&qid=1375835128&sr=1-10&keywords=screw+terminal+block]
*Or Yoonseo Terminal - [http://opensourceecology.org/wiki/CEB_Press/Pictures_of_Newest_Controller]

Design Rationale for Zach's CEB Controller -
*Switch from automatic to manual mode - toggle
*For drawer - you calibrate it and move it a certain percentage.
*For drawer - end positions via pressure sensor
*Replace pause with auto/manual switch

PCB of Board - [https://github.com/OSE/ceb-controller/blob/master/dwielcode/board/cebpress-controller-schematic-v4.png]
*Design Have plugin into main board
*Uses [[Arduino Teensy]]
*6 buttons - forward back up down pause shaker; timing knobs - 1 for main cylinder - to select brick thickness based on a given power source; 1 for drawer cylinder
*http://www.ladyada.net/library/pcb/manufacturers.html

=Sunday August 4 2013=
=PCB designs=
Sitting down and looking into PCB design for the CEB's. These will be professionally made to save time and also designed to be robust enough for outdoor, all weather use.

2 hours

=Saturday August 3 2013=
=Log Start=
*Evaluate current requests from FeF and determine cost, time, and workflow
*Setup Log

Had a late day getting started as there were unexpected issues here in moving my truck from Creation Flame to a shop in town. This will become 1983 Chevy Blazer 6.2 diesel mobile 4x4 power cube with a turbo. :)

=Time Log=

[https://docs.google.com/spreadsheet/ccc?key=0AhoET3RVh7_YdDZIQ3hzeHg4b3cyQnEtQTh4R2N0eHc#gid=0 Time Sheet]

<html><iframe width='500' height='300' frameborder='0' src='https://docs.google.com/spreadsheet/pub?key=0AhoET3RVh7_YdDZIQ3hzeHg4b3cyQnEtQTh4R2N0eHc&single=true&gid=0&output=html&widget=true'></iframe></html>

[[Category:Personal Logs]]

Dorkmo Log

2014-05-15T15:01:57Z

Daniel Benamy: /* april 13, 2014 */

{{RightTOC}}
im going to try to maintain an torrent rss feed of my files if anyone wants to subscribe to my latest and greatest. im new so it might not work. http://dorkmo.net/osefeeddorkmo.xml

also going to start a bittorrent snyc file folder. going to try to make torrent rss feed just clean polished stuff. and sync folder will just be lots or random stuff in process. heres the read only link BAW3VSPFCZ325PSPYQYGUMEWNZLNC2BJV [http://www.bittorrent.com/sync software] *not open source


=april 14, 2014=

http://opensourceecology.dozuki.com/c/Controller

http://blog.protoneer.co.nz/wp-content/uploads/2012/10/Arduino-Uno-Mega-Dimensions.png

=april 13, 2014=

trying out the [http://fritzing.org/home/ fritzing] program for a new ceb controller board project. [https://docs.google.com/document/d/11deHuTHwnXVGwOAiGU-PDnJxmzbjP9ZpLYPTA-D4dCo/edit?pli=1 Andrew's notes for reqs]

[[File:Controllerbridge1.fzz]]

finding a couple things for board [[Talk:CEB Press 6 - Controller Module - Bill of Materials]]

expiramting with an idea for printable rocker switches that will allow for rubber outer seal and can activate buttons mounted on a pcb. would eliminate wiring board to buttons.

[[File:Rockersmdbutton.skp]]

also have been looking over bunny's log for help [[James Slade Log]]

[https://upverter.com/eda/#tool=schematic,designId=2d958299ddd5a35c wiring schematic]

[https://docs.google.com/drawings/d/1AxeT5boHsEPlywFx8O94khOHOpDnSFwuXK3kAgsHP1c/edit?pli=1 pictures of assembled board and wiriing]

[http://opensourceecology.org/wiki/James_Slade_Log#Thu_Aug_8.2C_2013 bunny's bom]

https://github.com/OSE/ceb-controller/

=april 7, 2014=

[[User:Dorkmo/Ideas/Forklift]]

sketched an idea for a more tradition forklift attachment.

[[Image:Forklift-idea-dorkmo1.png|400px]]

=feb 21, 2014=

[[Image:DorkmoEarthlodge1.png|100px]]

general idea for a small earth house

[[User:Dorkmo/Ideas/Microhouse_Earth_Lodge]]

=dec 11, 2013=

sketched- added square tube across top of main lifetrac arms to mount 2 cylinders on [https://drive.google.com/file/d/0BwxMMqGvwTM-cno3TXU0RktuZm8/edit?usp=sharing doc]

=dec 9, 2013=

sketched- added the new cyclinders and sketch new mount for lifetrac arms [https://drive.google.com/file/d/0BwxMMqGvwTM-UWlWQlFzRDFPMDg/edit?usp=sharing google doc]

=dec 3, 2013=

did a little idea for mounting trencher on lifetrac [[Media:Trencheridea20131203.torrent]]

started an idea for the [[MicroHouse Collaboration 2014]]. half circle ceb design. roof will slant to center of flat wall. [https://drive.google.com/file/d/0BwxMMqGvwTM-aVZsV1VycnRDdkE/edit?usp=sharing google doc skp - work in progress]

=nov 5, 2013=

machine screw idea for trencher
1-1/2 long. 1/2" nuts are a little less than 1/2 tall, wich will be shorter than the 1/2 thick tooth plate.

[[http://www.fastenal.com/web/products/details/0147968?searchMode=productSearch&zipcode=&filterByStore=&filterByVendingMachine=&productSearchQueryString=term%3D%26termca%3D%26termpx%3D%26sortby%3Dwebrank%26sortdir%3Ddescending%26searchmode%3DproductSearch%26zipcode%3D%26filterByStore%3D%26filterByVendingMachine%3D%26r%3D~|categoryl1%3A%2522600000%2520Fasteners%2522|~%2520~|categoryl2%3A%2522600072%2520Nuts%2522|~%2520~|categoryl3%3A%2522608621%2520Hex%2520Nuts%2522|~%2520~|attrdiameter%3A630|~%2520~|ismadeinusa%3AYes|~ nut]]
[[http://www.fastenal.com/web/products/details/0146829?searchMode=productSearch&zipcode=&filterByStore=&filterByVendingMachine=&productSearchQueryString=term%3D%26termca%3D%26termpx%3D%26sortby%3Dwebrank%26sortdir%3Ddescending%26searchmode%3DproductSearch%26zipcode%3D%26filterByStore%3D%26filterByVendingMachine%3D%26r%3D~|categoryl1%3A%2522600000%2520Fasteners%2522|~%2520~|categoryl2%3A%2522600051%2520Screws%2522|~%2520~|categoryl3%3A%2522600059%2520Machine%2520Screws%2522|~%2520~|sattr02%3A^Flat%24|~%2520~|ismadeinusa%3AYes|~%2520~|attrlength%3A1410|~ bolt]]

could use 3/4" plate for teeth in order to use 3/4" bolts

[[http://www.fastenal.com/web/products/details/0147910?searchMode=productSearch&zipcode=&filterByStore=&filterByVendingMachine=&productSearchQueryString=term%3D%26termca%3D%26termpx%3D%26sortby%3Dwebrank%26sortdir%3Ddescending%26searchmode%3DproductSearch%26zipcode%3D%26filterByStore%3D%26filterByVendingMachine%3D%26r%3D~|categoryl1%3A%2522600000%2520Fasteners%2522|~%2520~|categoryl2%3A%2522600072%2520Nuts%2522|~%2520~|categoryl3%3A%2522608621%2520Hex%2520Nuts%2522|~%2520~|attrdiameter%3A950|~%2520~|ismadeinusa%3AYes|~ nut]]
[[http://www.fastenal.com/web/products/details/28182?searchMode=productSearch&zipcode=&filterByStore=&filterByVendingMachine=&productSearchQueryString=term%3D%26termca%3D%26termpx%3D%26sortby%3Dwebrank%26sortdir%3Ddescending%26searchmode%3DproductSearch%26zipcode%3D%26filterByStore%3D%26filterByVendingMachine%3D%26r%3D~|categoryl1%3A%2522600000%2520Fasteners%2522|~%2520~|categoryl2%3A%2522600051%2520Screws%2522|~%2520~|categoryl3%3A%2522600059%2520Machine%2520Screws%2522|~%2520~|sattr02%3A^Flat%24|~%2520~|attrdiameter%3A950|~%2520~|attrlength%3A1490|~ bolt]]

[[Image:Trenchermachinescrews20131105.png|400px]]

[[Media:Trenchermachinescrews20131105.skp]]

=oct 8, 2013=

backhoe side to side pivot with scissor [[File:Backhoe_sidebyside8.skp]]

[[Image:Pivotscissor.jpg|400px]]

=oct 6, 2013=

did backhoe sketch [[File:Backhoe_sidebyside2.skp]]

=Thu Sep 18, 2013=

==Design Proposals==

===Cab===

Arm mounting shaft split.

[[File:Ltr7-dp-splitarms.skp]]

[[File:Ltr7-dp-splitarms.png|400px]]
=sep 16, 2013=

finished cutting tubing

cleaned up some pivot plates with chisel and file

=sep 15, 2013=

finished 4x4s

cut DOM tubing for pivot plates

tools used:
*band saw
*speed square
*C clamps
*angle iron
*calipers
*steel shims

process description:
*set up an end stop on the band saw
**clamped small piece of angle iron 1/2" away from blade
**used speed square to keep perpindicular
*placed some shims to keep area infront of angle iron level with band saw base
*used some extra tubing with same O.D. to maintain distance of the swivel clamp by placing on opposite side of clamp
*placed tubing to be cut in clamp
*lowered blade to just above tube
*using calipers checked distance
*tightened clamp
*cut
**maintained about 2-3.5 on the hydraulic lowering setting for the kalamazoo brand band saw
*after cut checked width for accuracy
*continued next cut
*durring cutting used file to clean up edges of previously cut tube ring
*set aside for next process

=sep 14, 2013=

cut day 4x4s

tools used:
*speed square
*tape measure
*ruler
*soap stone
*abrasive saw
*big table
*scrap metal for leveling
*power cord

process desription:
*set up cutting area for 10' sections
*marked general location of cut on 4x4
*using ruler found center between holes
*marked center
*used speed square to draw line along center
*checked line with ruler again
*aligned in saw
*tightened into saw
*algined again
*final tighten
*cut
*when abrasive wheel became smaller would rotate 4x4 so that saw would continue previous cut
*marked feet and inches on 4x4
*placed in pile

=sep 13, 2013=

pivot plate

[[File:Pivotplatewide.skp]]

seat

[[File:Seat3550.skp]]

=sep 12, 2013=

cleaned up the workshop a little bit

tweaked a few things on the vw sled
*the lever for the clutch will interfere with current design, need to change something

[[File:Pc50hp33.skp]]

sketched a pivot for the lifetrac6 to be mounted above the top pivot point

[[File:Pivotmount20130912.skp]]

=sep 11, 2013=

*shifted in back instead of lowering it down
*added tanks above pump

[[File:Pc50hp30.skp]]

*flipped around

[[File:Pc50hp31.skp]]

possible double pump [http://www.surpluscenter.com/item.asp?item=9-5012-B&catname=hydraulic]

[http://www.surpluscenter.com/item.asp?item=9-1901-A&catname=hydraulic paired pump]

*picture of holes on engine http://www.huelsmann.us/bugman/FilterTech.html
**looks like should be able to tap and use two side holes as mounts

*vw sled utilizing holes on either side of oil pump plate
**moved tanks around
**added radiator

[[File:Pc50hp32.skp]]

=sep 10, 2013=

*new sled idea for vw
**angle iron base with vibration mounts front and back
**slides into tractor frame, bolts in 4 corners
**accommodates current exhaust system
**double pump possible
*known issues:
**sticks out the back
**still need to do tanks, should fit above bell and pump

[[File:Pc50hp29.skp]]

=sep 9, 2013=

*gary suggested making a angle iron frame that slides into the 4x4 frame
*seems doable, started doing a little brain storming. no model yet.
*swapped some ideas with marcin and lucas about changing a few of the mounting layouts for the arms and pivots

*[[File:LifeTrac6dorkmo20130909.skp]]
*[[File:LifeTrac6dorkmo20130909-3.skp]]

=sep 7, 2013=

*measured and drew bell housing holes
*used angle iron to attach to bell mount plate
*got rid of extra bell mount plate material.
*realigned pump and 4x4 mount

[[File:Osepcvw24.torrent]]

=sep 6, 2013=

cleaned up a few things. no changes.
*https://docs.google.com/file/d/0BwxMMqGvwTM-UGdtYTVlbE4tNVk/edit?usp=sharing

=sep 5, 2013=

did a pc ws version coupled instead of chained n sprocketed. used a 4x4 tube as pump mount.
*https://docs.google.com/file/d/0BwxMMqGvwTM-ZGFaUUJvaVFIZVE/edit?usp=sharing

=sep 4, 2013=

proposal for tractor frame change to mount 4x4 frame on back end.
*https://docs.google.com/file/d/0BwxMMqGvwTM-S09RTVdSTHE1Mms/edit?usp=sharing

=aug 29, 2013=

video of vw mount http://www.youtube.com/watch?v=Pr0UhhC7XpQ

added two angle irons for support on opposite side. may be welded or bolted together.
*https://docs.google.com/file/d/0BwxMMqGvwTM-WllaMV9XeFR5cEE/edit?usp=sharing

=aug 16, 2013=
going out of town. my sketchup work will be on pause.

https://docs.google.com/file/d/0BwxMMqGvwTM-VUJ1azU1aXEzRlU/edit?usp=sharing
*started hose routing
**1-1/2" suction hose has 5" bend radius
**will need to use pressure line with a 45 degree elbow connecting to pump. straight out wont work.
*added rough position of cooler and filter
*bolt conflict with the horizontal and vertical pivot mounts located on the lower front 4x4
**can see a little here [https://www.youtube.com/watch?v=1saG0hIY4bE&feature=youtube_gdata_player video]
*cleaned up [[OSE Torrent Files]] page a little

=aug 15, 2013=
https://docs.google.com/file/d/0BwxMMqGvwTM-RWo5MDhoMVZJSVk/edit?usp=sharing
*added some pipe fittings
**had to trim motor mount
*rough idea for hub to mount motorcycle sproket
*sourced and sketched some Vibration Isolation Mounts Cylindrical Type
**need to move a few things around slightly
**not sure how to get nut on within 4x4
*still need cooler and filter etc

=aug 14, 2013=
[[File:Pc50hp7.skp]]
*added chain and sprocket idea
*added hydraulic pump model
*need to get bolt pattern measurements of bell housing
*need to add hose and cooler models

=aug 13, 2013=

http://opensourceecology.org/wiki/File:LifeTrac6_(dave)(dorkmo)4.skp.torrent

4x4 XYZ frame for mounting VW engine.

http://opensourceecology.org/wiki/Power_Cube_WS#WS.2B

=july 30, 2013=

http://opensourceecology.org/wiki/File:Geardownaxel5.skp.torrent

utilizing steering pivot allows for front and rear drive axles. this theoretically simplifies a geardown. could also allow for simple gear changing by moving motors and other adjustments.

http://opensourceecology.org/wiki/Bulldozer_Geardown

=jun 24, 2013=

[[File:6SPOOLMOUNT.skp]]

[[Image:6spoolmount.png|300px]]

=Sun Jun 23, 2013=
'''The Control Cab Control Panel needs accommodation of:'''
*Power connection to Power Cube (3/4") - up to 4 Power Cubeconnections - let's do this.
*Case drain to Power Cube (1/4") - need to do 4 pairs if using 4 Power Cubes independently.
*6-spool backhoe valve - 1/2"
*2-spool motor valve - 3/4"
*2-spool foot pedals - 3/4"
*Totals
**[8] pairs of 3/4"
**[6] pairs of 1/2"
**[4] singles of 1/4" (just return)

[[Image:hydcontrolpanel.png]]

[[File:HydraulicQAcabmanifold10intermediateuntitled.dxf]]

=Sat Jun 22, 2013=
'''Control panel for hydraulics:'''

working with chris on hose routing for trac
*8 – ¾
*20 – ½
*1 male twords power cube
*valve bolt mounts to 4x4
*[[File:HydraulicQAcabmanifold6intermediate2B.dxf]]
*[[File:HydraulicQAcabmanifold6intermediate2A.dxf]]

=Friday 21, 2013=
==Sprocket Design==
How to design a sprocket - [[Image:chaindrawing.jpg|150px]]

[[File:chain.xcf|100px]] - source in GIMP

See also [[Chain Length Calculator]].

==Resulting Sprockets==
[[File:45T325bore.dxf]]

[[Image:sprocket45.png|200px]]

Sprocket with hub:

[[File:45T325bore1by8.dxf]]

[[Image:sprocketwhub.jpg|200px]]

Use this for cutting. This is just the hub backing plate:

[[File:3hubplate.dxf]]

[[Image:3hubplate.jpg|200px]]

Now the actual sprocket for cutting:

[[File:45T325bore1by8cut.dxf]]

[[Image:sprocketwhubcut.jpg|200px]]

==Lathe Work==
possible motor for lathe [http://www.surpluscenter.com/item.asp?item=9-7467&catname=hydraulic surplus center]

doing a draft with motor mount and threaded rods that tighten to base with some pieces that can c-clamp to base.

[[File:Lathe2.skp]]

[[Image:Lathe5.jpg|400px]]

=Thursday 20, 2013=

drew a rough sketchup of the lathe. going to redo motor mount.
[[File:Lathe1.skp]]

[[Image:Lathe1pic.jpg|400px]]

found this sprocket openscad thing on thingiverse
http://www.thingiverse.com/thing:7918

=Tue Jun 18, 2013=

'''Download DXFs of the 6 parts here - these are 6.26 bolt spacing for these bearings - and DXFs have been corrected for 3/4" bolt holes, meaning 3/4" + 1/16" for CNC torch allowance. [[File:geardownDXF.zip]]'''

[[Image:geardownview.jpg|300px]]
*went back to the basics and cut out intermedate shaft and using a quick attach module style mount.
**requires very large sprocket to achieve desired ratio

*need to change chain cover to accomidate flange bearing bolts sticking through.

[[Image:Geardownpic20130618.jpg|400px]]
[[Image:5xgear.jpg|400px]]
[[Image:Geardownpic20130618-2.jpg|400px]]

==DXF Files of Component Plates for Simple Geardown==
[https://drive.google.com/folderview?id=0BwxMMqGvwTM-N0hmeC1TV3FiZWs&usp=sharing Download DXFs]

=Sat Jun 15, 2013=
'''See also [[Geardown]] Concept.''' Download folder of Sketchup files- [https://drive.google.com/folderview?id=0BwxMMqGvwTM-N092MnBGLU9CdU0&usp=sharing]

[[Image:geardown.png|400px]]

[[Image:geardownsprocket.png|400px]]

added some detail
*bolts for flange bearings
**had to shift some things around to account for tighter space
*added QD bushing for 1-7/8
*changed a couple mounting bolts to frame

=June 8, 2013=

'''Needs discussion of how size can be made more compact'''.

https://docs.google.com/file/d/0BwxMMqGvwTM-RjJxVGNUVm90aVU/edit?usp=sharing

added to the model a mount style with QA facing opposite direction from before
*shortened distance the 2-15/16 bearing hangs out

cleaned up some of the mounting and case holes
*not sure about where the best places are to have mount holes

=June 7, 2013=

https://docs.google.com/file/d/0BwxMMqGvwTM-N1piZlVIaGtqUXc/edit?usp=sharing

started modeling the chain and sprockets.
*looking for collisions
*taking up as much slack of chain in design as possible

=June 1, 2013=

Design Sprint - Dozer Geardown

[[Category:Personal Logs]]
[[Category:CAD team]]

CEB Press Control Code Flowchart

2014-05-15T15:01:16Z

Daniel Benamy: /* Links */

=Code Flowchart=
<html><img src="https://docs.google.com/drawings/d/1POxAtm-XeJK92Vebt9KDyJSC1HON4AoGOCaTgV2YY7A/pub?w=700&h=500"></html>

[https://docs.google.com/a/opensourceecology.org/drawings/d/1POxAtm-XeJK92Vebt9KDyJSC1HON4AoGOCaTgV2YY7A/edit edit]

=Links=
*[[CEB Press Controller Schematic]]
*Credits - James Slade (controller build), Zach Dwiel (code). [[Slade Log]]. [[Zach Dwiel Log]].
*Download - https://github.com/OSE/ceb-controller/archive/master.zip
*[[Zach's CEB Press Controller Schematic]]
*Control logic animation ==Design Description==
<div>
<html><iframe width="400" height="233" src="https://www.youtube.com/embed//0-BRCh19b1Q" frameborder="0" allowfullscreen></iframe>
</html>
*Hydraulic Functional Diagram - [[File:CEBfunctionaldiagram.jpg|200px]]
*Control logic - but from Prototype I - [[CEB_Press_Control_Logic#Control_Logic]]

File:CEB code.rar

2014-05-15T15:00:14Z

Daniel Benamy:

=DO NOT USE THIS FILE=

=DO NOT USE THIS FILE=

=DO NOT USE THIS FILE=

=DO NOT USE THIS FILE=

=DO NOT USE THIS FILE=

==The latest code is at https://github.com/OSE/ceb-controller==

File:CEB code.rar

2014-05-15T14:58:17Z

Daniel Benamy:

=DO NOT USE THIS FILE=

==The latest code is at https://github.com/OSE/ceb-controller==

How to Structure the Wiki for GVCS Machines

2014-03-25T01:03:54Z

Daniel Benamy: /* Version R&D */

=Intro=

Historically the wiki has been a mess. Different machines set up in different ways, info that's hard to find, etc.

In Oct, 2013, we established a template for how to organize the wiki pages for each machine. This template was developed to meet the following requirements:
* One central "home page" for each machine.
* Multiple versions of machines.
* Working on a new version of a machine shouldn't interfere with people wanting to use docs for previous version(s).
* Parallel development of machine modules.
* Parallel building of machine modules.

Many old machines are still a mish mash. When we start new versions of them, please take a few minutes to split the general info from the version-specific info and restructure them like shown here.

This page should probably be better integrated with [[Documentation Standards]], but the author of this page, Dan Benamy, doesn't understand that one and is afraid to mess up what Marcin's trying to do with it.

=Structure=

The overall structure for accessing GVCS machines from the wiki is to start at the GVCS Index, [[GVCS]], which lists and links to all the machines.

Each of those links goes to the ''overall machine'' page which has general info about the machine and links to all versions of the machine. Eg: [[Ironworker]]

Each version of the machine has a main page with the status, development resources, build instructions, and user manuals for that version. Eg: [[Ironworker_3]]. Anything having to do with a version should be on a page "within" the version using a slash. This makes certain automatic wiki links work properly.

* GOOD: Ironworker_3/Research_Development
* BAD: Ironworker_Research_Development_3

=Page Templates=

When you create a new page, copy and paste the relevant template from here to the new page and replace the "TODO"s with the info specific to that page.

==Overall Machine==

http://opensourceecology.org/wiki/Some_Machine:

<pre>
(don't put the GVCS header on this page)

[[Image:TODO Some Machine.jpg|thumb|360px|A nice caption.]]

=Overview=
TODO

=Versions=
==Version 3==
TODO [[Some Machine 3]].

==Version 2==
TODO [[Some Machine 2]].

==Version 1==
TODO [[Some Machine 1]].

=Details=
TODO

=Product Ecology=
TODO

=See Also=
TODO

{{GVCS Footer}}
</pre>

==Version Main Page==

http://opensourceecology.org/wiki/Some_Machine_3 (or whatever version):

<pre>
{{GVCS Header}}

The is the main page for version TODO of the [[TODO Some Machine]]. See that page for general info and how it fits into the GVCS.

=Status=

TODO The first line of the status should be one of the following things:

1. '''This is the development version.''' If you're helping with development, or would like to, this is the version you want. See the "Research and Development" link above for details.
2. '''This is the stable version.''' If you want to build a SOME MACHINE that works, you should use this version.
3. '''This is an old version.''' There are newer and improved version of the [[Some Machine]].
4. '''This is a placeholder for a future version''' so we can start collecting notes about it.

TODO Then there can be more detail. Eg: Version 3 was started in early 2013 and then put on hold. It's being revived in Oct 2013.

(don't put a GVCS footer on this page)
</pre>

==Version R&D==
http://opensourceecology.org/wiki/Some_Machine_3/Research_Development (or whatever version):

There's some disagreement on how to do development boards. Marcin wants a separate board for each module. Dan Benamy and other's argue that this doesn't make sense. You make have to adjust this page depending on how it's done.

<pre>
{{GVCS Header}}

=Development Board=
TODO Update the embed and edit links:
<html><iframe width=80% height='500' frameborder='0' src='https://docs.google.com/spreadsheet/pub?key=YOUR_GOOGLE_SPREADSHEET&output=html&widget=true'></iframe></html>

[https://docs.google.com/spreadsheet/ccc?key=YOUR_GOOGLE_SPREADSHEET#gid=2 edit]

(You can use the above code for the embed and edit link by going to the development board, copying the "key" part of the url, and pasting it in the above urls.)

(no GVCS footer)
</pre>

==Version Bill of Materials==
http://opensourceecology.org/wiki/Some_Machine_3/Bill_of_Materials (or whatever version):

<pre>
{{GVCS Header}}

TODO Generated BOM goes here.
(no GVCS footer)
</pre>

==Version Manufacturing Instructions==
http://opensourceecology.org/wiki/Some_Machine_3/Manufacturing_Instructions (or whatever version):

<pre>
{{GVCS Header}}

=Guides on Dozuki=

==TODO Some Module==

<html>

TODO go to the guide on dozuki, get the embed link, remove the "<a href...></a>" and put the embed code instead of this:
<script type="text/javascript"
data-dozuki-embed='3'
src="http://d1luk0418egahw.cloudfront.net/static/embed/ifixit-embed.3.js#id=83&site=opensourceecology.dozuki.com"></script>

</html>

TODO Replace this link with the regular link to the dozuki guide:
[http://opensourceecology.dozuki.com/Guide/Ironworker+Frame/83/2 Open Full Screen]

==TODO Another Module==

==TODO A Third Module==

==Overall Assembly==
TODO

(no GVCS footer)
</pre>

Ironworker 3/Manufacturing Instructions

2014-01-16T18:15:10Z

Daniel Benamy:

{{GVCS Header}}

=Guides on Dozuki=

The dozuki guides are under active development in Oct 2013. Anything elsewhere should be put into dozuki or archived.

The assembly is broken into modules to facilitate parallel construction. Every module until the last one can be done in parallel if there's enough manpower. Then the final guide shows how to put all the pieces together. Pretty cool, huh? :-)

==Bottom Frame==
http://opensourceecology.dozuki.com/Guide/How+to+assemble+bottom+frame+of+the+Ironworker+%28in+progress%29/85

==Top Frame==
http://opensourceecology.dozuki.com/Guide/How+to+Ironworker+-+Top+Frame+module+%28in+progress%29/86

==Hydraulics==
TODO

==Shear==
http://opensourceecology.dozuki.com/Guide/How+to+assemble+the+shears/88

==Shear Table==
http://opensourceecology.dozuki.com/Guide/How+to+assemble+the+shear+table+of+the+Ironworker+%28in+progress%29/87

==Assembling the Pieces==
http://opensourceecology.dozuki.com/Guide/How+to+Ironworker+Machine+-+Overall+Machine+%28in+progress%29/84

How to Structure the Wiki for GVCS Machines

2014-01-14T12:17:16Z

Daniel Benamy: /* Intro */

=Intro=

Historically the wiki has been a mess. Different machines set up in different ways, info that's hard to find, etc.

In Oct, 2013, we established a template for how to organize the wiki pages for each machine. This template was developed to meet the following requirements:
* One central "home page" for each machine.
* Multiple versions of machines.
* Working on a new version of a machine shouldn't interfere with people wanting to use docs for previous version(s).
* Parallel development of machine modules.
* Parallel building of machine modules.

Many old machines are still a mish mash. When we start new versions of them, please take a few minutes to split the general info from the version-specific info and restructure them like shown here.

This page should probably be better integrated with [[Documentation Standards]], but the author of this page, Dan Benamy, doesn't understand that one and is afraid to mess up what Marcin's trying to do with it.

=Structure=

The overall structure for accessing GVCS machines from the wiki is to start at the GVCS Index, [[GVCS]], which lists and links to all the machines.

Each of those links goes to the ''overall machine'' page which has general info about the machine and links to all versions of the machine. Eg: [[Ironworker]]

Each version of the machine has a main page with the status, development resources, build instructions, and user manuals for that version. Eg: [[Ironworker_3]]. Anything having to do with a version should be on a page "within" the version using a slash. This makes certain automatic wiki links work properly.

* GOOD: Ironworker_3/Research_Development
* BAD: Ironworker_Research_Development_3

=Page Templates=

When you create a new page, copy and paste the relevant template from here to the new page and replace the "TODO"s with the info specific to that page.

==Overall Machine==

http://opensourceecology.org/wiki/Some_Machine:

<pre>
(don't put the GVCS header on this page)

[[Image:TODO Some Machine.jpg|thumb|360px|A nice caption.]]

=Overview=
TODO

=Versions=
==Version 3==
TODO [[Some Machine 3]].

==Version 2==
TODO [[Some Machine 2]].

==Version 1==
TODO [[Some Machine 1]].

=Details=
TODO

=Product Ecology=
TODO

=See Also=
TODO

{{GVCS Footer}}
</pre>

==Version Main Page==

http://opensourceecology.org/wiki/Some_Machine_3 (or whatever version):

<pre>
{{GVCS Header}}

The is the main page for version TODO of the [[TODO Some Machine]]. See that page for general info and how it fits into the GVCS.

=Status=

TODO The first line of the status should be one of the following things:

1. '''This is the development version.''' If you're helping with development, or would like to, this is the version you want. See the "Research and Development" link above for details.
2. '''This is the stable version.''' If you want to build a SOME MACHINE that works, you should use this version.
3. '''This is an old version.''' There are newer and improved version of the [[Some Machine]].
4. '''This is a placeholder for a future version''' so we can start collecting notes about it.

TODO Then there can be more detail. Eg: Version 3 was started in early 2013 and then put on hold. It's being revived in Oct 2013.

(don't put a GVCS footer on this page)
</pre>

==Version R&D==
http://opensourceecology.org/wiki/Some_Machine_3/Research Development (or whatever version):

There's some disagreement on how to do development boards. Marcin wants a separate board for each module. Dan Benamy and other's argue that this doesn't make sense. You make have to adjust this page depending on how it's done.

<pre>
{{GVCS Header}}

=Development Board=
TODO Update the embed and edit links:
<html><iframe width=80% height='500' frameborder='0' src='https://docs.google.com/spreadsheet/pub?key=YOUR_GOOGLE_SPREADSHEET&output=html&widget=true'></iframe></html>

[https://docs.google.com/spreadsheet/ccc?key=YOUR_GOOGLE_SPREADSHEET#gid=2 edit]

(You can use the above code for the embed and edit link by going to the development board, copying the "key" part of the url, and pasting it in the above urls.)

(no GVCS footer)
</pre>

==Version Bill of Materials==
http://opensourceecology.org/wiki/Some_Machine_3/Bill_of_Materials (or whatever version):

<pre>
{{GVCS Header}}

TODO Generated BOM goes here.
(no GVCS footer)
</pre>

==Version Manufacturing Instructions==
http://opensourceecology.org/wiki/Some_Machine_3/Manufacturing_Instructions (or whatever version):

<pre>
{{GVCS Header}}

=Guides on Dozuki=

==TODO Some Module==

<html>

TODO go to the guide on dozuki, get the embed link, remove the "<a href...></a>" and put the embed code instead of this:
<script type="text/javascript"
data-dozuki-embed='3'
src="http://d1luk0418egahw.cloudfront.net/static/embed/ifixit-embed.3.js#id=83&site=opensourceecology.dozuki.com"></script>

</html>

TODO Replace this link with the regular link to the dozuki guide:
[http://opensourceecology.dozuki.com/Guide/Ironworker+Frame/83/2 Open Full Screen]

==TODO Another Module==

==TODO A Third Module==

==Overall Assembly==
TODO

(no GVCS footer)
</pre>

How to Structure the Wiki for GVCS Machines

2014-01-14T12:15:59Z

Daniel Benamy: /* Intro */

=Intro=

Historically the wiki has been a mess. Different machines set up in different ways, info that's hard to find, etc.

In Oct, 2013, we established a template for how to organize the wiki pages for each machine. This template was developed to meet the following requirements:
* One central "home page" for each machine.
* Multiple versions of machines.
* Working on a new version of a machine shouldn't interfere with people wanting to use docs for previous version(s).
* Parallel development of machine modules.
* Parallel building of machine modules.

Many old machines are still a mish mash. When we start new versions of them, take a moment to split about the general and version-specific info and restructure them like shown here.

This page should probably be better integrated with [[Documentation Standards]], but the author of this page, Dan Benamy, doesn't understand that one and is afraid to mess up what Marcin's trying to do with it.

=Structure=

The overall structure for accessing GVCS machines from the wiki is to start at the GVCS Index, [[GVCS]], which lists and links to all the machines.

Each of those links goes to the ''overall machine'' page which has general info about the machine and links to all versions of the machine. Eg: [[Ironworker]]

Each version of the machine has a main page with the status, development resources, build instructions, and user manuals for that version. Eg: [[Ironworker_3]]. Anything having to do with a version should be on a page "within" the version using a slash. This makes certain automatic wiki links work properly.

* GOOD: Ironworker_3/Research_Development
* BAD: Ironworker_Research_Development_3

=Page Templates=

When you create a new page, copy and paste the relevant template from here to the new page and replace the "TODO"s with the info specific to that page.

==Overall Machine==

http://opensourceecology.org/wiki/Some_Machine:

<pre>
(don't put the GVCS header on this page)

[[Image:TODO Some Machine.jpg|thumb|360px|A nice caption.]]

=Overview=
TODO

=Versions=
==Version 3==
TODO [[Some Machine 3]].

==Version 2==
TODO [[Some Machine 2]].

==Version 1==
TODO [[Some Machine 1]].

=Details=
TODO

=Product Ecology=
TODO

=See Also=
TODO

{{GVCS Footer}}
</pre>

==Version Main Page==

http://opensourceecology.org/wiki/Some_Machine_3 (or whatever version):

<pre>
{{GVCS Header}}

The is the main page for version TODO of the [[TODO Some Machine]]. See that page for general info and how it fits into the GVCS.

=Status=

TODO The first line of the status should be one of the following things:

1. '''This is the development version.''' If you're helping with development, or would like to, this is the version you want. See the "Research and Development" link above for details.
2. '''This is the stable version.''' If you want to build a SOME MACHINE that works, you should use this version.
3. '''This is an old version.''' There are newer and improved version of the [[Some Machine]].
4. '''This is a placeholder for a future version''' so we can start collecting notes about it.

TODO Then there can be more detail. Eg: Version 3 was started in early 2013 and then put on hold. It's being revived in Oct 2013.

(don't put a GVCS footer on this page)
</pre>

==Version R&D==
http://opensourceecology.org/wiki/Some_Machine_3/Research Development (or whatever version):

There's some disagreement on how to do development boards. Marcin wants a separate board for each module. Dan Benamy and other's argue that this doesn't make sense. You make have to adjust this page depending on how it's done.

<pre>
{{GVCS Header}}

=Development Board=
TODO Update the embed and edit links:
<html><iframe width=80% height='500' frameborder='0' src='https://docs.google.com/spreadsheet/pub?key=YOUR_GOOGLE_SPREADSHEET&output=html&widget=true'></iframe></html>

[https://docs.google.com/spreadsheet/ccc?key=YOUR_GOOGLE_SPREADSHEET#gid=2 edit]

(You can use the above code for the embed and edit link by going to the development board, copying the "key" part of the url, and pasting it in the above urls.)

(no GVCS footer)
</pre>

==Version Bill of Materials==
http://opensourceecology.org/wiki/Some_Machine_3/Bill_of_Materials (or whatever version):

<pre>
{{GVCS Header}}

TODO Generated BOM goes here.
(no GVCS footer)
</pre>

==Version Manufacturing Instructions==
http://opensourceecology.org/wiki/Some_Machine_3/Manufacturing_Instructions (or whatever version):

<pre>
{{GVCS Header}}

=Guides on Dozuki=

==TODO Some Module==

<html>

TODO go to the guide on dozuki, get the embed link, remove the "<a href...></a>" and put the embed code instead of this:
<script type="text/javascript"
data-dozuki-embed='3'
src="http://d1luk0418egahw.cloudfront.net/static/embed/ifixit-embed.3.js#id=83&site=opensourceecology.dozuki.com"></script>

</html>

TODO Replace this link with the regular link to the dozuki guide:
[http://opensourceecology.dozuki.com/Guide/Ironworker+Frame/83/2 Open Full Screen]

==TODO Another Module==

==TODO A Third Module==

==Overall Assembly==
TODO

(no GVCS footer)
</pre>

How to Structure the Wiki for GVCS Machines

2014-01-14T12:15:02Z

Daniel Benamy: Created page with "=Intro= Historically the wiki has been a mess. Different machines set up in different ways, info that's hard to find, etc. In Oct, 2013, we established a template for how to..."

=Intro=

Historically the wiki has been a mess. Different machines set up in different ways, info that's hard to find, etc.

In Oct, 2013, we established a template for how to organize the wiki pages for each machine. This template was developed to meet the following requirements:
* One central "home page" for each machine.
* Multiple versions of machines.
* Working on a new version of a machine shouldn't interfere with people wanting to use docs for previous version(s).
* Parallel development of machine modules.
* Parallel building of machine modules.

This page should probably be better integrated with [[Documentation Standards]], but the author of this page, Dan Benamy, doesn't understand that one and is afraid to mess up what Marcin's trying to do with it.

=Structure=

The overall structure for accessing GVCS machines from the wiki is to start at the GVCS Index, [[GVCS]], which lists and links to all the machines.

Each of those links goes to the ''overall machine'' page which has general info about the machine and links to all versions of the machine. Eg: [[Ironworker]]

Each version of the machine has a main page with the status, development resources, build instructions, and user manuals for that version. Eg: [[Ironworker_3]]. Anything having to do with a version should be on a page "within" the version using a slash. This makes certain automatic wiki links work properly.

* GOOD: Ironworker_3/Research_Development
* BAD: Ironworker_Research_Development_3

=Page Templates=

When you create a new page, copy and paste the relevant template from here to the new page and replace the "TODO"s with the info specific to that page.

==Overall Machine==

http://opensourceecology.org/wiki/Some_Machine:

<pre>
(don't put the GVCS header on this page)

[[Image:TODO Some Machine.jpg|thumb|360px|A nice caption.]]

=Overview=
TODO

=Versions=
==Version 3==
TODO [[Some Machine 3]].

==Version 2==
TODO [[Some Machine 2]].

==Version 1==
TODO [[Some Machine 1]].

=Details=
TODO

=Product Ecology=
TODO

=See Also=
TODO

{{GVCS Footer}}
</pre>

==Version Main Page==

http://opensourceecology.org/wiki/Some_Machine_3 (or whatever version):

<pre>
{{GVCS Header}}

The is the main page for version TODO of the [[TODO Some Machine]]. See that page for general info and how it fits into the GVCS.

=Status=

TODO The first line of the status should be one of the following things:

1. '''This is the development version.''' If you're helping with development, or would like to, this is the version you want. See the "Research and Development" link above for details.
2. '''This is the stable version.''' If you want to build a SOME MACHINE that works, you should use this version.
3. '''This is an old version.''' There are newer and improved version of the [[Some Machine]].
4. '''This is a placeholder for a future version''' so we can start collecting notes about it.

TODO Then there can be more detail. Eg: Version 3 was started in early 2013 and then put on hold. It's being revived in Oct 2013.

(don't put a GVCS footer on this page)
</pre>

==Version R&D==
http://opensourceecology.org/wiki/Some_Machine_3/Research Development (or whatever version):

There's some disagreement on how to do development boards. Marcin wants a separate board for each module. Dan Benamy and other's argue that this doesn't make sense. You make have to adjust this page depending on how it's done.

<pre>
{{GVCS Header}}

=Development Board=
TODO Update the embed and edit links:
<html><iframe width=80% height='500' frameborder='0' src='https://docs.google.com/spreadsheet/pub?key=YOUR_GOOGLE_SPREADSHEET&output=html&widget=true'></iframe></html>

[https://docs.google.com/spreadsheet/ccc?key=YOUR_GOOGLE_SPREADSHEET#gid=2 edit]

(You can use the above code for the embed and edit link by going to the development board, copying the "key" part of the url, and pasting it in the above urls.)

(no GVCS footer)
</pre>

==Version Bill of Materials==
http://opensourceecology.org/wiki/Some_Machine_3/Bill_of_Materials (or whatever version):

<pre>
{{GVCS Header}}

TODO Generated BOM goes here.
(no GVCS footer)
</pre>

==Version Manufacturing Instructions==
http://opensourceecology.org/wiki/Some_Machine_3/Manufacturing_Instructions (or whatever version):

<pre>
{{GVCS Header}}

=Guides on Dozuki=

==TODO Some Module==

<html>

TODO go to the guide on dozuki, get the embed link, remove the "<a href...></a>" and put the embed code instead of this:
<script type="text/javascript"
data-dozuki-embed='3'
src="http://d1luk0418egahw.cloudfront.net/static/embed/ifixit-embed.3.js#id=83&site=opensourceecology.dozuki.com"></script>

</html>

TODO Replace this link with the regular link to the dozuki guide:
[http://opensourceecology.dozuki.com/Guide/Ironworker+Frame/83/2 Open Full Screen]

==TODO Another Module==

==TODO A Third Module==

==Overall Assembly==
TODO

(no GVCS footer)
</pre>

Ironworker 3/Bill of Materials

2014-01-14T12:08:58Z

Daniel Benamy:

{{GVCS Header}}


<pre>
This BOM was generated from the dozuki guides on 2013-11-16 17:25:37.081000

WARNING: If you hand-edit this list, your changes will be lost when the BOM is regenerated. If anything is wrong, you should update the parts entries in dozuki, fix bom_generator.py, or make a note in a section other than the generated list.

Count Part
----- ----
2 1" x 2" bolts
2 1" x 6" bolts
10 1" x 7" bolts
14 1" x 8" bolts
2 10" x 1" hardened bolts
20 7" x 1" bolts
6 8" x 1" bolts
4 pivot plates without bushings
4.5 ounces of grease
1 oz grease
107 1" nuts
6 1 hole x 5 hole plates
1 1" x 8" x 16" plate
4 2 hole x 2 hole plates
6 2 hole x 3 hole plates
16 2 hole x 4 hole plates
8 pivot plates
2 1" x TODO" threaded robs
2 1" x 15" threaded rods
5 1" x 16" threaded rods
4 13" x 1" threaded rods
4 14" x 1" threaded rods
3 15" x 1" threaded rods
1 16.5" x 1" threaded rod
2 26" x 1" threaded rods
1 3" x 8" solid shaft
2 1" springs
2 1 hole 0.5" tubes
2 1 hole 1/2" tubes
1 1/2" 12 hole tube
2 12 hole 1/2" tubes
1 14 hole 1/2" tube
1 17 hole 1/2" tube
5 19 hole 1/2" tubes
4 2 hole long 1/4" tubes
1 4 hole, 0.25" tube
2 6 hole, 0.25" tubes
59 1" washers

Count: 2, Part: 1" x 2" bolts
Used by: How to assemble all the pieces of the Ironworker (in progress), step 14
Count: 2, Part: 1" x 6" bolts
Used by: How to assemble the shear table of the Ironworker (in progress), step 6
Count: 10, Part: 1" x 7" bolts
Used by: How to assemble the top frame of the Ironworker (in progress), step 7
Used by: How to assemble all the pieces of the Ironworker (in progress), step 18
Count: 14, Part: 1" x 8" bolts
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 7
Used by: How to assemble the top frame of the Ironworker (in progress), step 2
Used by: How to assemble the top frame of the Ironworker (in progress), step 8
Count: 2, Part: 10" x 1" hardened bolts
Used by: How to assemble all the pieces of the Ironworker (in progress), step 5
Used by: How to assemble all the pieces of the Ironworker (in progress), step 4
Count: 20, Part: 7" x 1" bolts
Used by: How to assemble all the pieces of the Ironworker (in progress), step 20
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 5
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 2
Count: 6, Part: 8" x 1" bolts
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 3
Count: 4, Part: pivot plates without bushings
Used by: How to assemble the top frame of the Ironworker (in progress), step 6
Count: 4.5, Part: ounces of grease
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 12
Used by: How to assemble the top frame of the Ironworker (in progress), step 4
Used by: How to assemble all the pieces of the Ironworker (in progress), step 25
Count: 1, Part: oz grease
Used by: How to assemble all the pieces of the Ironworker (in progress), step 9
Count: 107, Part: 1" nuts
Used by: How to assemble the shear table of the Ironworker (in progress), step 1
Used by: How to assemble the shear table of the Ironworker (in progress), step 3
Used by: How to assemble the shear table of the Ironworker (in progress), step 2
Used by: How to assemble the shear table of the Ironworker (in progress), step 4
Used by: How to assemble the shear table of the Ironworker (in progress), step 6
Used by: How to assemble the top frame of the Ironworker (in progress), step 8
Used by: How to assemble the top frame of the Ironworker (in progress), step 6
Used by: How to assemble the top frame of the Ironworker (in progress), step 7
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 10
Used by: How to assemble the top frame of the Ironworker (in progress), step 2
Used by: How to assemble all the pieces of the Ironworker (in progress), step 8
Used by: How to assemble all the pieces of the Ironworker (in progress), step 3
Used by: How to assemble all the pieces of the Ironworker (in progress), step 5
Used by: How to assemble all the pieces of the Ironworker (in progress), step 4
Used by: How to assemble all the pieces of the Ironworker (in progress), step 19
Used by: How to assemble all the pieces of the Ironworker (in progress), step 18
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 9
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 7
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 5
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 3
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 2
Used by: How to assemble all the pieces of the Ironworker (in progress), step 28
Used by: How to assemble all the pieces of the Ironworker (in progress), step 22
Used by: How to assemble all the pieces of the Ironworker (in progress), step 24
Used by: How to assemble all the pieces of the Ironworker (in progress), step 26
Used by: How to assemble the top frame of the Ironworker (in progress), step 10
Count: 6, Part: 1 hole x 5 hole plates
Used by: How to assemble all the pieces of the Ironworker (in progress), step 16
Count: 1, Part: 1" x 8" x 16" plate
Used by: How to assemble all the pieces of the Ironworker (in progress), step 12
Count: 4, Part: 2 hole x 2 hole plates
Used by: How to assemble the top frame of the Ironworker (in progress), step 5
Count: 6, Part: 2 hole x 3 hole plates
Used by: How to assemble the top frame of the Ironworker (in progress), step 7
Used by: How to assemble the top frame of the Ironworker (in progress), step 8
Count: 16, Part: 2 hole x 4 hole plates
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 6
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 5
Used by: How to assemble the top frame of the Ironworker (in progress), step 2
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 3
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 2
Count: 8, Part: pivot plates
Used by: How to assemble the top frame of the Ironworker (in progress), step 4
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 10
Count: 2, Part: 1" x TODO" threaded robs
Used by: How to assemble the shear table of the Ironworker (in progress), step 1
Count: 2, Part: 1" x 15" threaded rods
Used by: How to assemble the top frame of the Ironworker (in progress), step 10
Count: 5, Part: 1" x 16" threaded rods
Used by: How to assemble all the pieces of the Ironworker (in progress), step 28
Used by: How to assemble the shear table of the Ironworker (in progress), step 4
Count: 4, Part: 13" x 1" threaded rods
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 6
Count: 4, Part: 14" x 1" threaded rods
Used by: How to assemble the top frame of the Ironworker (in progress), step 3
Count: 3, Part: 15" x 1" threaded rods
Used by: How to assemble all the pieces of the Ironworker (in progress), step 26
Count: 1, Part: 16.5" x 1" threaded rod
Used by: How to assemble all the pieces of the Ironworker (in progress), step 19
Count: 2, Part: 26" x 1" threaded rods
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 8
Count: 1, Part: 3" x 8" solid shaft
Used by: How to assemble all the pieces of the Ironworker (in progress), step 8
Count: 2, Part: 1" springs
Used by: How to assemble the shear table of the Ironworker (in progress), step 2
Count: 2, Part: 1 hole 0.5" tubes
Used by: How to assemble the shear table of the Ironworker (in progress), step 1
Count: 2, Part: 1 hole 1/2" tubes
Used by: How to assemble all the pieces of the Ironworker (in progress), step 10
Count: 1, Part: 1/2" 12 hole tube
Used by: How to assemble all the pieces of the Ironworker (in progress), step 27
Count: 2, Part: 12 hole 1/2" tubes
Used by: How to assemble all the pieces of the Ironworker (in progress), step 28
Count: 1, Part: 14 hole 1/2" tube
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 1
Count: 1, Part: 17 hole 1/2" tube
Used by: How to assemble the top frame of the Ironworker (in progress), step 1
Count: 5, Part: 19 hole 1/2" tubes
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 1
Used by: How to assemble the top frame of the Ironworker (in progress), step 1
Count: 4, Part: 2 hole long 1/4" tubes
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 9
Count: 1, Part: 4 hole, 0.25" tube
Used by: How to assemble the shear table of the Ironworker (in progress), step 6
Count: 2, Part: 6 hole, 0.25" tubes
Used by: How to assemble the shear table of the Ironworker (in progress), step 3
Used by: How to assemble the shear table of the Ironworker (in progress), step 5
Count: 59, Part: 1" washers
Used by: How to assemble the shear table of the Ironworker (in progress), step 3
Used by: How to assemble the shear table of the Ironworker (in progress), step 2
Used by: How to assemble the shear table of the Ironworker (in progress), step 5
Used by: How to assemble the shear table of the Ironworker (in progress), step 4
Used by: How to assemble the shear table of the Ironworker (in progress), step 6
Used by: How to assemble all the pieces of the Ironworker (in progress), step 24
Used by: How to assemble all the pieces of the Ironworker (in progress), step 5
Used by: How to assemble all the pieces of the Ironworker (in progress), step 4
Used by: How to assemble all the pieces of the Ironworker (in progress), step 20
Used by: How to assemble all the pieces of the Ironworker (in progress), step 28
Used by: How to assemble all the pieces of the Ironworker (in progress), step 22
Used by: How to assemble all the pieces of the Ironworker (in progress), step 19
Used by: How to assemble all the pieces of the Ironworker (in progress), step 18
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 9
Used by: How to assemble the top frame of the Ironworker (in progress), step 10
Used by: How to assemble all the pieces of the Ironworker (in progress), step 14
Used by: How to assemble all the pieces of the Ironworker (in progress), step 26
</pre>

Documentation Standards

2014-01-14T11:54:51Z

Daniel Benamy:

=Introduction=
In Dan Benamy's opinion, this page is confusing and needs some cleanup, focusing, clarifying, and/or splitting up. Normally he do that work but it looks like Marcin set up this page and he doesn't want to get in Marcin's way. Dan will just add a link here to [[How to Structure the Wiki for GVCS Machines]] which he'd normally integrate into the page if he understood it :-)

As OSE moves towards viral replicability, it is important to create effective documentation standards. This applies to the work of OSE and also towards creating a broader platform for open source product development. To this end, we are studying existing open source industry standards - to pick out existing best practice and to integrate these into a larger platform. The strategy is to remix as many existing tools as possible - while inspiring the related players to contribute to a greater platform.

The scope of Open Source Ecology involves machine and organization level items leading to the Open Source Economy. In Phase I (January, 2013), we are defining the standards for the 50 [[GVCS]] machines, which is intended to be a beta test for a larger platform that scales to any number of items - encyclopedic scope. Organizational aspects for creating the open source economy will be developed in Phase II (February, 2013).

The current priority is to standardize a format for documentation on the OSE Wiki.

=Strategy=
*Define problem statements and solutions - [https://docs.google.com/document/d/1K8sx7cYpgwy42m2oK_-HpOSU0fME9AiexZT_CfZ-hzk/edit]

*Seed the process, find Product Owners
*Invite Key Players for review to generate buy-in
*Host a Hackathon to deploy a minimum viable product based on community buy-in
*Keep developing platform
*Monetize platform for self-sustainability of effort

=General Approach=

We would like to develop a platform for uniform acccess to all open hardware, by virtue of defining a content taxonomy. This includes tagging to make Open Source Hardware (OSH) universally findable - so that it can be searched and results displayed. This includes defining uniform content taxonomy and standards (such as CAD, BOM, fabrication drawings, etc.). Define genearally-accepted best practice taxonomy for delivery of content and standards (such as Sketchup model, YouTube video, LibreCAD dxf file, etc). Open Source Warehouse would be a platform where content would be submitted and viewed via an easy-to-use platform.

=User Stories=

We will deploy a community version of the Documentation Platform in April. In February, we will deploy an OSE internal version which can be upgraded by others, with basic functionality that allows us to organize content from the entire wiki. The goal is to index and link to a large quantity of modular content. This modular content can subsequently be displayed in any viewing/structuring platform.

==Replicator==
*As a builder, I want to access the build instructions, videos, and BOMs for a successful build.
*As a replicator, I want to assess the state of completion of the product. I also want to disambiguate between product that does not exist vs. documentation that does not exist. Ie, some Product might be built, but documentation may not exist - so absence of documentation does not necessarily mean absence of product.
*As an open source economist, I need to see the economic analysis to see scaling potential of a manufacturing enterprise for a machine.

==Developer==
*As a developer, I need a place to upload content, and I need a clear structure so that I know where to upload it.
*As a developer working on a further iteration, I need a place to update the documentation without messing up the structure and integrity of prior documenation, because some changes of content also affects other parts of the documentation.
*As a minor developer who made only a small improvement, I need to make sure that my work is documented.
*As a reviewer, I want to see a history of how the machine versions have evolved over time, and I want to see performance calculations to verify them.
*As an information architect, I need to know how the documentation modules fit together.
*As a database designer, I need access to a taxonomy of all the content, and I need a sample of all the modules to test my display methods.
==Publisher==
*As a publisher, I want to publish a machine manual readily.

==Video Editor==

*As a video editor making instructionals, I need access to videos of various builds the results, and issues encountered during builds.
*As an eye-candy video editor, I need footage of sparks flying during production, as well as other flashy footage.
*As an animator, I need to understand the operating principles so I can make an explanatory rendering. I also need access to the 3D objects so I can use them in my animations.

=Basic Wiki Version=
Non-Structured OSHW Documentation:

<html><img src="https://docs.google.com/drawings/d/1wp2VnMd-JYoVDWeiMz-eXDrT-1p7kZUW0eq8BupIYZw/pub?w=543&h=362"></html>

[https://docs.google.com/drawings/d/1wp2VnMd-JYoVDWeiMz-eXDrT-1p7kZUW0eq8BupIYZw/edit edit]

=Sample Implementation=
*See http://openmaterials.org/CEBPress
=Available Documentation Tools=
*[https://cubehero.com/physibles/iamwil/robokitty/history/0cecb53528a7be6eb6236e01f36b7e37dbb260c8/robokitty.stl Visual 3D diffs]

==Working Document==
<html><iframe src="https://docs.google.com/document/pub?id=16Ke8VFmWfh7Q-8BncWqINgyjWSqxuLopT54gdqeQrlU&embedded=true" width=100% height="300" ></iframe></html>

[https://docs.google.com/document/d/16Ke8VFmWfh7Q-8BncWqINgyjWSqxuLopT54gdqeQrlU/edit edit]

=Open Hardware Documentation Outline=

<html><img src="https://docs.google.com/drawings/pub?id=1HJa6yWnQvXVHd72nemBcIkB67-w5RZBMJQlIeyc87M4&w=1200&h=700"></html>

[https://docs.google.com/drawings/d/1HJa6yWnQvXVHd72nemBcIkB67-w5RZBMJQlIeyc87M4/edit edit]

=Documentation Taxonomy=

<html><iframe width=100% height="300" frameborder='0' src='https://docs.google.com/spreadsheet/pub?key=0AkNG-lv1ELQvdHViNEdtVHp4dHRWOU8tcDNSbXROY3c&output=html&widget=true'></iframe> </html>

[https://docs.google.com/spreadsheet/ccc?key=0AkNG-lv1ELQvdHViNEdtVHp4dHRWOU8tcDNSbXROY3c#gid=2 edit]

==Samples==
*[[CEB Press Test]] in Mediawiki
*[http://www.openmaterials.org/CEBpress/ CEB Press example in Wordpress]:

<html><iframe src="http://www.openmaterials.org/CEBpress/" width=100% height="300"> </iframe></html>

=Information Architecture=
<html><img src="https://docs.google.com/drawings/d/1MUl31a7eFGNMFVP90Gq_mXiJ4d0U3Jgdw776z5qG1kE/pub?w=1124&h=3081"></html>

[https://docs.google.com/drawings/d/1MUl31a7eFGNMFVP90Gq_mXiJ4d0U3Jgdw776z5qG1kE/edit edit

=Documentation Platform - Entity Relationship Diagram=
Architecture for programming the user platform:

<html><img src="https://docs.google.com/drawings/d/1ZNT1_rhLgRAqDk_8qyQ3eRGgANCs7-HV5oA37o10M44/pub?w=1796&h=870"></html>

[https://docs.google.com/drawings/d/1ZNT1_rhLgRAqDk_8qyQ3eRGgANCs7-HV5oA37o10M44/edit edit]

=Documentation Workshop Organization=
*[[OSHW Documentation Hackathon]]
*Workshop planning - [https://docs.google.com/document/d/1z0sFINK3R9m-0nyKqczuTvB_GpafzLzxdb0SVexPe8s/edit]
*Chat with [[Joe Justice]] - [https://docs.google.com/document/d/1f176sOOQuCcZu9wx9KnSJexLyXg27_7708oqnougNL8/edit]
*OSHWA consultation - [https://docs.google.com/document/d/1EKHo-Y-etpVO3x13mJo0JXuNmD_CErqhjx6JYiM8tEU/edit]

=OSHW Documentation Handbook=

<html><iframe src="https://docs.google.com/document/d/1VeUbM1rLz_E9cQwIDfWvVJvCKwo3pktdVdREAZpy6Dc/pub?embedded=true" width=100% height="300"></iframe> </html>

[https://docs.google.com/document/d/1VeUbM1rLz_E9cQwIDfWvVJvCKwo3pktdVdREAZpy6Dc/edit#heading=h.91ba5gj5ki8u edit]

=Documentation Platform Principles or Specification=
*Language agnostic platform
*Readily publishable in part or in full in hard copy or digital copy
*Promotes the open source economy and distributive enterprise
*Clear contributor agreements and user license
*Work Product is a Protocol, not Platform. Distinction is Protocol can be implemented on any platform.
*Platform, hardware, and software agnostic. Uses open software formats; accepts proprietary formats so they can be translated.
*Contains a commit and quality assurance mechanism
*Upvotability and quality upgrade mechanism, versioning
*Modular design of documentation, clear modularity standards for how documentation components fit together, and easy interfaceability between modules
*Resource Description Format markup for semantic web compatibility. Tagging and markup for mashup and remix purposes. API for interoperability with other platforms.
*Breadcrumbs - location guide or secondary navigation scheme
*Well-defined tagging standards.
*Entry-level access for contributors (not a geek protocol)
*Entry-level access for developers
*Incentivizes participation with other open source and closed source platforms.
*Glossary is incuded, platform is self-explanatory.
*Meritocratic governance
*Provides an assessment mechanism for 'state of open-sourceness' of projects
*Facilitates quantitative assessment or statistics about open hardware projects in general
*Encourages DIY projects to join open source economic framework, and invites uninitiated DIY projects to add value to their work and to the world by making their work more visible
*Fosters Technical Literacy
*Ready verifiability of results
*Backup strategy well-defined
*Contributor rights clearly defined and designed as a Badge or Distinction. Crowd sourced contributions from users and developers; careful log of contributors

==Work Product==
<html><img src="https://docs.google.com/drawings/pub?id=1khu6oUh-gWeN3UUc3k_lMM3lxmNt3vPJPuir6bxg9fE&w=480&h=360"></html>

[https://docs.google.com/drawings/d/1khu6oUh-gWeN3UUc3k_lMM3lxmNt3vPJPuir6bxg9fE/edit edit]

==Value Proposition==
The value that we propose to add to defining documentation standards is:
*Basing platform on existing tools - building on open source industry standards and using non-open source tools only if necessary until they can be substituted.
*Developing interfaces between existing tools, not developing new tools (remixing and mashup)
*Documenting that interface with Brick Press as our test case
*Defining a protocol for documentation based on existing tools
*Getting feedback from the greater community, and defining a role for a Documentation Director for Scalable Open Source Product Distributive Enterprise Development Projects.

=Documentation Design Rationale=
The scope of effective documentation standards for OSE includes Machine, Organizational, and Wiki level areas of documentation.
==Organizatinal Level==
*The organizational level involves documentation related to running a GVCS-based development, production, or other applied project.
*Enterprise development documentation.

==Machine Level==
*Understanding the standards makes it possible to navigate both graphically and via the address bar on the OSE wiki - to access any piece of documentation for any machine.
*Machine naming is standard. Currently, the names used on the main site at opensourceecology.org are used.
*Each machine has a Core and Supporting documentation set. The Core set includes those pieces of documentation that are indispensible for the safe and effective building and usage of GVCS tools by inexperienced builders/users. Supporting documentation is that which allows for the modification, remixing of modules, and other hacks on the machines. It also includes that information which makes replication easier, but which is not critical to such replication - by a novice builder.
*Each Machine has a finite, well-defined set of Core Documentation and Supporting Documentation.
*Supporting Documentation consists of Wiki-level (such as Links section or Index) and Machine-level items (such as CAE analysis - noncritical but desirable for replication)
*Standards are consistent with [[Open Source Hardware Association Open Source Hardware Definition]].

==Wiki Level==
*Each machine has a particular set of wiki-level Supporting Documenation items - such as Links (example below). Standards are defined for each of these Supporting Documentation item

=Specific Wiki Page Structure=
Current work on [[Frame_DXF_Files]] indicates that a rigorous structure of documentation needs to occur for completeness. This structure should be represented as an infographic with design rationale (for documentation steps) captured.

=Links=
==Past Work of OSE==
*See video in [[Shuttleworth Fellowship 2013 Submission]] - overview of prototyping and documentation goals. Read entire application.
*[[OSE Specifications]] - value proposition of Open Source Ecology
*[[Open Source Hardware Modularity Pattern Language]] - technology primitives, GVCS-centric
*[[Open Source Technology Pattern Language]] - technology primitives, GVCS-centric
*Kickstarter shows a good overview of what proper documentation includes - see minute 1:22 at [http://www.kickstarter.com/projects/622508883/global-village-construction-set Kickstarter campaign of 2011].
*[[Communications Strategy]]
*[[GVCS Interface Design Standards]]
*See also [[Documentation_Standards_Development]]
*See also [[Process Documentation Standards]] and [[Process Documentation Standards Abstract]]
*[[Documentation Standards]] - beginning on documentation
*[[Flashy XM]] is an experimental platform in progress, but it does not make the critical distinction between Documentation and Development.
*GVCS tool template from 2011 - [[Template:ToolTemplate]] - an actual template in Media Wiki
*More detailed template for each page - see [[Template:CEB Press Manufacturing Instructions Navbox]] and [http://opensourceecology.org/wiki/Ceb_drawer this example of Brick Press Drawer].
*See [[Documentation Standards Old]]
*[[GVCS Interface Design Standards]]
*[[OSE Machine Development Process]]
*[[OSE Machine Documentation Process]]
*[[Fabrication Diagram]]
*[[Development Work Template]]

==Related Work==

*[[Open Hardware Repository]]
*http://www.ohanda.org/
*http://oshwa.org
*Make Projects - http://makeprojects.com/
*OKFN [http://design.okfn.org/about/ Open Design Definition]
*[[IKEA Furniture Documentation Standards]]
*Check out Army Manuals standards for documentation. What other best practice manuals are there? Check the [[Noun Project]].
*Open H20 standards development - [http://www.flickr.com/photos/worldworldworld/8244521061/in/photostream/lightbox/]
*[[Documentation Standards Development]]
*OS Hardware for Humanitarian Aid - [https://docs.google.com/document/d/1nBWYX7G3UFdcoiRZotQVvH0jRc7ljNuwxSpUcuKWz6c/edit]
*[http://www.ladyada.net/library/openhardware/whatisit.html LadyAda's Layers of Licensing]
*[http://www.oshwa.org/faq/ OSHWA's FAQ - What files do I need to share?]
*[http://www.oshwa.org/sharing-best-practices/ OSHWA's Sharing Best Practices]
*Open Source Hardware group on Google
*[[Vinay Gupta]]
*[[Extreme Modularity Resource Map]]
*[[WikiHouse]]
*[[SKDB]] - great theory, limited execution

==Meta==
*Resource Description Framework (RDF) - [http://www.w3.org/TR/2004/REC-rdf-primer-20040210/]. From Wikipedia article - Creative Commons - Uses RDF to embed license information in web pages and mp3 files.
*Semantic Media Wiki extension - SMW adds semantic annotations that allow a wiki to function as a collaborative database - [http://semantic-mediawiki.org/wiki/Help:Introduction_to_Semantic_MediaWiki]
*[http://challenge.semanticweb.org/ Semantic Web Challenge]
*[http://semantic-mediawiki.org/wiki/Project_Halo Project Halo] - ''The appendix to Paul Allen's new book, Idea Man, describes several challenges in artificial intelligence for which Project Halo is actively seeking solutions. We are actively seeking people and organizations with serious and well-grounded technical ideas that can result in significant progress against these challenges. Please use the Idea Submission Form to contact us with a sketch of your idea, along with any supporting evidence that it will be successful. '''Please do not send confidential or proprietary information to Project Halo using this site or through any other means.''''' - see http://www.projecthalo.com/

==Literature==
*Open Source Product Development - Springer Gabler - 2011 - [http://www.springer.com/springer+gabler/management/book/978-3-8349-3153-5]. [http://download.springer.com/static/pdf/378/bfm%253A978-3-8349-6949-1%252F1.pdf?auth66=1361290845_6147f8cd8157909dc0dc00ece9e00b0f&ext=.pdf Table of Contents]

==Open Source Hardware Project Listings==
*[[Open Source Hardware Projects]]

[[Category:Documentation]]
[[Category:Standards]]

Tracks

2014-01-14T10:25:52Z

Daniel Benamy: At least some of this way out of date or duplicate. Replaced with redirect to Get involved.

#REDIRECT [[Get involved]]

Get involved

2014-01-14T10:21:44Z

Daniel Benamy:

Take a look at http://opensourceecology.org/join.php

Get involved

2014-01-14T10:20:05Z

Daniel Benamy: Moved to Creating Writing a Get Involved Page

#REDIRECT [http://opensourceecology.org/join.php]

Writing a Get Involved Page

2014-01-14T10:17:06Z

Daniel Benamy: Moved from Get involved

Karien Bezuidenhout: http://www.greenpeace.org/international/en/getinvolved/

[11:59:02] Karien Bezuidenhout: http://www.charitywater.org/getinvolved/

[11:59:16] Karien Bezuidenhout: http://www.ready.gov/get-involved

[11:59:35] Karien Bezuidenhout: http://www.cancer.org/involved/

[12:01:26] Karien Bezuidenhout: above = get involved

[12:01:32] Karien Bezuidenhout: below = call to action

[12:01:40] Karien Bezuidenhout: http://blog.crazyegg.com/2013/07/24/call-to-action-examples/

[12:01:52] Karien Bezuidenhout: http://smallbusiness.yahoo.com/advisor/7-effective-call-action-examples-why-133741481.html

[12:02:02] Karien Bezuidenhout: http://www.smartbugmedia.com/blog/bid/164393/Get-Clicked-14-Examples-of-Amazing-Calls-to-Action

[12:02:16] Karien Bezuidenhout: http://www.seocopywriting.com/content-marketing/tips-and-strategy/7-call-action-techniques-work/

[12:04:10] Call from Karien Bezuidenhout, duration 43:37.

Ironworker 3/Manufacturing Instructions

2014-01-14T05:43:38Z

Daniel Benamy:

CNC Torch Table 2/Control Overview

2013-11-01T15:34:10Z

Daniel Benamy: /* Testing */

{{Template:Category=Torch Table}}

=Overview=
<html><img src="https://docs.google.com/drawings/pub?id=1SKGaBa6N21DPzXm9ILuqwPubc6nnRSBAARbkKaEU9hw&w=480&h=360"></html>

=Motor controller and drivers=

==RAMPS==
Dan's using [[RAMPS]] in Oct 2013 to get the table up and running ASAP. The plan is then to replace it with something beefier so we can go faster.

==Alternatives==
See [[Stepper Motor Controller]] and [[Stepper Motor Driver]].

=Software=

==G-code Prep==
[[File:Toolchain.svg|thumb|toolchain pathways]]
[[ImplicitCAD]] (see also [[Parametric_Design_Pilot_Project]])

[[Gcodetools]]

[[DXF_to_G-code_Conversion_Tutorial]]

[[Computer_to_Microcontroller]]

Nesting software would be useful. Example commercial product [http://www.mynesting.com/ here]. Anything open source?

[[DXF_to_G-code_Conversion_Tutorial#Piercing|Gcode preheat]]

Correction for torch cut kerf width ("cutter compensation" in CNC lingo) needed. G40/G41 but grbl does not interpret these.

==G Code Runner==
aka firmware aka motor controller (distinct from motor driver)

This is the firmware running on Arduino which converts a series of G-code commands to step/direction pulses for the drivers.

===Marlin===
When Dan Benamy was getting things going again in Oct 2013, he was using Marlin because grbl doesn't work with RAMPS out of the box. Marlin also has pretty much out of the box support for 2 drivers feeding 2 motors on Y which we use for out long axis because it has 2 motors.

* I cloned marlin from github and checked out the Marlin_v1 tag.
* Edited Configuration.h
** #define MOTHERBOARD 35
** #define DISABLE_E true // For all extruders
** #define TEMP_SENSOR_0 0 // Since we don't have temp sensors
** #define TEMP_SENSOR_1 0 // Since we don't have temp sensors
** #define DEFAULT_AXIS_STEPS_PER_UNIT {128.9304,142.5,200.0*8/3,760*1.1} // nov 1 2013- x and y are the right ballpark for the ose torch table at fef, see https://github.com/OSE/CNC-Torch-Table-OSE/issues/4#issuecomment-27460371 for where these numbers came from
** I set the "*ENDSTOP_INVERTING" consts as appropriate for our endstops by running gcode M119, seeing if an endstop was triggered, pushing the button, and running M119 again. If the logic was backwards, I flipped the appropriate boolean.
** I set the travel limits. There are 6 starting with "X_MAX_POS". I set the mins to 0. I set x and y max to 300 and z max to 150 for testing. Once we're calibrated and the table is fixed, we'll make these much bigger.
* I made home = 0,0,0 = the corner of the torch table near the ping pong table with the tool head fully down. Then I can stand at one end of the table and look down at it and it the standard x is right, y is up orientation. And when looking at it from the side, positive z is up.
* Edited Configuration_adv.h
** Uncommented "#define Y_DUAL_STEPPER_DRIVERS". I used Y because Marlin doesn't support dual drivers on X. We'll use Y as the long axis, X as the short axis, and Z as height. The 2nd Y will be output on the 2nd extruder port (E1, http://reprap.org/wiki/RAMPS_1.4#Wiring)
* Edited pins.h
** In the section for motherboards 33, 34 35, added "#define Y2_STEP_PIN 36", "#define Y2_DIR_PIN 34", and "#define Y2_ENABLE_PIN 30". This is a Marlin bug and I've submitted a fix upstream- https://github.com/ErikZalm/Marlin/pull/635
* Opened Marlin/Marlin/Marlin.pde in the arduino ide and clicked to compile and load it to the arduino.

=== grbl ===
When someone (Chuck?) was working on using the steppernug, they were running a modified grbl fork https://github.com/chuck-h/grbl/tree/edge. Changes from standard grbl [https://github.com/grbl/grbl]:
* Hardware I/O reassignment for steppernug interface
** different pin assignments on Arduino
** I2C extender
* substantially revised [[CNC_Torch_Table_Control_Overview#Limits_and_Homing|homing code]]
** dual X axis
** deep changes to stepper drive algorithm (implementing independent-axis trapezoidal move control during homing, as opposed to standard coordinated-axis move control for cutting) which should improve performance on long, limited-aceleration axes like torch table X and Y.

==Sending G Code to Firmware==

In Oct 2013, Dan can't find host software (gcode sending) that works with marlin. He tried about 8 different programs. For now the process is to use Printrun/Pronterface and copy/paste 3 or so gcodes at a time into there, wait for them to execute, and run the next batch. Pasting them all at once fails (machine does the wrong thing) probably because the instruction buffer in marlin isn't big enough.

See [[GcodeCommunications]] for a list of programs to send the g-code file from a host computer to a controller.

===Hardware===
Talk to Arduino with USB, or for longer distance RS422 e.g. [http://www.mouser.com/ProductDetail/Maxim-Integrated-Products/MAX3488ECSA+/?qs=sGAEpiMZZMvbyeSUH4qH%2fEqdkzg%252bEBoj MAX3488E]

== Testing ==
[[Stepper_Testing|Testing]]

Here's a test gcode file which Dan Benamy hand wrote. It works on marlin and draws a 2 hole by 1 hole plate- https://github.com/OSE/CNC-Torch-Table-OSE/issues/20

=Limits and Homing=

This whole section hasn't been updated for the Oct 2013 work using RAMPS. See https://github.com/OSE/CNC-Torch-Table-OSE/issues/11 for some of this with RAMPS setup.

Also note that docs from before Oct 2013 refer to the long axis as X but with RAMPS and marlin we had to make the long axis Y.

==Dual-motor homing==
The x axis (long axis) has 2 stepper motors. In the steppernug system, these have separate driver modules which receive identical step, direction, and enable signals.

For zeroing, the x axis needs to decouple - so if we get the x axis out of parallel, we can jog the x axes back into parallel by hitting their home switches independently. Steppernug supports this by allowing the Arduino to control a gate which blocks step pulses to the second driver module; in this condition the second motor will freeze and only the first motor will move. There is no provision for moving the second motor without moving the first, but that function is not required for the homing algorithm.

==Axis sequence==
# We will home the Z axis to its upper position first, just in case there are obstructions to clear during the X and Y axis homing.
# X and Y axes will do their initial fast moves to find home simultaneously (overlapped homing) to save time.
# The Y precision home movement will be performed.
# The dual-X-axis precision home maneuver will be performed.

==Limit and home switch configuration==

[[File:HomeLimit.PNG]]

''(TODO: add illustration showing distance coded reference mark options)''

''(Unconfirmed proposal at this time)'' [[User:ChuckH|ChuckH]] 23:42, 20 October 2012 (CEST)

Each axis has two switches: a '''limit switch''' and a '''home switch'''.
* The '''limit switch''' is activated at *either* end of travel. Its function is to protect against machine damage.
** Attempting to move further into the limit when the limit switch is active will cause all axis movement to stop, the torch to be shut off, and any other "safe shutdown" operation to be performed.
** The limit switch could be hit if the program erroneously commands the tool to move beyond the edge of the table
** The limit switch could also be hit if the torch table loses step (e.g. by hitting an obstruction) and subsequently performs a movement which takes it to the edge of the table
** The limit switch ''may'' be implemented as two physical switches wired in parallel, or the machine construction may permit a single switch to be used.
** Repeatable precision of actuation point is not very critical.
** This function is especially important if the table is expected to do automated cutting without constant human supervision.
* The '''home switch''' transitions between inactive and active at a point partway through the legal travel of the machine.
** For example, it might be active at the negative end of travel, and go inactive after 6 inches of movement.
** The home switch is used only for locating a repeatable zero position when the machine is powered on (or when recovering from lost steps)
*** Note that the logical "machine zero" coordinate may be placed at any programmed position relative to the physical home switch.
** Repeatable precision may be important
*** For the dual-motor axis, to establish accurate squareness
*** For all axes, to pick up in the middle of an interrupted job
*** If fixturing is used for repeat "production style" operations
** (''update, 14-July-2103:'') Instead of responding to a single flag location, the home switch could be actuated many times by multiple flags along the travel, with carefully designed nonuniform spacing between flags
*** This implements "distance coded reference marks" (DCRM), e.g. [[http://www.rls.si/en/dcrm-distance-coded-reference-mark-system--15934]], [[http://www.heidenhain.de/presentation/posa/en/index/N10584/N108A7/N10926.html]], [[http://www.newall.com/upload/content/file/SHG-TC%20-%20Distance-Coded%20Protocol%20-%20USA%20Ver%2004-07-05.pdf]]
*** DCRM is often applied to incremental linear encoder systems; the same principle is effective here using motor step count as the "incremental scale".
*** Using DCRM, the axis only needs to traverse two flag transitions after startup in order to unambiguously determine absolute position.
** By construction, the home switch is active at one end of travel and inactive at the other
*** This allows the machine to know which end of travel it is at in the event the limit switch is activated
*** This, in turn, allows the machine to permit recovery movement from the limit condition back into legal travel, while ignoring a command to go further into the limit zone.

There is an alternative switch configuration which places individual limit switches at the positive and negative limits of legal travel. However the configuration above is preferred because it supports faster homing and simpler control logic. Specifically:
# The substantial distance between the end of travel and the home switch location gives the machine overtravel room to do a controlled stop from high speed: maximum slewing speed can be used during initial homing without risk of slamming into the physical end-of-travel.
# Home switch placement can minimize the typical startup time.
#* If an axis is usually parked near one end of travel, the home switch can be placed there
#* If the axis position on startup is random, placing the home switch in the center of travel will minimize the average seek time.
#* DCRM can be implemented to obtain short startup/home times no matter what the starting position.
# The "safety shutdown" limit-switch function can be always active, and is independent of homing
#* The alternative approach requires logically repurposing a limit switch as home switch during home operations

==Switch Types==

The steppernug interface provides 5V power to sensor switches so either electronic or mechanical switches are easily accommodated.
* Mechanical microswitches are simple and effective.
* A Hall switch (e.g. [[Hall_Effect_Sensor_Module|this]]) is rugged but its position precision is probably only suitable for limits, not home switches.
* An optical interrupter (e.g. [http://www.mouser.com/ProductDetail/Sharp-Microelectronics/GP1A75EJ000F/?qs=%2fha2pyFaduhmXejJv184BikaBEqZykWweNnmsglkeuWVbMieAKIiNg%3d%3d Sharp GP1A75EJ000F]) can give precisely repeatable homing.

== Switch response time ==

The home switch should respond within one motor step time at the "creep speed" used for final approach. This speed might be ~100 steps/sec which gives us ~10ms.

The limit switch should respond quickly enough so that an emergency stop initiated by the switch will stop the machine motion before it hits a mechanical stop. This time is dependent on a lot of different design parameters, but is probably at least 10ms.

The limited response speed required allows us some latitude for noise suppression.

Since all switch signals pass through the I2C expander for I/O, there is about 150 usec (0.15ms) added, see [[Stepper_Testing#timing|here]].

=Torch control=

Software can use an M code to start the cut (e.g. open cutting-oxygen valve, strike plasma arc).

A second M code could shut down the entire torch (e.g. at the end of an unsupervised cutting session).

See also [[CNC_Torch_Table/Research_Development#Cutting_Torch]]

==Plasma Torch==

[[Plasma_Cutter_Design#Plasma_Cutter_PC_Interface]]

[http://www.metalwebnews.com/howto/plasma/presentation.pdf This presentation] on plasma-cutting accurate holes also suggests that ramping down plasma current while torch is still moving is good practice. (It makes the electrodes last longer.)

[[Sensing_Distance_from_Work_Piece|Z-axis arc voltage height control]]. Needs design work.

[[Plasma_Cutter_Cut_Speed_as_a_Function_of_Metal_Thickness|Cutting speed]]

Hypertherm:

[[File:PlasmaSpeed.jpg|400px]]

==Oxyfuel (oxyacetylene, oxypropane, etc) cutting torch==

During cutting, an oxyfuel cutting torch is literally burning the steel with a blast of oxygen; most of the heat comes from oxidizing the iron. However to start a new cut ("piercing") you must preheat the steel, relying on the acetylene or LPG for heat. After the steel is red hot you boost the oxygen flow and make the cut. We will want an oxygen-rated valve controlled by the microprocessor. "Oxygen-rated" mostly means the valve is thoroughly cleaned of all oil or flammable solvents that tend to explode on contact with pure oxygen; good practical reference [http://www.gmcscuba.com/pdf/CONVERTING%20DIVE%20TANKS%20FOR%20OXYGEN%20SERVICE.pdf here]. A solenoid valve like [http://www.lesman.com/acatalog/ASCO_8210_Oxygen-Service_Valves.html this] in combination with an ordinary regulator would give basic on/off control, but see better suggestions below.

Fairly technical application note about how to do good oxyfuel machine cutting from ESAB: [http://www.esabna.com/literature/Gas%20Apparatus/Miscellaneous/Oxy-Fuel_Cutting_Quality_0558006464.pdf]

[http://www.cnczone.com/forums/cnc_plasma_waterjet_machines/98346-cnc_oxy_fuel_discussion-25.html#post778595 This] ''long'' forum thread contains a lot of information about implementing small-shop CNC oxyfuel with programmed preheat, pierce, and cutting gas controls, auto ignition, etc. Based partly on this information, here are some control design suggestions for an Arduino-based CNC like [[CoolRAMPS]] or [[CNC_Torch_Table_Control_Overview#Steppernug_Driver_and_Interface_.28alternative_to_CoolRamps.29|Steppernug/grbl]]:
* use dome loaded regulators (e.g. Victor DL700 [http://www.amazon.com/Victor-0780-1188-DL700-500-Dome-Regulator/dp/B0047684PG] [http://victortechnologies.com/IM_Uploads/doclib_8016_DocLib_2331_56-0679%20%20DL%20700%20External%20Dome-Loaded%20Regulator%20Part%20Bulletin.pdf]) driven by regulated shop air [[File:DL700.png|thumb]] [[File:VTS250.png|thumb]]
** general description of spring- and dome-loaded regulators [http://www.documentation.emersonprocess.com/groups/public/documents/bulletins/debul2008x012.pdf here]
** It appears that almost any standard screw-handle regulator can be converted to "dome loaded" by sealing up the housing cap and replacing the screw/spring with an air pressure fitting. See video below. A classic dual-stage like the [http://victortechnologies.com/IM_Uploads/doclib_8039_DocLib_2310_56-0623%20VTS%20250%20Series%20Regulators.pdf VTS250] should work very nicely for conversion
** As with manual regulators, if oxy- or fuel-tank pressure exceeds inlet rating of dome-loaded regulator, a first-stage tank regulator will be required.
** With the dome-loaded regulators, gas on/off as well as pressure setting can be obtained with low-cost shop air components and small valves (e.g [http://www.ebay.com/itm/4V130C-06-DC24V-Solenoid-Air-Valve-5-port-3-position-/290652595990 4V130C],[http://www.automationdirect.com/adc/Shopping/Catalog/Pneumatic_Components/Pneumatic_Valves_-a-_Accessories/Solenoid_Air_Valves_-a-_Accessories/5-port_(4-way),_3-pos.,_Body_Ported_-z-_Manifold_(AVS-5,AM_Series)/AVS-523C1-24D AVS-523C1])
** Using a [http://www.digikey.com/product-detail/en/MPXHZ6400AC6T1/MPXHZ6400AC6T1CT-ND/2057456 solid-state pressure sensor] for feedback, the Arduino can set the regulated pressures to programmed levels by actuating the pneumatic valves (increase/decrease loading pressure until feedback is correct). See video below and code on [http://github.com/chuck-h/ose-gaspressurecontrol github].
* use an electric igniter ([http://www.rvpartwholesaler.com/servlet/the-31/Dometic-2931132019-Refrigerator-Reignitor/Detail RV fridge igniter], [http://www.amazon.com/GrillPro-20620-Electric-Button-Igniter/dp/B000FJVKNM BBQ igniter], [https://www.sparkfun.com/products/11218 spark coil]).
* follow the sequencing of x,y,z motions, pressure changes, on/off, and ignition described by the folks on the forum thread above.
** Develop a library of pressure/time/positioning parameters for different material thicknesses and tip sizes that can be applied automatically by the G-code programming; this should minimize setup time and tweaking.

<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=H3Z3EHqTn44"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=WcUnHnZJ8xU"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=uwCbohxajOY"}
)
</script>
</html>

Installing a [http://www.clippard.com/part/MNV-1K needle valve] at the solenoid air valve improved control smoothness a bit compared to video above.

[[Image:ClippardNeedle.jpg|300px]]

=== oxygen ===

The cutting oxygen for the torch must be high purity (according to the ESAB note above less than 95% purity simply will not cut steel, and >99.5% is required for best quality). Until recently, this meant cryogenically separated oxygen, depending on a large capital plant, and thus the user must rely on commercially provided tank oxygen. For some 30 years, [http://en.wikipedia.org/wiki/Pressure_swing_adsorption pressure-swing-adsorption (PSA) separators] have been available, but standard designs do not remove argon and therefore result in about 95%-oxygen, 5%-argon output gas. PSA construction is low-tech and works very nicely at small scale, e.g. portable breathing-oxygen units, and would be quite suitable for OSE. 95% purity is probably adequate for the preheat flame (ChuckH conjecture). For higher-purity cutting oxygen, PSA can be extended with additional zeolite materials [http://www.ou.edu/class/che-design/a-design/projects-2007/Oxygen%20Generator-Presentation.pdf] or activated carbon [http://www.airsepcpd.com/airsepcpd/pdfs/12779.pdf]; despite [http://cr4.globalspec.com/blogentry/20384/To-Build-an-Oxygen-Concentrator-or-Not this discussion] there is no clear record of small-scale DIY implementation of 99% oxygen PSA.

=== oxyacetylene ===

Recommendations from Victor:

[[File:Victor_Oxy_Acetylene.jpg]]

Commercial oxy-fuel machine cutting heads
* [http://www.pierce.cz/production/components-for-building-and-retrofiting-cutting-machines/autogenni-motorizovana-rezaci-hlava.htm?lang=en Czech] one with capacitive height sensor feature

Components offered by JB: [[CNC_Torch_Table_Log#Oct._21.2C_2012]]

== Oxy-propane, -natural gas, etc ==
[http://www.cousesteel.com/AndysPlace/PropaneAcetylene.html Propane] instead of acetylene. Note the large preheat oxygen flow (not in a consistent stoichiometric ratio to fuel) in this chart. Odd.

[[File:VictorLPGcutting.png]]

Would [[Gasifier|gasifier-gas]] or [[biogas]] & oxygen work? Probably, as natural gas is primarily methane and is a commercially successful cutting-torch fuel.

=See Also=
[[Distributed_CNC_Motion_Control]]

[[Category:CNC Torch Table Prototype II]]
[[Category:Vann]]

CNC Torch Table 2/Control Overview

2013-11-01T15:26:59Z

Daniel Benamy: /* Marlin */

{{Template:Category=Torch Table}}

=Overview=
<html><img src="https://docs.google.com/drawings/pub?id=1SKGaBa6N21DPzXm9ILuqwPubc6nnRSBAARbkKaEU9hw&w=480&h=360"></html>

=Motor controller and drivers=

==RAMPS==
Dan's using [[RAMPS]] in Oct 2013 to get the table up and running ASAP. The plan is then to replace it with something beefier so we can go faster.

==Alternatives==
See [[Stepper Motor Controller]] and [[Stepper Motor Driver]].

=Software=

==G-code Prep==
[[File:Toolchain.svg|thumb|toolchain pathways]]
[[ImplicitCAD]] (see also [[Parametric_Design_Pilot_Project]])

[[Gcodetools]]

[[DXF_to_G-code_Conversion_Tutorial]]

[[Computer_to_Microcontroller]]

Nesting software would be useful. Example commercial product [http://www.mynesting.com/ here]. Anything open source?

[[DXF_to_G-code_Conversion_Tutorial#Piercing|Gcode preheat]]

Correction for torch cut kerf width ("cutter compensation" in CNC lingo) needed. G40/G41 but grbl does not interpret these.

==G Code Runner==
aka firmware aka motor controller (distinct from motor driver)

This is the firmware running on Arduino which converts a series of G-code commands to step/direction pulses for the drivers.

===Marlin===
When Dan Benamy was getting things going again in Oct 2013, he was using Marlin because grbl doesn't work with RAMPS out of the box. Marlin also has pretty much out of the box support for 2 drivers feeding 2 motors on Y which we use for out long axis because it has 2 motors.

* I cloned marlin from github and checked out the Marlin_v1 tag.
* Edited Configuration.h
** #define MOTHERBOARD 35
** #define DISABLE_E true // For all extruders
** #define TEMP_SENSOR_0 0 // Since we don't have temp sensors
** #define TEMP_SENSOR_1 0 // Since we don't have temp sensors
** #define DEFAULT_AXIS_STEPS_PER_UNIT {128.9304,142.5,200.0*8/3,760*1.1} // nov 1 2013- x and y are the right ballpark for the ose torch table at fef, see https://github.com/OSE/CNC-Torch-Table-OSE/issues/4#issuecomment-27460371 for where these numbers came from
** I set the "*ENDSTOP_INVERTING" consts as appropriate for our endstops by running gcode M119, seeing if an endstop was triggered, pushing the button, and running M119 again. If the logic was backwards, I flipped the appropriate boolean.
** I set the travel limits. There are 6 starting with "X_MAX_POS". I set the mins to 0. I set x and y max to 300 and z max to 150 for testing. Once we're calibrated and the table is fixed, we'll make these much bigger.
* I made home = 0,0,0 = the corner of the torch table near the ping pong table with the tool head fully down. Then I can stand at one end of the table and look down at it and it the standard x is right, y is up orientation. And when looking at it from the side, positive z is up.
* Edited Configuration_adv.h
** Uncommented "#define Y_DUAL_STEPPER_DRIVERS". I used Y because Marlin doesn't support dual drivers on X. We'll use Y as the long axis, X as the short axis, and Z as height. The 2nd Y will be output on the 2nd extruder port (E1, http://reprap.org/wiki/RAMPS_1.4#Wiring)
* Edited pins.h
** In the section for motherboards 33, 34 35, added "#define Y2_STEP_PIN 36", "#define Y2_DIR_PIN 34", and "#define Y2_ENABLE_PIN 30". This is a Marlin bug and I've submitted a fix upstream- https://github.com/ErikZalm/Marlin/pull/635
* Opened Marlin/Marlin/Marlin.pde in the arduino ide and clicked to compile and load it to the arduino.

=== grbl ===
When someone (Chuck?) was working on using the steppernug, they were running a modified grbl fork https://github.com/chuck-h/grbl/tree/edge. Changes from standard grbl [https://github.com/grbl/grbl]:
* Hardware I/O reassignment for steppernug interface
** different pin assignments on Arduino
** I2C extender
* substantially revised [[CNC_Torch_Table_Control_Overview#Limits_and_Homing|homing code]]
** dual X axis
** deep changes to stepper drive algorithm (implementing independent-axis trapezoidal move control during homing, as opposed to standard coordinated-axis move control for cutting) which should improve performance on long, limited-aceleration axes like torch table X and Y.

==Sending G Code to Firmware==

In Oct 2013, Dan can't find host software (gcode sending) that works with marlin. He tried about 8 different programs. For now the process is to use Printrun/Pronterface and copy/paste 3 or so gcodes at a time into there, wait for them to execute, and run the next batch. Pasting them all at once fails (machine does the wrong thing) probably because the instruction buffer in marlin isn't big enough.

See [[GcodeCommunications]] for a list of programs to send the g-code file from a host computer to a controller.

===Hardware===
Talk to Arduino with USB, or for longer distance RS422 e.g. [http://www.mouser.com/ProductDetail/Maxim-Integrated-Products/MAX3488ECSA+/?qs=sGAEpiMZZMvbyeSUH4qH%2fEqdkzg%252bEBoj MAX3488E]

== Testing ==
[[Stepper_Testing|Testing]]

Here's a test gcode file which Dan Benamy hand wrote. It works on marlin and draws a 2 hole by 1 hole plate- https://github.com/OSE/CNC-Torch-Table-OSE/issues/20#issuecomment-27547764

=Limits and Homing=

This whole section hasn't been updated for the Oct 2013 work using RAMPS. See https://github.com/OSE/CNC-Torch-Table-OSE/issues/11 for some of this with RAMPS setup.

Also note that docs from before Oct 2013 refer to the long axis as X but with RAMPS and marlin we had to make the long axis Y.

==Dual-motor homing==
The x axis (long axis) has 2 stepper motors. In the steppernug system, these have separate driver modules which receive identical step, direction, and enable signals.

For zeroing, the x axis needs to decouple - so if we get the x axis out of parallel, we can jog the x axes back into parallel by hitting their home switches independently. Steppernug supports this by allowing the Arduino to control a gate which blocks step pulses to the second driver module; in this condition the second motor will freeze and only the first motor will move. There is no provision for moving the second motor without moving the first, but that function is not required for the homing algorithm.

==Axis sequence==
# We will home the Z axis to its upper position first, just in case there are obstructions to clear during the X and Y axis homing.
# X and Y axes will do their initial fast moves to find home simultaneously (overlapped homing) to save time.
# The Y precision home movement will be performed.
# The dual-X-axis precision home maneuver will be performed.

==Limit and home switch configuration==

[[File:HomeLimit.PNG]]

''(TODO: add illustration showing distance coded reference mark options)''

''(Unconfirmed proposal at this time)'' [[User:ChuckH|ChuckH]] 23:42, 20 October 2012 (CEST)

Each axis has two switches: a '''limit switch''' and a '''home switch'''.
* The '''limit switch''' is activated at *either* end of travel. Its function is to protect against machine damage.
** Attempting to move further into the limit when the limit switch is active will cause all axis movement to stop, the torch to be shut off, and any other "safe shutdown" operation to be performed.
** The limit switch could be hit if the program erroneously commands the tool to move beyond the edge of the table
** The limit switch could also be hit if the torch table loses step (e.g. by hitting an obstruction) and subsequently performs a movement which takes it to the edge of the table
** The limit switch ''may'' be implemented as two physical switches wired in parallel, or the machine construction may permit a single switch to be used.
** Repeatable precision of actuation point is not very critical.
** This function is especially important if the table is expected to do automated cutting without constant human supervision.
* The '''home switch''' transitions between inactive and active at a point partway through the legal travel of the machine.
** For example, it might be active at the negative end of travel, and go inactive after 6 inches of movement.
** The home switch is used only for locating a repeatable zero position when the machine is powered on (or when recovering from lost steps)
*** Note that the logical "machine zero" coordinate may be placed at any programmed position relative to the physical home switch.
** Repeatable precision may be important
*** For the dual-motor axis, to establish accurate squareness
*** For all axes, to pick up in the middle of an interrupted job
*** If fixturing is used for repeat "production style" operations
** (''update, 14-July-2103:'') Instead of responding to a single flag location, the home switch could be actuated many times by multiple flags along the travel, with carefully designed nonuniform spacing between flags
*** This implements "distance coded reference marks" (DCRM), e.g. [[http://www.rls.si/en/dcrm-distance-coded-reference-mark-system--15934]], [[http://www.heidenhain.de/presentation/posa/en/index/N10584/N108A7/N10926.html]], [[http://www.newall.com/upload/content/file/SHG-TC%20-%20Distance-Coded%20Protocol%20-%20USA%20Ver%2004-07-05.pdf]]
*** DCRM is often applied to incremental linear encoder systems; the same principle is effective here using motor step count as the "incremental scale".
*** Using DCRM, the axis only needs to traverse two flag transitions after startup in order to unambiguously determine absolute position.
** By construction, the home switch is active at one end of travel and inactive at the other
*** This allows the machine to know which end of travel it is at in the event the limit switch is activated
*** This, in turn, allows the machine to permit recovery movement from the limit condition back into legal travel, while ignoring a command to go further into the limit zone.

There is an alternative switch configuration which places individual limit switches at the positive and negative limits of legal travel. However the configuration above is preferred because it supports faster homing and simpler control logic. Specifically:
# The substantial distance between the end of travel and the home switch location gives the machine overtravel room to do a controlled stop from high speed: maximum slewing speed can be used during initial homing without risk of slamming into the physical end-of-travel.
# Home switch placement can minimize the typical startup time.
#* If an axis is usually parked near one end of travel, the home switch can be placed there
#* If the axis position on startup is random, placing the home switch in the center of travel will minimize the average seek time.
#* DCRM can be implemented to obtain short startup/home times no matter what the starting position.
# The "safety shutdown" limit-switch function can be always active, and is independent of homing
#* The alternative approach requires logically repurposing a limit switch as home switch during home operations

==Switch Types==

The steppernug interface provides 5V power to sensor switches so either electronic or mechanical switches are easily accommodated.
* Mechanical microswitches are simple and effective.
* A Hall switch (e.g. [[Hall_Effect_Sensor_Module|this]]) is rugged but its position precision is probably only suitable for limits, not home switches.
* An optical interrupter (e.g. [http://www.mouser.com/ProductDetail/Sharp-Microelectronics/GP1A75EJ000F/?qs=%2fha2pyFaduhmXejJv184BikaBEqZykWweNnmsglkeuWVbMieAKIiNg%3d%3d Sharp GP1A75EJ000F]) can give precisely repeatable homing.

== Switch response time ==

The home switch should respond within one motor step time at the "creep speed" used for final approach. This speed might be ~100 steps/sec which gives us ~10ms.

The limit switch should respond quickly enough so that an emergency stop initiated by the switch will stop the machine motion before it hits a mechanical stop. This time is dependent on a lot of different design parameters, but is probably at least 10ms.

The limited response speed required allows us some latitude for noise suppression.

Since all switch signals pass through the I2C expander for I/O, there is about 150 usec (0.15ms) added, see [[Stepper_Testing#timing|here]].

=Torch control=

Software can use an M code to start the cut (e.g. open cutting-oxygen valve, strike plasma arc).

A second M code could shut down the entire torch (e.g. at the end of an unsupervised cutting session).

See also [[CNC_Torch_Table/Research_Development#Cutting_Torch]]

==Plasma Torch==

[[Plasma_Cutter_Design#Plasma_Cutter_PC_Interface]]

[http://www.metalwebnews.com/howto/plasma/presentation.pdf This presentation] on plasma-cutting accurate holes also suggests that ramping down plasma current while torch is still moving is good practice. (It makes the electrodes last longer.)

[[Sensing_Distance_from_Work_Piece|Z-axis arc voltage height control]]. Needs design work.

[[Plasma_Cutter_Cut_Speed_as_a_Function_of_Metal_Thickness|Cutting speed]]

Hypertherm:

[[File:PlasmaSpeed.jpg|400px]]

==Oxyfuel (oxyacetylene, oxypropane, etc) cutting torch==

During cutting, an oxyfuel cutting torch is literally burning the steel with a blast of oxygen; most of the heat comes from oxidizing the iron. However to start a new cut ("piercing") you must preheat the steel, relying on the acetylene or LPG for heat. After the steel is red hot you boost the oxygen flow and make the cut. We will want an oxygen-rated valve controlled by the microprocessor. "Oxygen-rated" mostly means the valve is thoroughly cleaned of all oil or flammable solvents that tend to explode on contact with pure oxygen; good practical reference [http://www.gmcscuba.com/pdf/CONVERTING%20DIVE%20TANKS%20FOR%20OXYGEN%20SERVICE.pdf here]. A solenoid valve like [http://www.lesman.com/acatalog/ASCO_8210_Oxygen-Service_Valves.html this] in combination with an ordinary regulator would give basic on/off control, but see better suggestions below.

Fairly technical application note about how to do good oxyfuel machine cutting from ESAB: [http://www.esabna.com/literature/Gas%20Apparatus/Miscellaneous/Oxy-Fuel_Cutting_Quality_0558006464.pdf]

[http://www.cnczone.com/forums/cnc_plasma_waterjet_machines/98346-cnc_oxy_fuel_discussion-25.html#post778595 This] ''long'' forum thread contains a lot of information about implementing small-shop CNC oxyfuel with programmed preheat, pierce, and cutting gas controls, auto ignition, etc. Based partly on this information, here are some control design suggestions for an Arduino-based CNC like [[CoolRAMPS]] or [[CNC_Torch_Table_Control_Overview#Steppernug_Driver_and_Interface_.28alternative_to_CoolRamps.29|Steppernug/grbl]]:
* use dome loaded regulators (e.g. Victor DL700 [http://www.amazon.com/Victor-0780-1188-DL700-500-Dome-Regulator/dp/B0047684PG] [http://victortechnologies.com/IM_Uploads/doclib_8016_DocLib_2331_56-0679%20%20DL%20700%20External%20Dome-Loaded%20Regulator%20Part%20Bulletin.pdf]) driven by regulated shop air [[File:DL700.png|thumb]] [[File:VTS250.png|thumb]]
** general description of spring- and dome-loaded regulators [http://www.documentation.emersonprocess.com/groups/public/documents/bulletins/debul2008x012.pdf here]
** It appears that almost any standard screw-handle regulator can be converted to "dome loaded" by sealing up the housing cap and replacing the screw/spring with an air pressure fitting. See video below. A classic dual-stage like the [http://victortechnologies.com/IM_Uploads/doclib_8039_DocLib_2310_56-0623%20VTS%20250%20Series%20Regulators.pdf VTS250] should work very nicely for conversion
** As with manual regulators, if oxy- or fuel-tank pressure exceeds inlet rating of dome-loaded regulator, a first-stage tank regulator will be required.
** With the dome-loaded regulators, gas on/off as well as pressure setting can be obtained with low-cost shop air components and small valves (e.g [http://www.ebay.com/itm/4V130C-06-DC24V-Solenoid-Air-Valve-5-port-3-position-/290652595990 4V130C],[http://www.automationdirect.com/adc/Shopping/Catalog/Pneumatic_Components/Pneumatic_Valves_-a-_Accessories/Solenoid_Air_Valves_-a-_Accessories/5-port_(4-way),_3-pos.,_Body_Ported_-z-_Manifold_(AVS-5,AM_Series)/AVS-523C1-24D AVS-523C1])
** Using a [http://www.digikey.com/product-detail/en/MPXHZ6400AC6T1/MPXHZ6400AC6T1CT-ND/2057456 solid-state pressure sensor] for feedback, the Arduino can set the regulated pressures to programmed levels by actuating the pneumatic valves (increase/decrease loading pressure until feedback is correct). See video below and code on [http://github.com/chuck-h/ose-gaspressurecontrol github].
* use an electric igniter ([http://www.rvpartwholesaler.com/servlet/the-31/Dometic-2931132019-Refrigerator-Reignitor/Detail RV fridge igniter], [http://www.amazon.com/GrillPro-20620-Electric-Button-Igniter/dp/B000FJVKNM BBQ igniter], [https://www.sparkfun.com/products/11218 spark coil]).
* follow the sequencing of x,y,z motions, pressure changes, on/off, and ignition described by the folks on the forum thread above.
** Develop a library of pressure/time/positioning parameters for different material thicknesses and tip sizes that can be applied automatically by the G-code programming; this should minimize setup time and tweaking.

<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=H3Z3EHqTn44"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=WcUnHnZJ8xU"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=uwCbohxajOY"}
)
</script>
</html>

Installing a [http://www.clippard.com/part/MNV-1K needle valve] at the solenoid air valve improved control smoothness a bit compared to video above.

[[Image:ClippardNeedle.jpg|300px]]

=== oxygen ===

The cutting oxygen for the torch must be high purity (according to the ESAB note above less than 95% purity simply will not cut steel, and >99.5% is required for best quality). Until recently, this meant cryogenically separated oxygen, depending on a large capital plant, and thus the user must rely on commercially provided tank oxygen. For some 30 years, [http://en.wikipedia.org/wiki/Pressure_swing_adsorption pressure-swing-adsorption (PSA) separators] have been available, but standard designs do not remove argon and therefore result in about 95%-oxygen, 5%-argon output gas. PSA construction is low-tech and works very nicely at small scale, e.g. portable breathing-oxygen units, and would be quite suitable for OSE. 95% purity is probably adequate for the preheat flame (ChuckH conjecture). For higher-purity cutting oxygen, PSA can be extended with additional zeolite materials [http://www.ou.edu/class/che-design/a-design/projects-2007/Oxygen%20Generator-Presentation.pdf] or activated carbon [http://www.airsepcpd.com/airsepcpd/pdfs/12779.pdf]; despite [http://cr4.globalspec.com/blogentry/20384/To-Build-an-Oxygen-Concentrator-or-Not this discussion] there is no clear record of small-scale DIY implementation of 99% oxygen PSA.

=== oxyacetylene ===

Recommendations from Victor:

[[File:Victor_Oxy_Acetylene.jpg]]

Commercial oxy-fuel machine cutting heads
* [http://www.pierce.cz/production/components-for-building-and-retrofiting-cutting-machines/autogenni-motorizovana-rezaci-hlava.htm?lang=en Czech] one with capacitive height sensor feature

Components offered by JB: [[CNC_Torch_Table_Log#Oct._21.2C_2012]]

== Oxy-propane, -natural gas, etc ==
[http://www.cousesteel.com/AndysPlace/PropaneAcetylene.html Propane] instead of acetylene. Note the large preheat oxygen flow (not in a consistent stoichiometric ratio to fuel) in this chart. Odd.

[[File:VictorLPGcutting.png]]

Would [[Gasifier|gasifier-gas]] or [[biogas]] & oxygen work? Probably, as natural gas is primarily methane and is a commercially successful cutting-torch fuel.

=See Also=
[[Distributed_CNC_Motion_Control]]

[[Category:CNC Torch Table Prototype II]]
[[Category:Vann]]

GcodeCommunications

2013-11-01T07:38:13Z

Daniel Benamy: /* Repetier */

==Intro==
When using a [[CNC]] machine, there needs to be a program which sends the gcode created on a computer, to the motor controller which executes the gcode by moving around the motors.

== Gctrl ==
[[Gctrl]](cross-platform)

== Gcodesender ==
[http://www.shapeoko.com/wiki/index.php/Assembly_step_15 gcodesender](Windows).

==Printrun==
[http://reprap.org/wiki/Printrun Printrun] is a gcode sender that's supposed to have good support for RAMPS.

In Oct 2013, Dan used it for manual control and entering gcodes, but couldn't get it to send a file.

To get going, change baud rate to 250000 and click connect.

== ReplicatorG ==
http://replicat.org/

Seems not to have support for marlin.

== grbl-controller ==

http://zapmaker.org/projects/grbl-controller-3-0/

== Repetier ==

Beautiful, open source, versions for windows, linux, and mac. Very easy to configure.

In Oct 2013, Dan couldn't get it to run gcode files although it's got some nice manual control features.

== RepSnapper ==
https://github.com/timschmidt/repsnapper

In Oct 2013, build of master on osx failed.

== Universal G-code Sender ==
[https://github.com/winder/Universal-G-Code-Sender Universal G-Code Sender].

This is recommended for grbl. As of Oct 2013, it's supposed to have imperfect support for Marlin.

=== Universal G-code Sender on Raspberry Pi ===
[[File:GCodeOnRPi.png|thumb|300px|Raspberry Pi with grbl and steppernug]]

[[RaspberryPi]] is a very small, low-cost, single-board open-source computer. Although Universal G-code Sender is distributed as a self-contained "One-jar" package that handles its own dependencies, it needs a little help on the arm-linux platform. I believe it misidentifies arm-linux as intel-linux and tries to use an x86 communications driver. Therefore we need to provide our own version of the communications library and manually unpack Universal G-code Sender.

These instructions were developed on a Raspbian Wheezy installation downloaded from [http://www.raspberrypi.org/downloads]. Here is the OS identification:
<pre>
pi@raspberrypi ~ $ uname -a
Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux
</pre>

Install java and comms driver prerequisites
<pre>
sudo apt-get install openjdk-7-jre
sudo apt-get install librxtx-java
</pre>
''Note'' I installed openjdk-7-jdk, but I don't think it's necessary; the jre should be adequate.

download UniversalGcodeSender-v1.0.5-all32.zip from https://github.com/winder/Universal-G-Code-Sender/tree/master/releases

<pre>
unzip UniversalGcodeSender-v1.0.5-all32.zip
jar -xf UniversalGcodeSender-all32.jar
cd lib
jar -xf swing-layout-1.0.4.jar
cd ../main
export CLASSPATH=$CLASSPATH:.:/usr/share/java/RXTXcomm.jar:../lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jni
</pre>
To make the Arduino Uno comm port (ttyACM0) visible, you need to start the application with a command-line parameter
<pre>
java -Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0:/dev/ttyUSB0:/dev/ttyAMA0 com.willwinder.universalgcodesender.MainWindow
</pre>
Be patient, it takes about 20 seconds to start the application.

[[File:UniversalGcodeSender.png|500px|border]]

For minimum-cost implementation of CNC, it would be nice if the g-code sender interface could run from the composite TV-out of the Raspberry Pi (assuming an old TV may be cheaper than an HDMI/DVI monitor). Unfortunately, however, the UI doesn't fit:

[[File:GCodeSender tvres.png]]

== Other ==
Other options for gcode streaming [https://github.com/grbl/grbl/wiki/Using-Grbl here].

CNC Torch Table 2/Research Development

2013-11-01T05:51:47Z

Daniel Benamy:

CNC Torch Table 2/Research Development

2013-11-01T05:50:10Z

Daniel Benamy: /* Status */

CNC Torch Table 2/Research Development

2013-11-01T05:47:49Z

Daniel Benamy: /* Next Steps */

GcodeCommunications

2013-11-01T05:47:00Z

Daniel Benamy: /* RepSnapper */

==Intro==
When using a [[CNC]] machine, there needs to be a program which sends the gcode created on a computer, to the motor controller which executes the gcode by moving around the motors.

== Gctrl ==
[[Gctrl]](cross-platform)

== Gcodesender ==
[http://www.shapeoko.com/wiki/index.php/Assembly_step_15 gcodesender](Windows).

==Printrun==
[http://reprap.org/wiki/Printrun Printrun] is a gcode sender that's supposed to have good support for RAMPS.

In Oct 2013, Dan used it for manual control and entering gcodes, but couldn't get it to send a file.

To get going, change baud rate to 250000 and click connect.

== ReplicatorG ==
http://replicat.org/

Seems not to have support for marlin.

== grbl-controller ==

http://zapmaker.org/projects/grbl-controller-3-0/

== Repetier ==

Beautiful, open source, for macs. Very easy to configure.

In Oct 2013, Dan couldn't get it to run gcode files although it's got some nice manual control features.

== RepSnapper ==
https://github.com/timschmidt/repsnapper

In Oct 2013, build of master on osx failed.

== Universal G-code Sender ==
[https://github.com/winder/Universal-G-Code-Sender Universal G-Code Sender].

This is recommended for grbl. As of Oct 2013, it's supposed to have imperfect support for Marlin.

=== Universal G-code Sender on Raspberry Pi ===
[[File:GCodeOnRPi.png|thumb|300px|Raspberry Pi with grbl and steppernug]]

[[RaspberryPi]] is a very small, low-cost, single-board open-source computer. Although Universal G-code Sender is distributed as a self-contained "One-jar" package that handles its own dependencies, it needs a little help on the arm-linux platform. I believe it misidentifies arm-linux as intel-linux and tries to use an x86 communications driver. Therefore we need to provide our own version of the communications library and manually unpack Universal G-code Sender.

These instructions were developed on a Raspbian Wheezy installation downloaded from [http://www.raspberrypi.org/downloads]. Here is the OS identification:
<pre>
pi@raspberrypi ~ $ uname -a
Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux
</pre>

Install java and comms driver prerequisites
<pre>
sudo apt-get install openjdk-7-jre
sudo apt-get install librxtx-java
</pre>
''Note'' I installed openjdk-7-jdk, but I don't think it's necessary; the jre should be adequate.

download UniversalGcodeSender-v1.0.5-all32.zip from https://github.com/winder/Universal-G-Code-Sender/tree/master/releases

<pre>
unzip UniversalGcodeSender-v1.0.5-all32.zip
jar -xf UniversalGcodeSender-all32.jar
cd lib
jar -xf swing-layout-1.0.4.jar
cd ../main
export CLASSPATH=$CLASSPATH:.:/usr/share/java/RXTXcomm.jar:../lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jni
</pre>
To make the Arduino Uno comm port (ttyACM0) visible, you need to start the application with a command-line parameter
<pre>
java -Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0:/dev/ttyUSB0:/dev/ttyAMA0 com.willwinder.universalgcodesender.MainWindow
</pre>
Be patient, it takes about 20 seconds to start the application.

[[File:UniversalGcodeSender.png|500px|border]]

For minimum-cost implementation of CNC, it would be nice if the g-code sender interface could run from the composite TV-out of the Raspberry Pi (assuming an old TV may be cheaper than an HDMI/DVI monitor). Unfortunately, however, the UI doesn't fit:

[[File:GCodeSender tvres.png]]

== Other ==
Other options for gcode streaming [https://github.com/grbl/grbl/wiki/Using-Grbl here].

GcodeCommunications

2013-11-01T05:46:42Z

Daniel Benamy: /* ReplicatorG */

==Intro==
When using a [[CNC]] machine, there needs to be a program which sends the gcode created on a computer, to the motor controller which executes the gcode by moving around the motors.

== Gctrl ==
[[Gctrl]](cross-platform)

== Gcodesender ==
[http://www.shapeoko.com/wiki/index.php/Assembly_step_15 gcodesender](Windows).

==Printrun==
[http://reprap.org/wiki/Printrun Printrun] is a gcode sender that's supposed to have good support for RAMPS.

In Oct 2013, Dan used it for manual control and entering gcodes, but couldn't get it to send a file.

To get going, change baud rate to 250000 and click connect.

== ReplicatorG ==
http://replicat.org/

Seems not to have support for marlin.

== grbl-controller ==

http://zapmaker.org/projects/grbl-controller-3-0/

== Repetier ==

Beautiful, open source, for macs. Very easy to configure.

In Oct 2013, Dan couldn't get it to run gcode files although it's got some nice manual control features.

== RepSnapper ==
https://github.com/timschmidt/repsnapper

== Universal G-code Sender ==
[https://github.com/winder/Universal-G-Code-Sender Universal G-Code Sender].

This is recommended for grbl. As of Oct 2013, it's supposed to have imperfect support for Marlin.

=== Universal G-code Sender on Raspberry Pi ===
[[File:GCodeOnRPi.png|thumb|300px|Raspberry Pi with grbl and steppernug]]

[[RaspberryPi]] is a very small, low-cost, single-board open-source computer. Although Universal G-code Sender is distributed as a self-contained "One-jar" package that handles its own dependencies, it needs a little help on the arm-linux platform. I believe it misidentifies arm-linux as intel-linux and tries to use an x86 communications driver. Therefore we need to provide our own version of the communications library and manually unpack Universal G-code Sender.

These instructions were developed on a Raspbian Wheezy installation downloaded from [http://www.raspberrypi.org/downloads]. Here is the OS identification:
<pre>
pi@raspberrypi ~ $ uname -a
Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux
</pre>

Install java and comms driver prerequisites
<pre>
sudo apt-get install openjdk-7-jre
sudo apt-get install librxtx-java
</pre>
''Note'' I installed openjdk-7-jdk, but I don't think it's necessary; the jre should be adequate.

download UniversalGcodeSender-v1.0.5-all32.zip from https://github.com/winder/Universal-G-Code-Sender/tree/master/releases

<pre>
unzip UniversalGcodeSender-v1.0.5-all32.zip
jar -xf UniversalGcodeSender-all32.jar
cd lib
jar -xf swing-layout-1.0.4.jar
cd ../main
export CLASSPATH=$CLASSPATH:.:/usr/share/java/RXTXcomm.jar:../lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jni
</pre>
To make the Arduino Uno comm port (ttyACM0) visible, you need to start the application with a command-line parameter
<pre>
java -Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0:/dev/ttyUSB0:/dev/ttyAMA0 com.willwinder.universalgcodesender.MainWindow
</pre>
Be patient, it takes about 20 seconds to start the application.

[[File:UniversalGcodeSender.png|500px|border]]

For minimum-cost implementation of CNC, it would be nice if the g-code sender interface could run from the composite TV-out of the Raspberry Pi (assuming an old TV may be cheaper than an HDMI/DVI monitor). Unfortunately, however, the UI doesn't fit:

[[File:GCodeSender tvres.png]]

== Other ==
Other options for gcode streaming [https://github.com/grbl/grbl/wiki/Using-Grbl here].

GcodeCommunications

2013-11-01T05:44:46Z

Daniel Benamy: /* Printrun */

==Intro==
When using a [[CNC]] machine, there needs to be a program which sends the gcode created on a computer, to the motor controller which executes the gcode by moving around the motors.

== Gctrl ==
[[Gctrl]](cross-platform)

== Gcodesender ==
[http://www.shapeoko.com/wiki/index.php/Assembly_step_15 gcodesender](Windows).

==Printrun==
[http://reprap.org/wiki/Printrun Printrun] is a gcode sender that's supposed to have good support for RAMPS.

In Oct 2013, Dan used it for manual control and entering gcodes, but couldn't get it to send a file.

To get going, change baud rate to 250000 and click connect.

== ReplicatorG ==
http://replicat.org/

== grbl-controller ==

http://zapmaker.org/projects/grbl-controller-3-0/

== Repetier ==

Beautiful, open source, for macs. Very easy to configure.

In Oct 2013, Dan couldn't get it to run gcode files although it's got some nice manual control features.

== RepSnapper ==
https://github.com/timschmidt/repsnapper

== Universal G-code Sender ==
[https://github.com/winder/Universal-G-Code-Sender Universal G-Code Sender].

This is recommended for grbl. As of Oct 2013, it's supposed to have imperfect support for Marlin.

=== Universal G-code Sender on Raspberry Pi ===
[[File:GCodeOnRPi.png|thumb|300px|Raspberry Pi with grbl and steppernug]]

[[RaspberryPi]] is a very small, low-cost, single-board open-source computer. Although Universal G-code Sender is distributed as a self-contained "One-jar" package that handles its own dependencies, it needs a little help on the arm-linux platform. I believe it misidentifies arm-linux as intel-linux and tries to use an x86 communications driver. Therefore we need to provide our own version of the communications library and manually unpack Universal G-code Sender.

These instructions were developed on a Raspbian Wheezy installation downloaded from [http://www.raspberrypi.org/downloads]. Here is the OS identification:
<pre>
pi@raspberrypi ~ $ uname -a
Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux
</pre>

Install java and comms driver prerequisites
<pre>
sudo apt-get install openjdk-7-jre
sudo apt-get install librxtx-java
</pre>
''Note'' I installed openjdk-7-jdk, but I don't think it's necessary; the jre should be adequate.

download UniversalGcodeSender-v1.0.5-all32.zip from https://github.com/winder/Universal-G-Code-Sender/tree/master/releases

<pre>
unzip UniversalGcodeSender-v1.0.5-all32.zip
jar -xf UniversalGcodeSender-all32.jar
cd lib
jar -xf swing-layout-1.0.4.jar
cd ../main
export CLASSPATH=$CLASSPATH:.:/usr/share/java/RXTXcomm.jar:../lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jni
</pre>
To make the Arduino Uno comm port (ttyACM0) visible, you need to start the application with a command-line parameter
<pre>
java -Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0:/dev/ttyUSB0:/dev/ttyAMA0 com.willwinder.universalgcodesender.MainWindow
</pre>
Be patient, it takes about 20 seconds to start the application.

[[File:UniversalGcodeSender.png|500px|border]]

For minimum-cost implementation of CNC, it would be nice if the g-code sender interface could run from the composite TV-out of the Raspberry Pi (assuming an old TV may be cheaper than an HDMI/DVI monitor). Unfortunately, however, the UI doesn't fit:

[[File:GCodeSender tvres.png]]

== Other ==
Other options for gcode streaming [https://github.com/grbl/grbl/wiki/Using-Grbl here].

CNC Torch Table 2/Control Overview

2013-11-01T05:44:17Z

Daniel Benamy: /* Sending G Code to Firmware */

{{Template:Category=Torch Table}}

=Overview=
<html><img src="https://docs.google.com/drawings/pub?id=1SKGaBa6N21DPzXm9ILuqwPubc6nnRSBAARbkKaEU9hw&w=480&h=360"></html>

=Motor controller and drivers=

==RAMPS==
Dan's using [[RAMPS]] in Oct 2013 to get the table up and running ASAP. The plan is then to replace it with something beefier so we can go faster.

==Alternatives==
See [[Stepper Motor Controller]] and [[Stepper Motor Driver]].

=Software=

==G-code Prep==
[[File:Toolchain.svg|thumb|toolchain pathways]]
[[ImplicitCAD]] (see also [[Parametric_Design_Pilot_Project]])

[[Gcodetools]]

[[DXF_to_G-code_Conversion_Tutorial]]

[[Computer_to_Microcontroller]]

Nesting software would be useful. Example commercial product [http://www.mynesting.com/ here]. Anything open source?

[[DXF_to_G-code_Conversion_Tutorial#Piercing|Gcode preheat]]

Correction for torch cut kerf width ("cutter compensation" in CNC lingo) needed. G40/G41 but grbl does not interpret these.

==G Code Runner==
aka firmware aka motor controller (distinct from motor driver)

This is the firmware running on Arduino which converts a series of G-code commands to step/direction pulses for the drivers.

===Marlin===
When Dan Benamy was getting things going again in Oct 2013, he was using Marlin because grbl doesn't work with RAMPS out of the box. Marlin also has pretty much out of the box support for 2 drivers feeding 2 motors on Y which we use for out long axis because it has 2 motors.

* I cloned marlin from github and checked out the Marlin_v1 tag.
* Edited Configuration.h
** #define MOTHERBOARD 35
** #define DISABLE_E true // For all extruders
** #define TEMP_SENSOR_0 0 // Since we don't have temp sensors
** #define TEMP_SENSOR_1 0 // Since we don't have temp sensors
** #define DEFAULT_AXIS_STEPS_PER_UNIT {128.0537,144.2128,200.0*8/3,760*1.1} // x and y are the right ballpark for the ose torch table at fef, see https://github.com/OSE/CNC-Torch-Table-OSE/issues/4#issuecomment-27460371 for where these numbers came from
** I set the "*ENDSTOP_INVERTING" consts as appropriate for our endstops by running gcode M119, seeing if an endstop was triggered, pushing the button, and running M119 again. If the logic was backwards, I flipped the appropriate boolean.
** I set the travel limits. There are 6 starting with "X_MAX_POS". I set the mins to 0. I set x and y max to 300 and z max to 150 for testing. Once we're calibrated and the table is fixed, we'll make these much bigger.
* I made home = 0,0,0 = the corner of the torch table near the ping pong table with the tool head fully down. Then I can stand at one end of the table and look down at it and it the standard x is right, y is up orientation. And when looking at it from the side, positive z is up.
* Edited Configuration_adv.h
** Uncommented "#define Y_DUAL_STEPPER_DRIVERS". I used Y because Marlin doesn't support dual drivers on X. We'll use Y as the long axis, X as the short axis, and Z as height. The 2nd Y will be output on the 2nd extruder port (E1, http://reprap.org/wiki/RAMPS_1.4#Wiring)
* Edited pins.h
** In the section for motherboards 33, 34 35, added "#define Y2_STEP_PIN 36", "#define Y2_DIR_PIN 34", and "#define Y2_ENABLE_PIN 30". This is a Marlin bug and I've submitted a fix upstream- https://github.com/ErikZalm/Marlin/pull/635
* Opened Marlin/Marlin/Marlin.pde in the arduino ide and clicked to compile and load it to the arduino.

=== grbl ===
When someone (Chuck?) was working on using the steppernug, they were running a modified grbl fork https://github.com/chuck-h/grbl/tree/edge. Changes from standard grbl [https://github.com/grbl/grbl]:
* Hardware I/O reassignment for steppernug interface
** different pin assignments on Arduino
** I2C extender
* substantially revised [[CNC_Torch_Table_Control_Overview#Limits_and_Homing|homing code]]
** dual X axis
** deep changes to stepper drive algorithm (implementing independent-axis trapezoidal move control during homing, as opposed to standard coordinated-axis move control for cutting) which should improve performance on long, limited-aceleration axes like torch table X and Y.

==Sending G Code to Firmware==

In Oct 2013, Dan can't find host software (gcode sending) that works with marlin. He tried about 8 different programs. For now the process is to use Printrun/Pronterface and copy/paste 3 or so gcodes at a time into there, wait for them to execute, and run the next batch. Pasting them all at once fails (machine does the wrong thing) probably because the instruction buffer in marlin isn't big enough.

See [[GcodeCommunications]] for a list of programs to send the g-code file from a host computer to a controller.

===Hardware===
Talk to Arduino with USB, or for longer distance RS422 e.g. [http://www.mouser.com/ProductDetail/Maxim-Integrated-Products/MAX3488ECSA+/?qs=sGAEpiMZZMvbyeSUH4qH%2fEqdkzg%252bEBoj MAX3488E]

== Testing ==
[[Stepper_Testing|Testing]]

Here's a test gcode file which Dan Benamy hand wrote. It works on marlin and draws a 2 hole by 1 hole plate- https://github.com/OSE/CNC-Torch-Table-OSE/issues/20#issuecomment-27547764

=Limits and Homing=

This whole section hasn't been updated for the Oct 2013 work using RAMPS. See https://github.com/OSE/CNC-Torch-Table-OSE/issues/11 for some of this with RAMPS setup.

Also note that docs from before Oct 2013 refer to the long axis as X but with RAMPS and marlin we had to make the long axis Y.

==Dual-motor homing==
The x axis (long axis) has 2 stepper motors. In the steppernug system, these have separate driver modules which receive identical step, direction, and enable signals.

For zeroing, the x axis needs to decouple - so if we get the x axis out of parallel, we can jog the x axes back into parallel by hitting their home switches independently. Steppernug supports this by allowing the Arduino to control a gate which blocks step pulses to the second driver module; in this condition the second motor will freeze and only the first motor will move. There is no provision for moving the second motor without moving the first, but that function is not required for the homing algorithm.

==Axis sequence==
# We will home the Z axis to its upper position first, just in case there are obstructions to clear during the X and Y axis homing.
# X and Y axes will do their initial fast moves to find home simultaneously (overlapped homing) to save time.
# The Y precision home movement will be performed.
# The dual-X-axis precision home maneuver will be performed.

==Limit and home switch configuration==

[[File:HomeLimit.PNG]]

''(TODO: add illustration showing distance coded reference mark options)''

''(Unconfirmed proposal at this time)'' [[User:ChuckH|ChuckH]] 23:42, 20 October 2012 (CEST)

Each axis has two switches: a '''limit switch''' and a '''home switch'''.
* The '''limit switch''' is activated at *either* end of travel. Its function is to protect against machine damage.
** Attempting to move further into the limit when the limit switch is active will cause all axis movement to stop, the torch to be shut off, and any other "safe shutdown" operation to be performed.
** The limit switch could be hit if the program erroneously commands the tool to move beyond the edge of the table
** The limit switch could also be hit if the torch table loses step (e.g. by hitting an obstruction) and subsequently performs a movement which takes it to the edge of the table
** The limit switch ''may'' be implemented as two physical switches wired in parallel, or the machine construction may permit a single switch to be used.
** Repeatable precision of actuation point is not very critical.
** This function is especially important if the table is expected to do automated cutting without constant human supervision.
* The '''home switch''' transitions between inactive and active at a point partway through the legal travel of the machine.
** For example, it might be active at the negative end of travel, and go inactive after 6 inches of movement.
** The home switch is used only for locating a repeatable zero position when the machine is powered on (or when recovering from lost steps)
*** Note that the logical "machine zero" coordinate may be placed at any programmed position relative to the physical home switch.
** Repeatable precision may be important
*** For the dual-motor axis, to establish accurate squareness
*** For all axes, to pick up in the middle of an interrupted job
*** If fixturing is used for repeat "production style" operations
** (''update, 14-July-2103:'') Instead of responding to a single flag location, the home switch could be actuated many times by multiple flags along the travel, with carefully designed nonuniform spacing between flags
*** This implements "distance coded reference marks" (DCRM), e.g. [[http://www.rls.si/en/dcrm-distance-coded-reference-mark-system--15934]], [[http://www.heidenhain.de/presentation/posa/en/index/N10584/N108A7/N10926.html]], [[http://www.newall.com/upload/content/file/SHG-TC%20-%20Distance-Coded%20Protocol%20-%20USA%20Ver%2004-07-05.pdf]]
*** DCRM is often applied to incremental linear encoder systems; the same principle is effective here using motor step count as the "incremental scale".
*** Using DCRM, the axis only needs to traverse two flag transitions after startup in order to unambiguously determine absolute position.
** By construction, the home switch is active at one end of travel and inactive at the other
*** This allows the machine to know which end of travel it is at in the event the limit switch is activated
*** This, in turn, allows the machine to permit recovery movement from the limit condition back into legal travel, while ignoring a command to go further into the limit zone.

There is an alternative switch configuration which places individual limit switches at the positive and negative limits of legal travel. However the configuration above is preferred because it supports faster homing and simpler control logic. Specifically:
# The substantial distance between the end of travel and the home switch location gives the machine overtravel room to do a controlled stop from high speed: maximum slewing speed can be used during initial homing without risk of slamming into the physical end-of-travel.
# Home switch placement can minimize the typical startup time.
#* If an axis is usually parked near one end of travel, the home switch can be placed there
#* If the axis position on startup is random, placing the home switch in the center of travel will minimize the average seek time.
#* DCRM can be implemented to obtain short startup/home times no matter what the starting position.
# The "safety shutdown" limit-switch function can be always active, and is independent of homing
#* The alternative approach requires logically repurposing a limit switch as home switch during home operations

==Switch Types==

The steppernug interface provides 5V power to sensor switches so either electronic or mechanical switches are easily accommodated.
* Mechanical microswitches are simple and effective.
* A Hall switch (e.g. [[Hall_Effect_Sensor_Module|this]]) is rugged but its position precision is probably only suitable for limits, not home switches.
* An optical interrupter (e.g. [http://www.mouser.com/ProductDetail/Sharp-Microelectronics/GP1A75EJ000F/?qs=%2fha2pyFaduhmXejJv184BikaBEqZykWweNnmsglkeuWVbMieAKIiNg%3d%3d Sharp GP1A75EJ000F]) can give precisely repeatable homing.

== Switch response time ==

The home switch should respond within one motor step time at the "creep speed" used for final approach. This speed might be ~100 steps/sec which gives us ~10ms.

The limit switch should respond quickly enough so that an emergency stop initiated by the switch will stop the machine motion before it hits a mechanical stop. This time is dependent on a lot of different design parameters, but is probably at least 10ms.

The limited response speed required allows us some latitude for noise suppression.

Since all switch signals pass through the I2C expander for I/O, there is about 150 usec (0.15ms) added, see [[Stepper_Testing#timing|here]].

=Torch control=

Software can use an M code to start the cut (e.g. open cutting-oxygen valve, strike plasma arc).

A second M code could shut down the entire torch (e.g. at the end of an unsupervised cutting session).

See also [[CNC_Torch_Table/Research_Development#Cutting_Torch]]

==Plasma Torch==

[[Plasma_Cutter_Design#Plasma_Cutter_PC_Interface]]

[http://www.metalwebnews.com/howto/plasma/presentation.pdf This presentation] on plasma-cutting accurate holes also suggests that ramping down plasma current while torch is still moving is good practice. (It makes the electrodes last longer.)

[[Sensing_Distance_from_Work_Piece|Z-axis arc voltage height control]]. Needs design work.

[[Plasma_Cutter_Cut_Speed_as_a_Function_of_Metal_Thickness|Cutting speed]]

Hypertherm:

[[File:PlasmaSpeed.jpg|400px]]

==Oxyfuel (oxyacetylene, oxypropane, etc) cutting torch==

During cutting, an oxyfuel cutting torch is literally burning the steel with a blast of oxygen; most of the heat comes from oxidizing the iron. However to start a new cut ("piercing") you must preheat the steel, relying on the acetylene or LPG for heat. After the steel is red hot you boost the oxygen flow and make the cut. We will want an oxygen-rated valve controlled by the microprocessor. "Oxygen-rated" mostly means the valve is thoroughly cleaned of all oil or flammable solvents that tend to explode on contact with pure oxygen; good practical reference [http://www.gmcscuba.com/pdf/CONVERTING%20DIVE%20TANKS%20FOR%20OXYGEN%20SERVICE.pdf here]. A solenoid valve like [http://www.lesman.com/acatalog/ASCO_8210_Oxygen-Service_Valves.html this] in combination with an ordinary regulator would give basic on/off control, but see better suggestions below.

Fairly technical application note about how to do good oxyfuel machine cutting from ESAB: [http://www.esabna.com/literature/Gas%20Apparatus/Miscellaneous/Oxy-Fuel_Cutting_Quality_0558006464.pdf]

[http://www.cnczone.com/forums/cnc_plasma_waterjet_machines/98346-cnc_oxy_fuel_discussion-25.html#post778595 This] ''long'' forum thread contains a lot of information about implementing small-shop CNC oxyfuel with programmed preheat, pierce, and cutting gas controls, auto ignition, etc. Based partly on this information, here are some control design suggestions for an Arduino-based CNC like [[CoolRAMPS]] or [[CNC_Torch_Table_Control_Overview#Steppernug_Driver_and_Interface_.28alternative_to_CoolRamps.29|Steppernug/grbl]]:
* use dome loaded regulators (e.g. Victor DL700 [http://www.amazon.com/Victor-0780-1188-DL700-500-Dome-Regulator/dp/B0047684PG] [http://victortechnologies.com/IM_Uploads/doclib_8016_DocLib_2331_56-0679%20%20DL%20700%20External%20Dome-Loaded%20Regulator%20Part%20Bulletin.pdf]) driven by regulated shop air [[File:DL700.png|thumb]] [[File:VTS250.png|thumb]]
** general description of spring- and dome-loaded regulators [http://www.documentation.emersonprocess.com/groups/public/documents/bulletins/debul2008x012.pdf here]
** It appears that almost any standard screw-handle regulator can be converted to "dome loaded" by sealing up the housing cap and replacing the screw/spring with an air pressure fitting. See video below. A classic dual-stage like the [http://victortechnologies.com/IM_Uploads/doclib_8039_DocLib_2310_56-0623%20VTS%20250%20Series%20Regulators.pdf VTS250] should work very nicely for conversion
** As with manual regulators, if oxy- or fuel-tank pressure exceeds inlet rating of dome-loaded regulator, a first-stage tank regulator will be required.
** With the dome-loaded regulators, gas on/off as well as pressure setting can be obtained with low-cost shop air components and small valves (e.g [http://www.ebay.com/itm/4V130C-06-DC24V-Solenoid-Air-Valve-5-port-3-position-/290652595990 4V130C],[http://www.automationdirect.com/adc/Shopping/Catalog/Pneumatic_Components/Pneumatic_Valves_-a-_Accessories/Solenoid_Air_Valves_-a-_Accessories/5-port_(4-way),_3-pos.,_Body_Ported_-z-_Manifold_(AVS-5,AM_Series)/AVS-523C1-24D AVS-523C1])
** Using a [http://www.digikey.com/product-detail/en/MPXHZ6400AC6T1/MPXHZ6400AC6T1CT-ND/2057456 solid-state pressure sensor] for feedback, the Arduino can set the regulated pressures to programmed levels by actuating the pneumatic valves (increase/decrease loading pressure until feedback is correct). See video below and code on [http://github.com/chuck-h/ose-gaspressurecontrol github].
* use an electric igniter ([http://www.rvpartwholesaler.com/servlet/the-31/Dometic-2931132019-Refrigerator-Reignitor/Detail RV fridge igniter], [http://www.amazon.com/GrillPro-20620-Electric-Button-Igniter/dp/B000FJVKNM BBQ igniter], [https://www.sparkfun.com/products/11218 spark coil]).
* follow the sequencing of x,y,z motions, pressure changes, on/off, and ignition described by the folks on the forum thread above.
** Develop a library of pressure/time/positioning parameters for different material thicknesses and tip sizes that can be applied automatically by the G-code programming; this should minimize setup time and tweaking.

<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=H3Z3EHqTn44"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=WcUnHnZJ8xU"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=uwCbohxajOY"}
)
</script>
</html>

Installing a [http://www.clippard.com/part/MNV-1K needle valve] at the solenoid air valve improved control smoothness a bit compared to video above.

[[Image:ClippardNeedle.jpg|300px]]

=== oxygen ===

The cutting oxygen for the torch must be high purity (according to the ESAB note above less than 95% purity simply will not cut steel, and >99.5% is required for best quality). Until recently, this meant cryogenically separated oxygen, depending on a large capital plant, and thus the user must rely on commercially provided tank oxygen. For some 30 years, [http://en.wikipedia.org/wiki/Pressure_swing_adsorption pressure-swing-adsorption (PSA) separators] have been available, but standard designs do not remove argon and therefore result in about 95%-oxygen, 5%-argon output gas. PSA construction is low-tech and works very nicely at small scale, e.g. portable breathing-oxygen units, and would be quite suitable for OSE. 95% purity is probably adequate for the preheat flame (ChuckH conjecture). For higher-purity cutting oxygen, PSA can be extended with additional zeolite materials [http://www.ou.edu/class/che-design/a-design/projects-2007/Oxygen%20Generator-Presentation.pdf] or activated carbon [http://www.airsepcpd.com/airsepcpd/pdfs/12779.pdf]; despite [http://cr4.globalspec.com/blogentry/20384/To-Build-an-Oxygen-Concentrator-or-Not this discussion] there is no clear record of small-scale DIY implementation of 99% oxygen PSA.

=== oxyacetylene ===

Recommendations from Victor:

[[File:Victor_Oxy_Acetylene.jpg]]

Commercial oxy-fuel machine cutting heads
* [http://www.pierce.cz/production/components-for-building-and-retrofiting-cutting-machines/autogenni-motorizovana-rezaci-hlava.htm?lang=en Czech] one with capacitive height sensor feature

Components offered by JB: [[CNC_Torch_Table_Log#Oct._21.2C_2012]]

== Oxy-propane, -natural gas, etc ==
[http://www.cousesteel.com/AndysPlace/PropaneAcetylene.html Propane] instead of acetylene. Note the large preheat oxygen flow (not in a consistent stoichiometric ratio to fuel) in this chart. Odd.

[[File:VictorLPGcutting.png]]

Would [[Gasifier|gasifier-gas]] or [[biogas]] & oxygen work? Probably, as natural gas is primarily methane and is a commercially successful cutting-torch fuel.

=See Also=
[[Distributed_CNC_Motion_Control]]

[[Category:CNC Torch Table Prototype II]]
[[Category:Vann]]

GcodeCommunications

2013-11-01T05:40:09Z

Daniel Benamy:

==Intro==
When using a [[CNC]] machine, there needs to be a program which sends the gcode created on a computer, to the motor controller which executes the gcode by moving around the motors.

== Gctrl ==
[[Gctrl]](cross-platform)

== Gcodesender ==
[http://www.shapeoko.com/wiki/index.php/Assembly_step_15 gcodesender](Windows).

==Printrun==
[http://reprap.org/wiki/Printrun Printrun] is a gcode sender that's supposed to have good support for RAMPS.

In Oct 2013, Dan used it for manual control and entering gcodes, but couldn't get it to send a file.

== ReplicatorG ==
http://replicat.org/

== grbl-controller ==

http://zapmaker.org/projects/grbl-controller-3-0/

== Repetier ==

Beautiful, open source, for macs. Very easy to configure.

In Oct 2013, Dan couldn't get it to run gcode files although it's got some nice manual control features.

== RepSnapper ==
https://github.com/timschmidt/repsnapper

== Universal G-code Sender ==
[https://github.com/winder/Universal-G-Code-Sender Universal G-Code Sender].

This is recommended for grbl. As of Oct 2013, it's supposed to have imperfect support for Marlin.

=== Universal G-code Sender on Raspberry Pi ===
[[File:GCodeOnRPi.png|thumb|300px|Raspberry Pi with grbl and steppernug]]

[[RaspberryPi]] is a very small, low-cost, single-board open-source computer. Although Universal G-code Sender is distributed as a self-contained "One-jar" package that handles its own dependencies, it needs a little help on the arm-linux platform. I believe it misidentifies arm-linux as intel-linux and tries to use an x86 communications driver. Therefore we need to provide our own version of the communications library and manually unpack Universal G-code Sender.

These instructions were developed on a Raspbian Wheezy installation downloaded from [http://www.raspberrypi.org/downloads]. Here is the OS identification:
<pre>
pi@raspberrypi ~ $ uname -a
Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux
</pre>

Install java and comms driver prerequisites
<pre>
sudo apt-get install openjdk-7-jre
sudo apt-get install librxtx-java
</pre>
''Note'' I installed openjdk-7-jdk, but I don't think it's necessary; the jre should be adequate.

download UniversalGcodeSender-v1.0.5-all32.zip from https://github.com/winder/Universal-G-Code-Sender/tree/master/releases

<pre>
unzip UniversalGcodeSender-v1.0.5-all32.zip
jar -xf UniversalGcodeSender-all32.jar
cd lib
jar -xf swing-layout-1.0.4.jar
cd ../main
export CLASSPATH=$CLASSPATH:.:/usr/share/java/RXTXcomm.jar:../lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jni
</pre>
To make the Arduino Uno comm port (ttyACM0) visible, you need to start the application with a command-line parameter
<pre>
java -Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0:/dev/ttyUSB0:/dev/ttyAMA0 com.willwinder.universalgcodesender.MainWindow
</pre>
Be patient, it takes about 20 seconds to start the application.

[[File:UniversalGcodeSender.png|500px|border]]

For minimum-cost implementation of CNC, it would be nice if the g-code sender interface could run from the composite TV-out of the Raspberry Pi (assuming an old TV may be cheaper than an HDMI/DVI monitor). Unfortunately, however, the UI doesn't fit:

[[File:GCodeSender tvres.png]]

== Other ==
Other options for gcode streaming [https://github.com/grbl/grbl/wiki/Using-Grbl here].

GcodeCommunications

2013-11-01T05:23:19Z

Daniel Benamy:

==Intro==
When using a [[CNC]] machine, there needs to be a program which sends the gcode created on a computer, to the motor controller which executes the gcode by moving around the motors.

== Gctrl ==
[[Gctrl]](cross-platform)

== Gcodesender ==
[http://www.shapeoko.com/wiki/index.php/Assembly_step_15 gcodesender](Windows).

==Printrun==
[http://reprap.org/wiki/Printrun Printrun] is a gcode sender that's supposed to have good support for RAMPS.

In Oct 2013, Dan used it for manual control and entering gcodes, but couldn't get it to send a file.

== Universal G-code Sender ==
[https://github.com/winder/Universal-G-Code-Sender Universal G-Code Sender].

This is recommended for grbl. As of Oct 2013, it's supposed to have imperfect support for Marlin.

=== Universal G-code Sender on Raspberry Pi ===
[[File:GCodeOnRPi.png|thumb|300px|Raspberry Pi with grbl and steppernug]]

[[RaspberryPi]] is a very small, low-cost, single-board open-source computer. Although Universal G-code Sender is distributed as a self-contained "One-jar" package that handles its own dependencies, it needs a little help on the arm-linux platform. I believe it misidentifies arm-linux as intel-linux and tries to use an x86 communications driver. Therefore we need to provide our own version of the communications library and manually unpack Universal G-code Sender.

These instructions were developed on a Raspbian Wheezy installation downloaded from [http://www.raspberrypi.org/downloads]. Here is the OS identification:
<pre>
pi@raspberrypi ~ $ uname -a
Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux
</pre>

Install java and comms driver prerequisites
<pre>
sudo apt-get install openjdk-7-jre
sudo apt-get install librxtx-java
</pre>
''Note'' I installed openjdk-7-jdk, but I don't think it's necessary; the jre should be adequate.

download UniversalGcodeSender-v1.0.5-all32.zip from https://github.com/winder/Universal-G-Code-Sender/tree/master/releases

<pre>
unzip UniversalGcodeSender-v1.0.5-all32.zip
jar -xf UniversalGcodeSender-all32.jar
cd lib
jar -xf swing-layout-1.0.4.jar
cd ../main
export CLASSPATH=$CLASSPATH:.:/usr/share/java/RXTXcomm.jar:../lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jni
</pre>
To make the Arduino Uno comm port (ttyACM0) visible, you need to start the application with a command-line parameter
<pre>
java -Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0:/dev/ttyUSB0:/dev/ttyAMA0 com.willwinder.universalgcodesender.MainWindow
</pre>
Be patient, it takes about 20 seconds to start the application.

[[File:UniversalGcodeSender.png|500px|border]]

For minimum-cost implementation of CNC, it would be nice if the g-code sender interface could run from the composite TV-out of the Raspberry Pi (assuming an old TV may be cheaper than an HDMI/DVI monitor). Unfortunately, however, the UI doesn't fit:

[[File:GCodeSender tvres.png]]

== grbl-controller ==

http://zapmaker.org/projects/grbl-controller-3-0/

== Repetier ==

Beautiful, open source, for macs. Very easy to configure.

In Oct 2013, Dan couldn't get it to run gcode files although it's got some nice manual control features.

== RepSnapper ==
https://github.com/timschmidt/repsnapper

== Other ==
Other options for gcode streaming [https://github.com/grbl/grbl/wiki/Using-Grbl here].

GcodeCommunications

2013-11-01T05:18:31Z

Daniel Benamy:

==Intro==
When using a [[CNC]] machine, there needs to be a program which sends the gcode created on a computer, to the motor controller which executes the gcode by moving around the motors.

== Gctrl ==
[[Gctrl]](cross-platform)

== Gcodesender ==
[http://www.shapeoko.com/wiki/index.php/Assembly_step_15 gcodesender](Windows).

==Printrun==
[http://reprap.org/wiki/Printrun Printrun] is a gcode sender that's supposed to have good support for RAMPS.

In Oct 2013, Dan used it for manual control and entering gcodes, but couldn't get it to send a file.

== Universal G-code Sender ==
[https://github.com/winder/Universal-G-Code-Sender Universal G-Code Sender].

This is recommended for grbl. As of Oct 2013, it's supposed to have imperfect support for Marlin.

=== Universal G-code Sender on Raspberry Pi ===
[[File:GCodeOnRPi.png|thumb|300px|Raspberry Pi with grbl and steppernug]]

[[RaspberryPi]] is a very small, low-cost, single-board open-source computer. Although Universal G-code Sender is distributed as a self-contained "One-jar" package that handles its own dependencies, it needs a little help on the arm-linux platform. I believe it misidentifies arm-linux as intel-linux and tries to use an x86 communications driver. Therefore we need to provide our own version of the communications library and manually unpack Universal G-code Sender.

These instructions were developed on a Raspbian Wheezy installation downloaded from [http://www.raspberrypi.org/downloads]. Here is the OS identification:
<pre>
pi@raspberrypi ~ $ uname -a
Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux
</pre>

Install java and comms driver prerequisites
<pre>
sudo apt-get install openjdk-7-jre
sudo apt-get install librxtx-java
</pre>
''Note'' I installed openjdk-7-jdk, but I don't think it's necessary; the jre should be adequate.

download UniversalGcodeSender-v1.0.5-all32.zip from https://github.com/winder/Universal-G-Code-Sender/tree/master/releases

<pre>
unzip UniversalGcodeSender-v1.0.5-all32.zip
jar -xf UniversalGcodeSender-all32.jar
cd lib
jar -xf swing-layout-1.0.4.jar
cd ../main
export CLASSPATH=$CLASSPATH:.:/usr/share/java/RXTXcomm.jar:../lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jni
</pre>
To make the Arduino Uno comm port (ttyACM0) visible, you need to start the application with a command-line parameter
<pre>
java -Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0:/dev/ttyUSB0:/dev/ttyAMA0 com.willwinder.universalgcodesender.MainWindow
</pre>
Be patient, it takes about 20 seconds to start the application.

[[File:UniversalGcodeSender.png|500px|border]]

For minimum-cost implementation of CNC, it would be nice if the g-code sender interface could run from the composite TV-out of the Raspberry Pi (assuming an old TV may be cheaper than an HDMI/DVI monitor). Unfortunately, however, the UI doesn't fit:

[[File:GCodeSender tvres.png]]

== grbl-controller ==

http://zapmaker.org/projects/grbl-controller-3-0/

== Repetier ==

Beautiful, open source, for macs. Very easy to configure.

In Oct 2013, Dan couldn't get it to run gcode files although it's got some nice manual control features.

== Other ==
Other options for gcode streaming [https://github.com/grbl/grbl/wiki/Using-Grbl here].

GcodeCommunications

2013-11-01T05:10:53Z

Daniel Benamy: /* Printrun */

==Intro==
When using a [[CNC]] machine, there needs to be a program which sends the gcode created on a computer, to the motor controller which executes the gcode by moving around the motors.

== Gctrl ==
[[Gctrl]](cross-platform)

== Gcodesender ==
[http://www.shapeoko.com/wiki/index.php/Assembly_step_15 gcodesender](Windows).

==Printrun==
[http://reprap.org/wiki/Printrun Printrun] is a gcode sender that's supposed to have good support for RAMPS.

In Oct 2013, Dan used it for manual control and entering gcodes, but couldn't get it to send a file.

== Universal G-code Sender ==
[https://github.com/winder/Universal-G-Code-Sender Universal G-Code Sender].

This is recommended for grbl. As of Oct 2013, it's supposed to have imperfect support for Marlin.

=== Universal G-code Sender on Raspberry Pi ===
[[File:GCodeOnRPi.png|thumb|300px|Raspberry Pi with grbl and steppernug]]

[[RaspberryPi]] is a very small, low-cost, single-board open-source computer. Although Universal G-code Sender is distributed as a self-contained "One-jar" package that handles its own dependencies, it needs a little help on the arm-linux platform. I believe it misidentifies arm-linux as intel-linux and tries to use an x86 communications driver. Therefore we need to provide our own version of the communications library and manually unpack Universal G-code Sender.

These instructions were developed on a Raspbian Wheezy installation downloaded from [http://www.raspberrypi.org/downloads]. Here is the OS identification:
<pre>
pi@raspberrypi ~ $ uname -a
Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux
</pre>

Install java and comms driver prerequisites
<pre>
sudo apt-get install openjdk-7-jre
sudo apt-get install librxtx-java
</pre>
''Note'' I installed openjdk-7-jdk, but I don't think it's necessary; the jre should be adequate.

download UniversalGcodeSender-v1.0.5-all32.zip from https://github.com/winder/Universal-G-Code-Sender/tree/master/releases

<pre>
unzip UniversalGcodeSender-v1.0.5-all32.zip
jar -xf UniversalGcodeSender-all32.jar
cd lib
jar -xf swing-layout-1.0.4.jar
cd ../main
export CLASSPATH=$CLASSPATH:.:/usr/share/java/RXTXcomm.jar:../lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jni
</pre>
To make the Arduino Uno comm port (ttyACM0) visible, you need to start the application with a command-line parameter
<pre>
java -Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0:/dev/ttyUSB0:/dev/ttyAMA0 com.willwinder.universalgcodesender.MainWindow
</pre>
Be patient, it takes about 20 seconds to start the application.

[[File:UniversalGcodeSender.png|500px|border]]

For minimum-cost implementation of CNC, it would be nice if the g-code sender interface could run from the composite TV-out of the Raspberry Pi (assuming an old TV may be cheaper than an HDMI/DVI monitor). Unfortunately, however, the UI doesn't fit:

[[File:GCodeSender tvres.png]]

== grbl-controller ==

http://zapmaker.org/projects/grbl-controller-3-0/

== Other ==
Other options for gcode streaming [https://github.com/grbl/grbl/wiki/Using-Grbl here].

CNC Torch Table 2/Control Overview

2013-11-01T05:02:57Z

Daniel Benamy: /* Limits and Homing */

{{Template:Category=Torch Table}}

=Overview=
<html><img src="https://docs.google.com/drawings/pub?id=1SKGaBa6N21DPzXm9ILuqwPubc6nnRSBAARbkKaEU9hw&w=480&h=360"></html>

=Motor controller and drivers=

==RAMPS==
Dan's using [[RAMPS]] in Oct 2013 to get the table up and running ASAP. The plan is then to replace it with something beefier so we can go faster.

==Alternatives==
See [[Stepper Motor Controller]] and [[Stepper Motor Driver]].

=Software=

==G-code Prep==
[[File:Toolchain.svg|thumb|toolchain pathways]]
[[ImplicitCAD]] (see also [[Parametric_Design_Pilot_Project]])

[[Gcodetools]]

[[DXF_to_G-code_Conversion_Tutorial]]

[[Computer_to_Microcontroller]]

Nesting software would be useful. Example commercial product [http://www.mynesting.com/ here]. Anything open source?

[[DXF_to_G-code_Conversion_Tutorial#Piercing|Gcode preheat]]

Correction for torch cut kerf width ("cutter compensation" in CNC lingo) needed. G40/G41 but grbl does not interpret these.

==G Code Runner==
aka firmware aka motor controller (distinct from motor driver)

This is the firmware running on Arduino which converts a series of G-code commands to step/direction pulses for the drivers.

===Marlin===
When Dan Benamy was getting things going again in Oct 2013, he was using Marlin because grbl doesn't work with RAMPS out of the box. Marlin also has pretty much out of the box support for 2 drivers feeding 2 motors on Y which we use for out long axis because it has 2 motors.

* I cloned marlin from github and checked out the Marlin_v1 tag.
* Edited Configuration.h
** #define MOTHERBOARD 35
** #define DISABLE_E true // For all extruders
** #define TEMP_SENSOR_0 0 // Since we don't have temp sensors
** #define TEMP_SENSOR_1 0 // Since we don't have temp sensors
** #define DEFAULT_AXIS_STEPS_PER_UNIT {128.0537,144.2128,200.0*8/3,760*1.1} // x and y are the right ballpark for the ose torch table at fef, see https://github.com/OSE/CNC-Torch-Table-OSE/issues/4#issuecomment-27460371 for where these numbers came from
** I set the "*ENDSTOP_INVERTING" consts as appropriate for our endstops by running gcode M119, seeing if an endstop was triggered, pushing the button, and running M119 again. If the logic was backwards, I flipped the appropriate boolean.
** I set the travel limits. There are 6 starting with "X_MAX_POS". I set the mins to 0. I set x and y max to 300 and z max to 150 for testing. Once we're calibrated and the table is fixed, we'll make these much bigger.
* I made home = 0,0,0 = the corner of the torch table near the ping pong table with the tool head fully down. Then I can stand at one end of the table and look down at it and it the standard x is right, y is up orientation. And when looking at it from the side, positive z is up.
* Edited Configuration_adv.h
** Uncommented "#define Y_DUAL_STEPPER_DRIVERS". I used Y because Marlin doesn't support dual drivers on X. We'll use Y as the long axis, X as the short axis, and Z as height. The 2nd Y will be output on the 2nd extruder port (E1, http://reprap.org/wiki/RAMPS_1.4#Wiring)
* Edited pins.h
** In the section for motherboards 33, 34 35, added "#define Y2_STEP_PIN 36", "#define Y2_DIR_PIN 34", and "#define Y2_ENABLE_PIN 30". This is a Marlin bug and I've submitted a fix upstream- https://github.com/ErikZalm/Marlin/pull/635
* Opened Marlin/Marlin/Marlin.pde in the arduino ide and clicked to compile and load it to the arduino.

=== grbl ===
When someone (Chuck?) was working on using the steppernug, they were running a modified grbl fork https://github.com/chuck-h/grbl/tree/edge. Changes from standard grbl [https://github.com/grbl/grbl]:
* Hardware I/O reassignment for steppernug interface
** different pin assignments on Arduino
** I2C extender
* substantially revised [[CNC_Torch_Table_Control_Overview#Limits_and_Homing|homing code]]
** dual X axis
** deep changes to stepper drive algorithm (implementing independent-axis trapezoidal move control during homing, as opposed to standard coordinated-axis move control for cutting) which should improve performance on long, limited-aceleration axes like torch table X and Y.

==Sending G Code to Firmware==

===Printrun===
This is what Dan's using in Oct 2013.

There's good installation instructions at https://github.com/kliment/Printrun. He wanted to do a source install but gave up when it wasn't easy with pip because it needs to use system wide python for access to the display.

* Change baud rate to 250000.
* Click connect.

===Other Software===
[[GcodeCommunications]]: other programs to send the g-code file from a host computer to a controller.

===Hardware===
Talk to Arduino with USB, or for longer distance RS422 e.g. [http://www.mouser.com/ProductDetail/Maxim-Integrated-Products/MAX3488ECSA+/?qs=sGAEpiMZZMvbyeSUH4qH%2fEqdkzg%252bEBoj MAX3488E]

== Testing ==
[[Stepper_Testing|Testing]]

Here's a test gcode file which Dan Benamy hand wrote. It works on marlin and draws a 2 hole by 1 hole plate- https://github.com/OSE/CNC-Torch-Table-OSE/issues/20#issuecomment-27547764

=Limits and Homing=

This whole section hasn't been updated for the Oct 2013 work using RAMPS. See https://github.com/OSE/CNC-Torch-Table-OSE/issues/11 for some of this with RAMPS setup.

Also note that docs from before Oct 2013 refer to the long axis as X but with RAMPS and marlin we had to make the long axis Y.

==Dual-motor homing==
The x axis (long axis) has 2 stepper motors. In the steppernug system, these have separate driver modules which receive identical step, direction, and enable signals.

For zeroing, the x axis needs to decouple - so if we get the x axis out of parallel, we can jog the x axes back into parallel by hitting their home switches independently. Steppernug supports this by allowing the Arduino to control a gate which blocks step pulses to the second driver module; in this condition the second motor will freeze and only the first motor will move. There is no provision for moving the second motor without moving the first, but that function is not required for the homing algorithm.

==Axis sequence==
# We will home the Z axis to its upper position first, just in case there are obstructions to clear during the X and Y axis homing.
# X and Y axes will do their initial fast moves to find home simultaneously (overlapped homing) to save time.
# The Y precision home movement will be performed.
# The dual-X-axis precision home maneuver will be performed.

==Limit and home switch configuration==

[[File:HomeLimit.PNG]]

''(TODO: add illustration showing distance coded reference mark options)''

''(Unconfirmed proposal at this time)'' [[User:ChuckH|ChuckH]] 23:42, 20 October 2012 (CEST)

Each axis has two switches: a '''limit switch''' and a '''home switch'''.
* The '''limit switch''' is activated at *either* end of travel. Its function is to protect against machine damage.
** Attempting to move further into the limit when the limit switch is active will cause all axis movement to stop, the torch to be shut off, and any other "safe shutdown" operation to be performed.
** The limit switch could be hit if the program erroneously commands the tool to move beyond the edge of the table
** The limit switch could also be hit if the torch table loses step (e.g. by hitting an obstruction) and subsequently performs a movement which takes it to the edge of the table
** The limit switch ''may'' be implemented as two physical switches wired in parallel, or the machine construction may permit a single switch to be used.
** Repeatable precision of actuation point is not very critical.
** This function is especially important if the table is expected to do automated cutting without constant human supervision.
* The '''home switch''' transitions between inactive and active at a point partway through the legal travel of the machine.
** For example, it might be active at the negative end of travel, and go inactive after 6 inches of movement.
** The home switch is used only for locating a repeatable zero position when the machine is powered on (or when recovering from lost steps)
*** Note that the logical "machine zero" coordinate may be placed at any programmed position relative to the physical home switch.
** Repeatable precision may be important
*** For the dual-motor axis, to establish accurate squareness
*** For all axes, to pick up in the middle of an interrupted job
*** If fixturing is used for repeat "production style" operations
** (''update, 14-July-2103:'') Instead of responding to a single flag location, the home switch could be actuated many times by multiple flags along the travel, with carefully designed nonuniform spacing between flags
*** This implements "distance coded reference marks" (DCRM), e.g. [[http://www.rls.si/en/dcrm-distance-coded-reference-mark-system--15934]], [[http://www.heidenhain.de/presentation/posa/en/index/N10584/N108A7/N10926.html]], [[http://www.newall.com/upload/content/file/SHG-TC%20-%20Distance-Coded%20Protocol%20-%20USA%20Ver%2004-07-05.pdf]]
*** DCRM is often applied to incremental linear encoder systems; the same principle is effective here using motor step count as the "incremental scale".
*** Using DCRM, the axis only needs to traverse two flag transitions after startup in order to unambiguously determine absolute position.
** By construction, the home switch is active at one end of travel and inactive at the other
*** This allows the machine to know which end of travel it is at in the event the limit switch is activated
*** This, in turn, allows the machine to permit recovery movement from the limit condition back into legal travel, while ignoring a command to go further into the limit zone.

There is an alternative switch configuration which places individual limit switches at the positive and negative limits of legal travel. However the configuration above is preferred because it supports faster homing and simpler control logic. Specifically:
# The substantial distance between the end of travel and the home switch location gives the machine overtravel room to do a controlled stop from high speed: maximum slewing speed can be used during initial homing without risk of slamming into the physical end-of-travel.
# Home switch placement can minimize the typical startup time.
#* If an axis is usually parked near one end of travel, the home switch can be placed there
#* If the axis position on startup is random, placing the home switch in the center of travel will minimize the average seek time.
#* DCRM can be implemented to obtain short startup/home times no matter what the starting position.
# The "safety shutdown" limit-switch function can be always active, and is independent of homing
#* The alternative approach requires logically repurposing a limit switch as home switch during home operations

==Switch Types==

The steppernug interface provides 5V power to sensor switches so either electronic or mechanical switches are easily accommodated.
* Mechanical microswitches are simple and effective.
* A Hall switch (e.g. [[Hall_Effect_Sensor_Module|this]]) is rugged but its position precision is probably only suitable for limits, not home switches.
* An optical interrupter (e.g. [http://www.mouser.com/ProductDetail/Sharp-Microelectronics/GP1A75EJ000F/?qs=%2fha2pyFaduhmXejJv184BikaBEqZykWweNnmsglkeuWVbMieAKIiNg%3d%3d Sharp GP1A75EJ000F]) can give precisely repeatable homing.

== Switch response time ==

The home switch should respond within one motor step time at the "creep speed" used for final approach. This speed might be ~100 steps/sec which gives us ~10ms.

The limit switch should respond quickly enough so that an emergency stop initiated by the switch will stop the machine motion before it hits a mechanical stop. This time is dependent on a lot of different design parameters, but is probably at least 10ms.

The limited response speed required allows us some latitude for noise suppression.

Since all switch signals pass through the I2C expander for I/O, there is about 150 usec (0.15ms) added, see [[Stepper_Testing#timing|here]].

=Torch control=

Software can use an M code to start the cut (e.g. open cutting-oxygen valve, strike plasma arc).

A second M code could shut down the entire torch (e.g. at the end of an unsupervised cutting session).

See also [[CNC_Torch_Table/Research_Development#Cutting_Torch]]

==Plasma Torch==

[[Plasma_Cutter_Design#Plasma_Cutter_PC_Interface]]

[http://www.metalwebnews.com/howto/plasma/presentation.pdf This presentation] on plasma-cutting accurate holes also suggests that ramping down plasma current while torch is still moving is good practice. (It makes the electrodes last longer.)

[[Sensing_Distance_from_Work_Piece|Z-axis arc voltage height control]]. Needs design work.

[[Plasma_Cutter_Cut_Speed_as_a_Function_of_Metal_Thickness|Cutting speed]]

Hypertherm:

[[File:PlasmaSpeed.jpg|400px]]

==Oxyfuel (oxyacetylene, oxypropane, etc) cutting torch==

During cutting, an oxyfuel cutting torch is literally burning the steel with a blast of oxygen; most of the heat comes from oxidizing the iron. However to start a new cut ("piercing") you must preheat the steel, relying on the acetylene or LPG for heat. After the steel is red hot you boost the oxygen flow and make the cut. We will want an oxygen-rated valve controlled by the microprocessor. "Oxygen-rated" mostly means the valve is thoroughly cleaned of all oil or flammable solvents that tend to explode on contact with pure oxygen; good practical reference [http://www.gmcscuba.com/pdf/CONVERTING%20DIVE%20TANKS%20FOR%20OXYGEN%20SERVICE.pdf here]. A solenoid valve like [http://www.lesman.com/acatalog/ASCO_8210_Oxygen-Service_Valves.html this] in combination with an ordinary regulator would give basic on/off control, but see better suggestions below.

Fairly technical application note about how to do good oxyfuel machine cutting from ESAB: [http://www.esabna.com/literature/Gas%20Apparatus/Miscellaneous/Oxy-Fuel_Cutting_Quality_0558006464.pdf]

[http://www.cnczone.com/forums/cnc_plasma_waterjet_machines/98346-cnc_oxy_fuel_discussion-25.html#post778595 This] ''long'' forum thread contains a lot of information about implementing small-shop CNC oxyfuel with programmed preheat, pierce, and cutting gas controls, auto ignition, etc. Based partly on this information, here are some control design suggestions for an Arduino-based CNC like [[CoolRAMPS]] or [[CNC_Torch_Table_Control_Overview#Steppernug_Driver_and_Interface_.28alternative_to_CoolRamps.29|Steppernug/grbl]]:
* use dome loaded regulators (e.g. Victor DL700 [http://www.amazon.com/Victor-0780-1188-DL700-500-Dome-Regulator/dp/B0047684PG] [http://victortechnologies.com/IM_Uploads/doclib_8016_DocLib_2331_56-0679%20%20DL%20700%20External%20Dome-Loaded%20Regulator%20Part%20Bulletin.pdf]) driven by regulated shop air [[File:DL700.png|thumb]] [[File:VTS250.png|thumb]]
** general description of spring- and dome-loaded regulators [http://www.documentation.emersonprocess.com/groups/public/documents/bulletins/debul2008x012.pdf here]
** It appears that almost any standard screw-handle regulator can be converted to "dome loaded" by sealing up the housing cap and replacing the screw/spring with an air pressure fitting. See video below. A classic dual-stage like the [http://victortechnologies.com/IM_Uploads/doclib_8039_DocLib_2310_56-0623%20VTS%20250%20Series%20Regulators.pdf VTS250] should work very nicely for conversion
** As with manual regulators, if oxy- or fuel-tank pressure exceeds inlet rating of dome-loaded regulator, a first-stage tank regulator will be required.
** With the dome-loaded regulators, gas on/off as well as pressure setting can be obtained with low-cost shop air components and small valves (e.g [http://www.ebay.com/itm/4V130C-06-DC24V-Solenoid-Air-Valve-5-port-3-position-/290652595990 4V130C],[http://www.automationdirect.com/adc/Shopping/Catalog/Pneumatic_Components/Pneumatic_Valves_-a-_Accessories/Solenoid_Air_Valves_-a-_Accessories/5-port_(4-way),_3-pos.,_Body_Ported_-z-_Manifold_(AVS-5,AM_Series)/AVS-523C1-24D AVS-523C1])
** Using a [http://www.digikey.com/product-detail/en/MPXHZ6400AC6T1/MPXHZ6400AC6T1CT-ND/2057456 solid-state pressure sensor] for feedback, the Arduino can set the regulated pressures to programmed levels by actuating the pneumatic valves (increase/decrease loading pressure until feedback is correct). See video below and code on [http://github.com/chuck-h/ose-gaspressurecontrol github].
* use an electric igniter ([http://www.rvpartwholesaler.com/servlet/the-31/Dometic-2931132019-Refrigerator-Reignitor/Detail RV fridge igniter], [http://www.amazon.com/GrillPro-20620-Electric-Button-Igniter/dp/B000FJVKNM BBQ igniter], [https://www.sparkfun.com/products/11218 spark coil]).
* follow the sequencing of x,y,z motions, pressure changes, on/off, and ignition described by the folks on the forum thread above.
** Develop a library of pressure/time/positioning parameters for different material thicknesses and tip sizes that can be applied automatically by the G-code programming; this should minimize setup time and tweaking.

<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=H3Z3EHqTn44"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=WcUnHnZJ8xU"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=uwCbohxajOY"}
)
</script>
</html>

Installing a [http://www.clippard.com/part/MNV-1K needle valve] at the solenoid air valve improved control smoothness a bit compared to video above.

[[Image:ClippardNeedle.jpg|300px]]

=== oxygen ===

The cutting oxygen for the torch must be high purity (according to the ESAB note above less than 95% purity simply will not cut steel, and >99.5% is required for best quality). Until recently, this meant cryogenically separated oxygen, depending on a large capital plant, and thus the user must rely on commercially provided tank oxygen. For some 30 years, [http://en.wikipedia.org/wiki/Pressure_swing_adsorption pressure-swing-adsorption (PSA) separators] have been available, but standard designs do not remove argon and therefore result in about 95%-oxygen, 5%-argon output gas. PSA construction is low-tech and works very nicely at small scale, e.g. portable breathing-oxygen units, and would be quite suitable for OSE. 95% purity is probably adequate for the preheat flame (ChuckH conjecture). For higher-purity cutting oxygen, PSA can be extended with additional zeolite materials [http://www.ou.edu/class/che-design/a-design/projects-2007/Oxygen%20Generator-Presentation.pdf] or activated carbon [http://www.airsepcpd.com/airsepcpd/pdfs/12779.pdf]; despite [http://cr4.globalspec.com/blogentry/20384/To-Build-an-Oxygen-Concentrator-or-Not this discussion] there is no clear record of small-scale DIY implementation of 99% oxygen PSA.

=== oxyacetylene ===

Recommendations from Victor:

[[File:Victor_Oxy_Acetylene.jpg]]

Commercial oxy-fuel machine cutting heads
* [http://www.pierce.cz/production/components-for-building-and-retrofiting-cutting-machines/autogenni-motorizovana-rezaci-hlava.htm?lang=en Czech] one with capacitive height sensor feature

Components offered by JB: [[CNC_Torch_Table_Log#Oct._21.2C_2012]]

== Oxy-propane, -natural gas, etc ==
[http://www.cousesteel.com/AndysPlace/PropaneAcetylene.html Propane] instead of acetylene. Note the large preheat oxygen flow (not in a consistent stoichiometric ratio to fuel) in this chart. Odd.

[[File:VictorLPGcutting.png]]

Would [[Gasifier|gasifier-gas]] or [[biogas]] & oxygen work? Probably, as natural gas is primarily methane and is a commercially successful cutting-torch fuel.

=See Also=
[[Distributed_CNC_Motion_Control]]

[[Category:CNC Torch Table Prototype II]]
[[Category:Vann]]

CNC Torch Table 2/Control Overview

2013-11-01T04:59:28Z

Daniel Benamy: /* Testing */

{{Template:Category=Torch Table}}

=Overview=
<html><img src="https://docs.google.com/drawings/pub?id=1SKGaBa6N21DPzXm9ILuqwPubc6nnRSBAARbkKaEU9hw&w=480&h=360"></html>

=Motor controller and drivers=

==RAMPS==
Dan's using [[RAMPS]] in Oct 2013 to get the table up and running ASAP. The plan is then to replace it with something beefier so we can go faster.

==Alternatives==
See [[Stepper Motor Controller]] and [[Stepper Motor Driver]].

=Software=

==G-code Prep==
[[File:Toolchain.svg|thumb|toolchain pathways]]
[[ImplicitCAD]] (see also [[Parametric_Design_Pilot_Project]])

[[Gcodetools]]

[[DXF_to_G-code_Conversion_Tutorial]]

[[Computer_to_Microcontroller]]

Nesting software would be useful. Example commercial product [http://www.mynesting.com/ here]. Anything open source?

[[DXF_to_G-code_Conversion_Tutorial#Piercing|Gcode preheat]]

Correction for torch cut kerf width ("cutter compensation" in CNC lingo) needed. G40/G41 but grbl does not interpret these.

==G Code Runner==
aka firmware aka motor controller (distinct from motor driver)

This is the firmware running on Arduino which converts a series of G-code commands to step/direction pulses for the drivers.

===Marlin===
When Dan Benamy was getting things going again in Oct 2013, he was using Marlin because grbl doesn't work with RAMPS out of the box. Marlin also has pretty much out of the box support for 2 drivers feeding 2 motors on Y which we use for out long axis because it has 2 motors.

* I cloned marlin from github and checked out the Marlin_v1 tag.
* Edited Configuration.h
** #define MOTHERBOARD 35
** #define DISABLE_E true // For all extruders
** #define TEMP_SENSOR_0 0 // Since we don't have temp sensors
** #define TEMP_SENSOR_1 0 // Since we don't have temp sensors
** #define DEFAULT_AXIS_STEPS_PER_UNIT {128.0537,144.2128,200.0*8/3,760*1.1} // x and y are the right ballpark for the ose torch table at fef, see https://github.com/OSE/CNC-Torch-Table-OSE/issues/4#issuecomment-27460371 for where these numbers came from
** I set the "*ENDSTOP_INVERTING" consts as appropriate for our endstops by running gcode M119, seeing if an endstop was triggered, pushing the button, and running M119 again. If the logic was backwards, I flipped the appropriate boolean.
** I set the travel limits. There are 6 starting with "X_MAX_POS". I set the mins to 0. I set x and y max to 300 and z max to 150 for testing. Once we're calibrated and the table is fixed, we'll make these much bigger.
* I made home = 0,0,0 = the corner of the torch table near the ping pong table with the tool head fully down. Then I can stand at one end of the table and look down at it and it the standard x is right, y is up orientation. And when looking at it from the side, positive z is up.
* Edited Configuration_adv.h
** Uncommented "#define Y_DUAL_STEPPER_DRIVERS". I used Y because Marlin doesn't support dual drivers on X. We'll use Y as the long axis, X as the short axis, and Z as height. The 2nd Y will be output on the 2nd extruder port (E1, http://reprap.org/wiki/RAMPS_1.4#Wiring)
* Edited pins.h
** In the section for motherboards 33, 34 35, added "#define Y2_STEP_PIN 36", "#define Y2_DIR_PIN 34", and "#define Y2_ENABLE_PIN 30". This is a Marlin bug and I've submitted a fix upstream- https://github.com/ErikZalm/Marlin/pull/635
* Opened Marlin/Marlin/Marlin.pde in the arduino ide and clicked to compile and load it to the arduino.

=== grbl ===
When someone (Chuck?) was working on using the steppernug, they were running a modified grbl fork https://github.com/chuck-h/grbl/tree/edge. Changes from standard grbl [https://github.com/grbl/grbl]:
* Hardware I/O reassignment for steppernug interface
** different pin assignments on Arduino
** I2C extender
* substantially revised [[CNC_Torch_Table_Control_Overview#Limits_and_Homing|homing code]]
** dual X axis
** deep changes to stepper drive algorithm (implementing independent-axis trapezoidal move control during homing, as opposed to standard coordinated-axis move control for cutting) which should improve performance on long, limited-aceleration axes like torch table X and Y.

==Sending G Code to Firmware==

===Printrun===
This is what Dan's using in Oct 2013.

There's good installation instructions at https://github.com/kliment/Printrun. He wanted to do a source install but gave up when it wasn't easy with pip because it needs to use system wide python for access to the display.

* Change baud rate to 250000.
* Click connect.

===Other Software===
[[GcodeCommunications]]: other programs to send the g-code file from a host computer to a controller.

===Hardware===
Talk to Arduino with USB, or for longer distance RS422 e.g. [http://www.mouser.com/ProductDetail/Maxim-Integrated-Products/MAX3488ECSA+/?qs=sGAEpiMZZMvbyeSUH4qH%2fEqdkzg%252bEBoj MAX3488E]

== Testing ==
[[Stepper_Testing|Testing]]

Here's a test gcode file which Dan Benamy hand wrote. It works on marlin and draws a 2 hole by 1 hole plate- https://github.com/OSE/CNC-Torch-Table-OSE/issues/20#issuecomment-27547764

=Limits and Homing=

==Dual-motor homing==
The x axis (long axis) has 2 stepper motors. In the steppernug system, these have separate driver modules which receive identical step, direction, and enable signals.

For zeroing, the x axis needs to decouple - so if we get the x axis out of parallel, we can jog the x axes back into parallel by hitting their home switches independently. Steppernug supports this by allowing the Arduino to control a gate which blocks step pulses to the second driver module; in this condition the second motor will freeze and only the first motor will move. There is no provision for moving the second motor without moving the first, but that function is not required for the homing algorithm.

==Axis sequence==
# We will home the Z axis to its upper position first, just in case there are obstructions to clear during the X and Y axis homing.
# X and Y axes will do their initial fast moves to find home simultaneously (overlapped homing) to save time.
# The Y precision home movement will be performed.
# The dual-X-axis precision home maneuver will be performed.

==Limit and home switch configuration==

[[File:HomeLimit.PNG]]

''(TODO: add illustration showing distance coded reference mark options)''

''(Unconfirmed proposal at this time)'' [[User:ChuckH|ChuckH]] 23:42, 20 October 2012 (CEST)

Each axis has two switches: a '''limit switch''' and a '''home switch'''.
* The '''limit switch''' is activated at *either* end of travel. Its function is to protect against machine damage.
** Attempting to move further into the limit when the limit switch is active will cause all axis movement to stop, the torch to be shut off, and any other "safe shutdown" operation to be performed.
** The limit switch could be hit if the program erroneously commands the tool to move beyond the edge of the table
** The limit switch could also be hit if the torch table loses step (e.g. by hitting an obstruction) and subsequently performs a movement which takes it to the edge of the table
** The limit switch ''may'' be implemented as two physical switches wired in parallel, or the machine construction may permit a single switch to be used.
** Repeatable precision of actuation point is not very critical.
** This function is especially important if the table is expected to do automated cutting without constant human supervision.
* The '''home switch''' transitions between inactive and active at a point partway through the legal travel of the machine.
** For example, it might be active at the negative end of travel, and go inactive after 6 inches of movement.
** The home switch is used only for locating a repeatable zero position when the machine is powered on (or when recovering from lost steps)
*** Note that the logical "machine zero" coordinate may be placed at any programmed position relative to the physical home switch.
** Repeatable precision may be important
*** For the dual-motor axis, to establish accurate squareness
*** For all axes, to pick up in the middle of an interrupted job
*** If fixturing is used for repeat "production style" operations
** (''update, 14-July-2103:'') Instead of responding to a single flag location, the home switch could be actuated many times by multiple flags along the travel, with carefully designed nonuniform spacing between flags
*** This implements "distance coded reference marks" (DCRM), e.g. [[http://www.rls.si/en/dcrm-distance-coded-reference-mark-system--15934]], [[http://www.heidenhain.de/presentation/posa/en/index/N10584/N108A7/N10926.html]], [[http://www.newall.com/upload/content/file/SHG-TC%20-%20Distance-Coded%20Protocol%20-%20USA%20Ver%2004-07-05.pdf]]
*** DCRM is often applied to incremental linear encoder systems; the same principle is effective here using motor step count as the "incremental scale".
*** Using DCRM, the axis only needs to traverse two flag transitions after startup in order to unambiguously determine absolute position.
** By construction, the home switch is active at one end of travel and inactive at the other
*** This allows the machine to know which end of travel it is at in the event the limit switch is activated
*** This, in turn, allows the machine to permit recovery movement from the limit condition back into legal travel, while ignoring a command to go further into the limit zone.

There is an alternative switch configuration which places individual limit switches at the positive and negative limits of legal travel. However the configuration above is preferred because it supports faster homing and simpler control logic. Specifically:
# The substantial distance between the end of travel and the home switch location gives the machine overtravel room to do a controlled stop from high speed: maximum slewing speed can be used during initial homing without risk of slamming into the physical end-of-travel.
# Home switch placement can minimize the typical startup time.
#* If an axis is usually parked near one end of travel, the home switch can be placed there
#* If the axis position on startup is random, placing the home switch in the center of travel will minimize the average seek time.
#* DCRM can be implemented to obtain short startup/home times no matter what the starting position.
# The "safety shutdown" limit-switch function can be always active, and is independent of homing
#* The alternative approach requires logically repurposing a limit switch as home switch during home operations

==Switch Types==

The steppernug interface provides 5V power to sensor switches so either electronic or mechanical switches are easily accommodated.
* Mechanical microswitches are simple and effective.
* A Hall switch (e.g. [[Hall_Effect_Sensor_Module|this]]) is rugged but its position precision is probably only suitable for limits, not home switches.
* An optical interrupter (e.g. [http://www.mouser.com/ProductDetail/Sharp-Microelectronics/GP1A75EJ000F/?qs=%2fha2pyFaduhmXejJv184BikaBEqZykWweNnmsglkeuWVbMieAKIiNg%3d%3d Sharp GP1A75EJ000F]) can give precisely repeatable homing.

== Switch response time ==

The home switch should respond within one motor step time at the "creep speed" used for final approach. This speed might be ~100 steps/sec which gives us ~10ms.

The limit switch should respond quickly enough so that an emergency stop initiated by the switch will stop the machine motion before it hits a mechanical stop. This time is dependent on a lot of different design parameters, but is probably at least 10ms.

The limited response speed required allows us some latitude for noise suppression.

Since all switch signals pass through the I2C expander for I/O, there is about 150 usec (0.15ms) added, see [[Stepper_Testing#timing|here]].

=Torch control=

Software can use an M code to start the cut (e.g. open cutting-oxygen valve, strike plasma arc).

A second M code could shut down the entire torch (e.g. at the end of an unsupervised cutting session).

See also [[CNC_Torch_Table/Research_Development#Cutting_Torch]]

==Plasma Torch==

[[Plasma_Cutter_Design#Plasma_Cutter_PC_Interface]]

[http://www.metalwebnews.com/howto/plasma/presentation.pdf This presentation] on plasma-cutting accurate holes also suggests that ramping down plasma current while torch is still moving is good practice. (It makes the electrodes last longer.)

[[Sensing_Distance_from_Work_Piece|Z-axis arc voltage height control]]. Needs design work.

[[Plasma_Cutter_Cut_Speed_as_a_Function_of_Metal_Thickness|Cutting speed]]

Hypertherm:

[[File:PlasmaSpeed.jpg|400px]]

==Oxyfuel (oxyacetylene, oxypropane, etc) cutting torch==

During cutting, an oxyfuel cutting torch is literally burning the steel with a blast of oxygen; most of the heat comes from oxidizing the iron. However to start a new cut ("piercing") you must preheat the steel, relying on the acetylene or LPG for heat. After the steel is red hot you boost the oxygen flow and make the cut. We will want an oxygen-rated valve controlled by the microprocessor. "Oxygen-rated" mostly means the valve is thoroughly cleaned of all oil or flammable solvents that tend to explode on contact with pure oxygen; good practical reference [http://www.gmcscuba.com/pdf/CONVERTING%20DIVE%20TANKS%20FOR%20OXYGEN%20SERVICE.pdf here]. A solenoid valve like [http://www.lesman.com/acatalog/ASCO_8210_Oxygen-Service_Valves.html this] in combination with an ordinary regulator would give basic on/off control, but see better suggestions below.

Fairly technical application note about how to do good oxyfuel machine cutting from ESAB: [http://www.esabna.com/literature/Gas%20Apparatus/Miscellaneous/Oxy-Fuel_Cutting_Quality_0558006464.pdf]

[http://www.cnczone.com/forums/cnc_plasma_waterjet_machines/98346-cnc_oxy_fuel_discussion-25.html#post778595 This] ''long'' forum thread contains a lot of information about implementing small-shop CNC oxyfuel with programmed preheat, pierce, and cutting gas controls, auto ignition, etc. Based partly on this information, here are some control design suggestions for an Arduino-based CNC like [[CoolRAMPS]] or [[CNC_Torch_Table_Control_Overview#Steppernug_Driver_and_Interface_.28alternative_to_CoolRamps.29|Steppernug/grbl]]:
* use dome loaded regulators (e.g. Victor DL700 [http://www.amazon.com/Victor-0780-1188-DL700-500-Dome-Regulator/dp/B0047684PG] [http://victortechnologies.com/IM_Uploads/doclib_8016_DocLib_2331_56-0679%20%20DL%20700%20External%20Dome-Loaded%20Regulator%20Part%20Bulletin.pdf]) driven by regulated shop air [[File:DL700.png|thumb]] [[File:VTS250.png|thumb]]
** general description of spring- and dome-loaded regulators [http://www.documentation.emersonprocess.com/groups/public/documents/bulletins/debul2008x012.pdf here]
** It appears that almost any standard screw-handle regulator can be converted to "dome loaded" by sealing up the housing cap and replacing the screw/spring with an air pressure fitting. See video below. A classic dual-stage like the [http://victortechnologies.com/IM_Uploads/doclib_8039_DocLib_2310_56-0623%20VTS%20250%20Series%20Regulators.pdf VTS250] should work very nicely for conversion
** As with manual regulators, if oxy- or fuel-tank pressure exceeds inlet rating of dome-loaded regulator, a first-stage tank regulator will be required.
** With the dome-loaded regulators, gas on/off as well as pressure setting can be obtained with low-cost shop air components and small valves (e.g [http://www.ebay.com/itm/4V130C-06-DC24V-Solenoid-Air-Valve-5-port-3-position-/290652595990 4V130C],[http://www.automationdirect.com/adc/Shopping/Catalog/Pneumatic_Components/Pneumatic_Valves_-a-_Accessories/Solenoid_Air_Valves_-a-_Accessories/5-port_(4-way),_3-pos.,_Body_Ported_-z-_Manifold_(AVS-5,AM_Series)/AVS-523C1-24D AVS-523C1])
** Using a [http://www.digikey.com/product-detail/en/MPXHZ6400AC6T1/MPXHZ6400AC6T1CT-ND/2057456 solid-state pressure sensor] for feedback, the Arduino can set the regulated pressures to programmed levels by actuating the pneumatic valves (increase/decrease loading pressure until feedback is correct). See video below and code on [http://github.com/chuck-h/ose-gaspressurecontrol github].
* use an electric igniter ([http://www.rvpartwholesaler.com/servlet/the-31/Dometic-2931132019-Refrigerator-Reignitor/Detail RV fridge igniter], [http://www.amazon.com/GrillPro-20620-Electric-Button-Igniter/dp/B000FJVKNM BBQ igniter], [https://www.sparkfun.com/products/11218 spark coil]).
* follow the sequencing of x,y,z motions, pressure changes, on/off, and ignition described by the folks on the forum thread above.
** Develop a library of pressure/time/positioning parameters for different material thicknesses and tip sizes that can be applied automatically by the G-code programming; this should minimize setup time and tweaking.

<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=H3Z3EHqTn44"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=WcUnHnZJ8xU"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=uwCbohxajOY"}
)
</script>
</html>

Installing a [http://www.clippard.com/part/MNV-1K needle valve] at the solenoid air valve improved control smoothness a bit compared to video above.

[[Image:ClippardNeedle.jpg|300px]]

=== oxygen ===

The cutting oxygen for the torch must be high purity (according to the ESAB note above less than 95% purity simply will not cut steel, and >99.5% is required for best quality). Until recently, this meant cryogenically separated oxygen, depending on a large capital plant, and thus the user must rely on commercially provided tank oxygen. For some 30 years, [http://en.wikipedia.org/wiki/Pressure_swing_adsorption pressure-swing-adsorption (PSA) separators] have been available, but standard designs do not remove argon and therefore result in about 95%-oxygen, 5%-argon output gas. PSA construction is low-tech and works very nicely at small scale, e.g. portable breathing-oxygen units, and would be quite suitable for OSE. 95% purity is probably adequate for the preheat flame (ChuckH conjecture). For higher-purity cutting oxygen, PSA can be extended with additional zeolite materials [http://www.ou.edu/class/che-design/a-design/projects-2007/Oxygen%20Generator-Presentation.pdf] or activated carbon [http://www.airsepcpd.com/airsepcpd/pdfs/12779.pdf]; despite [http://cr4.globalspec.com/blogentry/20384/To-Build-an-Oxygen-Concentrator-or-Not this discussion] there is no clear record of small-scale DIY implementation of 99% oxygen PSA.

=== oxyacetylene ===

Recommendations from Victor:

[[File:Victor_Oxy_Acetylene.jpg]]

Commercial oxy-fuel machine cutting heads
* [http://www.pierce.cz/production/components-for-building-and-retrofiting-cutting-machines/autogenni-motorizovana-rezaci-hlava.htm?lang=en Czech] one with capacitive height sensor feature

Components offered by JB: [[CNC_Torch_Table_Log#Oct._21.2C_2012]]

== Oxy-propane, -natural gas, etc ==
[http://www.cousesteel.com/AndysPlace/PropaneAcetylene.html Propane] instead of acetylene. Note the large preheat oxygen flow (not in a consistent stoichiometric ratio to fuel) in this chart. Odd.

[[File:VictorLPGcutting.png]]

Would [[Gasifier|gasifier-gas]] or [[biogas]] & oxygen work? Probably, as natural gas is primarily methane and is a commercially successful cutting-torch fuel.

=See Also=
[[Distributed_CNC_Motion_Control]]

[[Category:CNC Torch Table Prototype II]]
[[Category:Vann]]

CNC Torch Table 2/Control Overview

2013-11-01T00:53:31Z

Daniel Benamy: /* Marlin */

{{Template:Category=Torch Table}}

=Overview=
<html><img src="https://docs.google.com/drawings/pub?id=1SKGaBa6N21DPzXm9ILuqwPubc6nnRSBAARbkKaEU9hw&w=480&h=360"></html>

=Motor controller and drivers=

==RAMPS==
Dan's using [[RAMPS]] in Oct 2013 to get the table up and running ASAP. The plan is then to replace it with something beefier so we can go faster.

==Alternatives==
See [[Stepper Motor Controller]] and [[Stepper Motor Driver]].

=Software=

==G-code Prep==
[[File:Toolchain.svg|thumb|toolchain pathways]]
[[ImplicitCAD]] (see also [[Parametric_Design_Pilot_Project]])

[[Gcodetools]]

[[DXF_to_G-code_Conversion_Tutorial]]

[[Computer_to_Microcontroller]]

Nesting software would be useful. Example commercial product [http://www.mynesting.com/ here]. Anything open source?

[[DXF_to_G-code_Conversion_Tutorial#Piercing|Gcode preheat]]

Correction for torch cut kerf width ("cutter compensation" in CNC lingo) needed. G40/G41 but grbl does not interpret these.

==G Code Runner==
aka firmware aka motor controller (distinct from motor driver)

This is the firmware running on Arduino which converts a series of G-code commands to step/direction pulses for the drivers.

===Marlin===
When Dan Benamy was getting things going again in Oct 2013, he was using Marlin because grbl doesn't work with RAMPS out of the box. Marlin also has pretty much out of the box support for 2 drivers feeding 2 motors on Y which we use for out long axis because it has 2 motors.

* I cloned marlin from github and checked out the Marlin_v1 tag.
* Edited Configuration.h
** #define MOTHERBOARD 35
** #define DISABLE_E true // For all extruders
** #define TEMP_SENSOR_0 0 // Since we don't have temp sensors
** #define TEMP_SENSOR_1 0 // Since we don't have temp sensors
** #define DEFAULT_AXIS_STEPS_PER_UNIT {128.0537,144.2128,200.0*8/3,760*1.1} // x and y are the right ballpark for the ose torch table at fef, see https://github.com/OSE/CNC-Torch-Table-OSE/issues/4#issuecomment-27460371 for where these numbers came from
** I set the "*ENDSTOP_INVERTING" consts as appropriate for our endstops by running gcode M119, seeing if an endstop was triggered, pushing the button, and running M119 again. If the logic was backwards, I flipped the appropriate boolean.
** I set the travel limits. There are 6 starting with "X_MAX_POS". I set the mins to 0. I set x and y max to 300 and z max to 150 for testing. Once we're calibrated and the table is fixed, we'll make these much bigger.
* I made home = 0,0,0 = the corner of the torch table near the ping pong table with the tool head fully down. Then I can stand at one end of the table and look down at it and it the standard x is right, y is up orientation. And when looking at it from the side, positive z is up.
* Edited Configuration_adv.h
** Uncommented "#define Y_DUAL_STEPPER_DRIVERS". I used Y because Marlin doesn't support dual drivers on X. We'll use Y as the long axis, X as the short axis, and Z as height. The 2nd Y will be output on the 2nd extruder port (E1, http://reprap.org/wiki/RAMPS_1.4#Wiring)
* Edited pins.h
** In the section for motherboards 33, 34 35, added "#define Y2_STEP_PIN 36", "#define Y2_DIR_PIN 34", and "#define Y2_ENABLE_PIN 30". This is a Marlin bug and I've submitted a fix upstream- https://github.com/ErikZalm/Marlin/pull/635
* Opened Marlin/Marlin/Marlin.pde in the arduino ide and clicked to compile and load it to the arduino.

=== grbl ===
When someone (Chuck?) was working on using the steppernug, they were running a modified grbl fork https://github.com/chuck-h/grbl/tree/edge. Changes from standard grbl [https://github.com/grbl/grbl]:
* Hardware I/O reassignment for steppernug interface
** different pin assignments on Arduino
** I2C extender
* substantially revised [[CNC_Torch_Table_Control_Overview#Limits_and_Homing|homing code]]
** dual X axis
** deep changes to stepper drive algorithm (implementing independent-axis trapezoidal move control during homing, as opposed to standard coordinated-axis move control for cutting) which should improve performance on long, limited-aceleration axes like torch table X and Y.

==Sending G Code to Firmware==

===Printrun===
This is what Dan's using in Oct 2013.

There's good installation instructions at https://github.com/kliment/Printrun. He wanted to do a source install but gave up when it wasn't easy with pip because it needs to use system wide python for access to the display.

* Change baud rate to 250000.
* Click connect.

===Other Software===
[[GcodeCommunications]]: other programs to send the g-code file from a host computer to a controller.

===Hardware===
Talk to Arduino with USB, or for longer distance RS422 e.g. [http://www.mouser.com/ProductDetail/Maxim-Integrated-Products/MAX3488ECSA+/?qs=sGAEpiMZZMvbyeSUH4qH%2fEqdkzg%252bEBoj MAX3488E]

== Testing ==
[[Stepper_Testing|Testing]]

=Limits and Homing=

==Dual-motor homing==
The x axis (long axis) has 2 stepper motors. In the steppernug system, these have separate driver modules which receive identical step, direction, and enable signals.

For zeroing, the x axis needs to decouple - so if we get the x axis out of parallel, we can jog the x axes back into parallel by hitting their home switches independently. Steppernug supports this by allowing the Arduino to control a gate which blocks step pulses to the second driver module; in this condition the second motor will freeze and only the first motor will move. There is no provision for moving the second motor without moving the first, but that function is not required for the homing algorithm.

==Axis sequence==
# We will home the Z axis to its upper position first, just in case there are obstructions to clear during the X and Y axis homing.
# X and Y axes will do their initial fast moves to find home simultaneously (overlapped homing) to save time.
# The Y precision home movement will be performed.
# The dual-X-axis precision home maneuver will be performed.

==Limit and home switch configuration==

[[File:HomeLimit.PNG]]

''(TODO: add illustration showing distance coded reference mark options)''

''(Unconfirmed proposal at this time)'' [[User:ChuckH|ChuckH]] 23:42, 20 October 2012 (CEST)

Each axis has two switches: a '''limit switch''' and a '''home switch'''.
* The '''limit switch''' is activated at *either* end of travel. Its function is to protect against machine damage.
** Attempting to move further into the limit when the limit switch is active will cause all axis movement to stop, the torch to be shut off, and any other "safe shutdown" operation to be performed.
** The limit switch could be hit if the program erroneously commands the tool to move beyond the edge of the table
** The limit switch could also be hit if the torch table loses step (e.g. by hitting an obstruction) and subsequently performs a movement which takes it to the edge of the table
** The limit switch ''may'' be implemented as two physical switches wired in parallel, or the machine construction may permit a single switch to be used.
** Repeatable precision of actuation point is not very critical.
** This function is especially important if the table is expected to do automated cutting without constant human supervision.
* The '''home switch''' transitions between inactive and active at a point partway through the legal travel of the machine.
** For example, it might be active at the negative end of travel, and go inactive after 6 inches of movement.
** The home switch is used only for locating a repeatable zero position when the machine is powered on (or when recovering from lost steps)
*** Note that the logical "machine zero" coordinate may be placed at any programmed position relative to the physical home switch.
** Repeatable precision may be important
*** For the dual-motor axis, to establish accurate squareness
*** For all axes, to pick up in the middle of an interrupted job
*** If fixturing is used for repeat "production style" operations
** (''update, 14-July-2103:'') Instead of responding to a single flag location, the home switch could be actuated many times by multiple flags along the travel, with carefully designed nonuniform spacing between flags
*** This implements "distance coded reference marks" (DCRM), e.g. [[http://www.rls.si/en/dcrm-distance-coded-reference-mark-system--15934]], [[http://www.heidenhain.de/presentation/posa/en/index/N10584/N108A7/N10926.html]], [[http://www.newall.com/upload/content/file/SHG-TC%20-%20Distance-Coded%20Protocol%20-%20USA%20Ver%2004-07-05.pdf]]
*** DCRM is often applied to incremental linear encoder systems; the same principle is effective here using motor step count as the "incremental scale".
*** Using DCRM, the axis only needs to traverse two flag transitions after startup in order to unambiguously determine absolute position.
** By construction, the home switch is active at one end of travel and inactive at the other
*** This allows the machine to know which end of travel it is at in the event the limit switch is activated
*** This, in turn, allows the machine to permit recovery movement from the limit condition back into legal travel, while ignoring a command to go further into the limit zone.

There is an alternative switch configuration which places individual limit switches at the positive and negative limits of legal travel. However the configuration above is preferred because it supports faster homing and simpler control logic. Specifically:
# The substantial distance between the end of travel and the home switch location gives the machine overtravel room to do a controlled stop from high speed: maximum slewing speed can be used during initial homing without risk of slamming into the physical end-of-travel.
# Home switch placement can minimize the typical startup time.
#* If an axis is usually parked near one end of travel, the home switch can be placed there
#* If the axis position on startup is random, placing the home switch in the center of travel will minimize the average seek time.
#* DCRM can be implemented to obtain short startup/home times no matter what the starting position.
# The "safety shutdown" limit-switch function can be always active, and is independent of homing
#* The alternative approach requires logically repurposing a limit switch as home switch during home operations

==Switch Types==

The steppernug interface provides 5V power to sensor switches so either electronic or mechanical switches are easily accommodated.
* Mechanical microswitches are simple and effective.
* A Hall switch (e.g. [[Hall_Effect_Sensor_Module|this]]) is rugged but its position precision is probably only suitable for limits, not home switches.
* An optical interrupter (e.g. [http://www.mouser.com/ProductDetail/Sharp-Microelectronics/GP1A75EJ000F/?qs=%2fha2pyFaduhmXejJv184BikaBEqZykWweNnmsglkeuWVbMieAKIiNg%3d%3d Sharp GP1A75EJ000F]) can give precisely repeatable homing.

== Switch response time ==

The home switch should respond within one motor step time at the "creep speed" used for final approach. This speed might be ~100 steps/sec which gives us ~10ms.

The limit switch should respond quickly enough so that an emergency stop initiated by the switch will stop the machine motion before it hits a mechanical stop. This time is dependent on a lot of different design parameters, but is probably at least 10ms.

The limited response speed required allows us some latitude for noise suppression.

Since all switch signals pass through the I2C expander for I/O, there is about 150 usec (0.15ms) added, see [[Stepper_Testing#timing|here]].

=Torch control=

Software can use an M code to start the cut (e.g. open cutting-oxygen valve, strike plasma arc).

A second M code could shut down the entire torch (e.g. at the end of an unsupervised cutting session).

See also [[CNC_Torch_Table/Research_Development#Cutting_Torch]]

==Plasma Torch==

[[Plasma_Cutter_Design#Plasma_Cutter_PC_Interface]]

[http://www.metalwebnews.com/howto/plasma/presentation.pdf This presentation] on plasma-cutting accurate holes also suggests that ramping down plasma current while torch is still moving is good practice. (It makes the electrodes last longer.)

[[Sensing_Distance_from_Work_Piece|Z-axis arc voltage height control]]. Needs design work.

[[Plasma_Cutter_Cut_Speed_as_a_Function_of_Metal_Thickness|Cutting speed]]

Hypertherm:

[[File:PlasmaSpeed.jpg|400px]]

==Oxyfuel (oxyacetylene, oxypropane, etc) cutting torch==

During cutting, an oxyfuel cutting torch is literally burning the steel with a blast of oxygen; most of the heat comes from oxidizing the iron. However to start a new cut ("piercing") you must preheat the steel, relying on the acetylene or LPG for heat. After the steel is red hot you boost the oxygen flow and make the cut. We will want an oxygen-rated valve controlled by the microprocessor. "Oxygen-rated" mostly means the valve is thoroughly cleaned of all oil or flammable solvents that tend to explode on contact with pure oxygen; good practical reference [http://www.gmcscuba.com/pdf/CONVERTING%20DIVE%20TANKS%20FOR%20OXYGEN%20SERVICE.pdf here]. A solenoid valve like [http://www.lesman.com/acatalog/ASCO_8210_Oxygen-Service_Valves.html this] in combination with an ordinary regulator would give basic on/off control, but see better suggestions below.

Fairly technical application note about how to do good oxyfuel machine cutting from ESAB: [http://www.esabna.com/literature/Gas%20Apparatus/Miscellaneous/Oxy-Fuel_Cutting_Quality_0558006464.pdf]

[http://www.cnczone.com/forums/cnc_plasma_waterjet_machines/98346-cnc_oxy_fuel_discussion-25.html#post778595 This] ''long'' forum thread contains a lot of information about implementing small-shop CNC oxyfuel with programmed preheat, pierce, and cutting gas controls, auto ignition, etc. Based partly on this information, here are some control design suggestions for an Arduino-based CNC like [[CoolRAMPS]] or [[CNC_Torch_Table_Control_Overview#Steppernug_Driver_and_Interface_.28alternative_to_CoolRamps.29|Steppernug/grbl]]:
* use dome loaded regulators (e.g. Victor DL700 [http://www.amazon.com/Victor-0780-1188-DL700-500-Dome-Regulator/dp/B0047684PG] [http://victortechnologies.com/IM_Uploads/doclib_8016_DocLib_2331_56-0679%20%20DL%20700%20External%20Dome-Loaded%20Regulator%20Part%20Bulletin.pdf]) driven by regulated shop air [[File:DL700.png|thumb]] [[File:VTS250.png|thumb]]
** general description of spring- and dome-loaded regulators [http://www.documentation.emersonprocess.com/groups/public/documents/bulletins/debul2008x012.pdf here]
** It appears that almost any standard screw-handle regulator can be converted to "dome loaded" by sealing up the housing cap and replacing the screw/spring with an air pressure fitting. See video below. A classic dual-stage like the [http://victortechnologies.com/IM_Uploads/doclib_8039_DocLib_2310_56-0623%20VTS%20250%20Series%20Regulators.pdf VTS250] should work very nicely for conversion
** As with manual regulators, if oxy- or fuel-tank pressure exceeds inlet rating of dome-loaded regulator, a first-stage tank regulator will be required.
** With the dome-loaded regulators, gas on/off as well as pressure setting can be obtained with low-cost shop air components and small valves (e.g [http://www.ebay.com/itm/4V130C-06-DC24V-Solenoid-Air-Valve-5-port-3-position-/290652595990 4V130C],[http://www.automationdirect.com/adc/Shopping/Catalog/Pneumatic_Components/Pneumatic_Valves_-a-_Accessories/Solenoid_Air_Valves_-a-_Accessories/5-port_(4-way),_3-pos.,_Body_Ported_-z-_Manifold_(AVS-5,AM_Series)/AVS-523C1-24D AVS-523C1])
** Using a [http://www.digikey.com/product-detail/en/MPXHZ6400AC6T1/MPXHZ6400AC6T1CT-ND/2057456 solid-state pressure sensor] for feedback, the Arduino can set the regulated pressures to programmed levels by actuating the pneumatic valves (increase/decrease loading pressure until feedback is correct). See video below and code on [http://github.com/chuck-h/ose-gaspressurecontrol github].
* use an electric igniter ([http://www.rvpartwholesaler.com/servlet/the-31/Dometic-2931132019-Refrigerator-Reignitor/Detail RV fridge igniter], [http://www.amazon.com/GrillPro-20620-Electric-Button-Igniter/dp/B000FJVKNM BBQ igniter], [https://www.sparkfun.com/products/11218 spark coil]).
* follow the sequencing of x,y,z motions, pressure changes, on/off, and ignition described by the folks on the forum thread above.
** Develop a library of pressure/time/positioning parameters for different material thicknesses and tip sizes that can be applied automatically by the G-code programming; this should minimize setup time and tweaking.

<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=H3Z3EHqTn44"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=WcUnHnZJ8xU"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=uwCbohxajOY"}
)
</script>
</html>

Installing a [http://www.clippard.com/part/MNV-1K needle valve] at the solenoid air valve improved control smoothness a bit compared to video above.

[[Image:ClippardNeedle.jpg|300px]]

=== oxygen ===

The cutting oxygen for the torch must be high purity (according to the ESAB note above less than 95% purity simply will not cut steel, and >99.5% is required for best quality). Until recently, this meant cryogenically separated oxygen, depending on a large capital plant, and thus the user must rely on commercially provided tank oxygen. For some 30 years, [http://en.wikipedia.org/wiki/Pressure_swing_adsorption pressure-swing-adsorption (PSA) separators] have been available, but standard designs do not remove argon and therefore result in about 95%-oxygen, 5%-argon output gas. PSA construction is low-tech and works very nicely at small scale, e.g. portable breathing-oxygen units, and would be quite suitable for OSE. 95% purity is probably adequate for the preheat flame (ChuckH conjecture). For higher-purity cutting oxygen, PSA can be extended with additional zeolite materials [http://www.ou.edu/class/che-design/a-design/projects-2007/Oxygen%20Generator-Presentation.pdf] or activated carbon [http://www.airsepcpd.com/airsepcpd/pdfs/12779.pdf]; despite [http://cr4.globalspec.com/blogentry/20384/To-Build-an-Oxygen-Concentrator-or-Not this discussion] there is no clear record of small-scale DIY implementation of 99% oxygen PSA.

=== oxyacetylene ===

Recommendations from Victor:

[[File:Victor_Oxy_Acetylene.jpg]]

Commercial oxy-fuel machine cutting heads
* [http://www.pierce.cz/production/components-for-building-and-retrofiting-cutting-machines/autogenni-motorizovana-rezaci-hlava.htm?lang=en Czech] one with capacitive height sensor feature

Components offered by JB: [[CNC_Torch_Table_Log#Oct._21.2C_2012]]

== Oxy-propane, -natural gas, etc ==
[http://www.cousesteel.com/AndysPlace/PropaneAcetylene.html Propane] instead of acetylene. Note the large preheat oxygen flow (not in a consistent stoichiometric ratio to fuel) in this chart. Odd.

[[File:VictorLPGcutting.png]]

Would [[Gasifier|gasifier-gas]] or [[biogas]] & oxygen work? Probably, as natural gas is primarily methane and is a commercially successful cutting-torch fuel.

=See Also=
[[Distributed_CNC_Motion_Control]]

[[Category:CNC Torch Table Prototype II]]
[[Category:Vann]]

CNC Torch Table 2/Control Overview

2013-11-01T00:41:27Z

Daniel Benamy: /* Marlin */

{{Template:Category=Torch Table}}

=Overview=
<html><img src="https://docs.google.com/drawings/pub?id=1SKGaBa6N21DPzXm9ILuqwPubc6nnRSBAARbkKaEU9hw&w=480&h=360"></html>

=Motor controller and drivers=

==RAMPS==
Dan's using [[RAMPS]] in Oct 2013 to get the table up and running ASAP. The plan is then to replace it with something beefier so we can go faster.

==Alternatives==
See [[Stepper Motor Controller]] and [[Stepper Motor Driver]].

=Software=

==G-code Prep==
[[File:Toolchain.svg|thumb|toolchain pathways]]
[[ImplicitCAD]] (see also [[Parametric_Design_Pilot_Project]])

[[Gcodetools]]

[[DXF_to_G-code_Conversion_Tutorial]]

[[Computer_to_Microcontroller]]

Nesting software would be useful. Example commercial product [http://www.mynesting.com/ here]. Anything open source?

[[DXF_to_G-code_Conversion_Tutorial#Piercing|Gcode preheat]]

Correction for torch cut kerf width ("cutter compensation" in CNC lingo) needed. G40/G41 but grbl does not interpret these.

==G Code Runner==
aka firmware aka motor controller (distinct from motor driver)

This is the firmware running on Arduino which converts a series of G-code commands to step/direction pulses for the drivers.

===Marlin===
When Dan Benamy was getting things going again in Oct 2013, he was using Marlin because grbl doesn't work with RAMPS out of the box.

Marlin will need some modifications if we want our 2 long axis motors to be on separate drivers rather than in parallel on one driver. See http://shapeoko.com/forum/viewtopic.php?f=4&t=1095 for someone doing this.

* I cloned marlin from github and checked out the Marlin_v1 tag.
* Edited Configuration.h
** #define MOTHERBOARD 35 - not sure if this is what we want
** #define DISABLE_E true // For all extruders
** #define TEMP_SENSOR_0 0 // Since we don't have temp sensors
** #define TEMP_SENSOR_1 0 // Since we don't have temp sensors
** #define DEFAULT_AXIS_STEPS_PER_UNIT {128.0537,144.2128,200.0*8/3,760*1.1} // x and y are the right ballpark for the ose torch table at fef, see https://github.com/OSE/CNC-Torch-Table-OSE/issues/4#issuecomment-27460371 for where these numbers came from
** I set the "*ENDSTOP_INVERTING" consts as appropriate for our buttons by running gcode M119, seeing if an endstop was triggered, pushing the button, and running M119 again. If the logic was backwards, I flipped the appropriate bool in marlin.
** I set the travel limits. There are 6 starting with "X_MAX_POS". I set the mins to 0. x and y max to 300 and z max to 150 for testing. Once we're calibrated and the table is fixed, there will be made much bigger.
* I made home = 0,0,0 = the corner of the torch table near the ping pong table & tool head fully down. Then I can stand at one end of the table and look down at it and it the standard x is right, y is up orientation. And when looking at it from the side, positive z is up.
* Edited Configuration_adv.h
** Uncommented "#define Y_DUAL_STEPPER_DRIVERS". I used Y because Marlin doesn't support dual drivers on X. We'll use Y as the long axis, X as the short axis, and Z as height. The 2nd Y will be output on the 2nd extruder port (E1, http://reprap.org/wiki/RAMPS_1.4#Wiring)
* Edited pins.h
** In the section for motherboards 33, 34 35, added "#define Y2_STEP_PIN 36", "#define Y2_DIR_PIN 34", and "#define Y2_ENABLE_PIN 30". This is a Marlin bug and I've submitted a fix upstream- https://github.com/ErikZalm/Marlin/pull/635
* Opened Marlin/Marlin/Marlin.pde in the arduino ide and clicked to compile and load it to the arduino.

=== grbl ===
When someone (Chuck?) was working on using the steppernug, they were running a modified grbl fork https://github.com/chuck-h/grbl/tree/edge. Changes from standard grbl [https://github.com/grbl/grbl]:
* Hardware I/O reassignment for steppernug interface
** different pin assignments on Arduino
** I2C extender
* substantially revised [[CNC_Torch_Table_Control_Overview#Limits_and_Homing|homing code]]
** dual X axis
** deep changes to stepper drive algorithm (implementing independent-axis trapezoidal move control during homing, as opposed to standard coordinated-axis move control for cutting) which should improve performance on long, limited-aceleration axes like torch table X and Y.

==Sending G Code to Firmware==

===Printrun===
This is what Dan's using in Oct 2013.

There's good installation instructions at https://github.com/kliment/Printrun. He wanted to do a source install but gave up when it wasn't easy with pip because it needs to use system wide python for access to the display.

* Change baud rate to 250000.
* Click connect.

===Other Software===
[[GcodeCommunications]]: other programs to send the g-code file from a host computer to a controller.

===Hardware===
Talk to Arduino with USB, or for longer distance RS422 e.g. [http://www.mouser.com/ProductDetail/Maxim-Integrated-Products/MAX3488ECSA+/?qs=sGAEpiMZZMvbyeSUH4qH%2fEqdkzg%252bEBoj MAX3488E]

== Testing ==
[[Stepper_Testing|Testing]]

=Limits and Homing=

==Dual-motor homing==
The x axis (long axis) has 2 stepper motors. In the steppernug system, these have separate driver modules which receive identical step, direction, and enable signals.

For zeroing, the x axis needs to decouple - so if we get the x axis out of parallel, we can jog the x axes back into parallel by hitting their home switches independently. Steppernug supports this by allowing the Arduino to control a gate which blocks step pulses to the second driver module; in this condition the second motor will freeze and only the first motor will move. There is no provision for moving the second motor without moving the first, but that function is not required for the homing algorithm.

==Axis sequence==
# We will home the Z axis to its upper position first, just in case there are obstructions to clear during the X and Y axis homing.
# X and Y axes will do their initial fast moves to find home simultaneously (overlapped homing) to save time.
# The Y precision home movement will be performed.
# The dual-X-axis precision home maneuver will be performed.

==Limit and home switch configuration==

[[File:HomeLimit.PNG]]

''(TODO: add illustration showing distance coded reference mark options)''

''(Unconfirmed proposal at this time)'' [[User:ChuckH|ChuckH]] 23:42, 20 October 2012 (CEST)

Each axis has two switches: a '''limit switch''' and a '''home switch'''.
* The '''limit switch''' is activated at *either* end of travel. Its function is to protect against machine damage.
** Attempting to move further into the limit when the limit switch is active will cause all axis movement to stop, the torch to be shut off, and any other "safe shutdown" operation to be performed.
** The limit switch could be hit if the program erroneously commands the tool to move beyond the edge of the table
** The limit switch could also be hit if the torch table loses step (e.g. by hitting an obstruction) and subsequently performs a movement which takes it to the edge of the table
** The limit switch ''may'' be implemented as two physical switches wired in parallel, or the machine construction may permit a single switch to be used.
** Repeatable precision of actuation point is not very critical.
** This function is especially important if the table is expected to do automated cutting without constant human supervision.
* The '''home switch''' transitions between inactive and active at a point partway through the legal travel of the machine.
** For example, it might be active at the negative end of travel, and go inactive after 6 inches of movement.
** The home switch is used only for locating a repeatable zero position when the machine is powered on (or when recovering from lost steps)
*** Note that the logical "machine zero" coordinate may be placed at any programmed position relative to the physical home switch.
** Repeatable precision may be important
*** For the dual-motor axis, to establish accurate squareness
*** For all axes, to pick up in the middle of an interrupted job
*** If fixturing is used for repeat "production style" operations
** (''update, 14-July-2103:'') Instead of responding to a single flag location, the home switch could be actuated many times by multiple flags along the travel, with carefully designed nonuniform spacing between flags
*** This implements "distance coded reference marks" (DCRM), e.g. [[http://www.rls.si/en/dcrm-distance-coded-reference-mark-system--15934]], [[http://www.heidenhain.de/presentation/posa/en/index/N10584/N108A7/N10926.html]], [[http://www.newall.com/upload/content/file/SHG-TC%20-%20Distance-Coded%20Protocol%20-%20USA%20Ver%2004-07-05.pdf]]
*** DCRM is often applied to incremental linear encoder systems; the same principle is effective here using motor step count as the "incremental scale".
*** Using DCRM, the axis only needs to traverse two flag transitions after startup in order to unambiguously determine absolute position.
** By construction, the home switch is active at one end of travel and inactive at the other
*** This allows the machine to know which end of travel it is at in the event the limit switch is activated
*** This, in turn, allows the machine to permit recovery movement from the limit condition back into legal travel, while ignoring a command to go further into the limit zone.

There is an alternative switch configuration which places individual limit switches at the positive and negative limits of legal travel. However the configuration above is preferred because it supports faster homing and simpler control logic. Specifically:
# The substantial distance between the end of travel and the home switch location gives the machine overtravel room to do a controlled stop from high speed: maximum slewing speed can be used during initial homing without risk of slamming into the physical end-of-travel.
# Home switch placement can minimize the typical startup time.
#* If an axis is usually parked near one end of travel, the home switch can be placed there
#* If the axis position on startup is random, placing the home switch in the center of travel will minimize the average seek time.
#* DCRM can be implemented to obtain short startup/home times no matter what the starting position.
# The "safety shutdown" limit-switch function can be always active, and is independent of homing
#* The alternative approach requires logically repurposing a limit switch as home switch during home operations

==Switch Types==

The steppernug interface provides 5V power to sensor switches so either electronic or mechanical switches are easily accommodated.
* Mechanical microswitches are simple and effective.
* A Hall switch (e.g. [[Hall_Effect_Sensor_Module|this]]) is rugged but its position precision is probably only suitable for limits, not home switches.
* An optical interrupter (e.g. [http://www.mouser.com/ProductDetail/Sharp-Microelectronics/GP1A75EJ000F/?qs=%2fha2pyFaduhmXejJv184BikaBEqZykWweNnmsglkeuWVbMieAKIiNg%3d%3d Sharp GP1A75EJ000F]) can give precisely repeatable homing.

== Switch response time ==

The home switch should respond within one motor step time at the "creep speed" used for final approach. This speed might be ~100 steps/sec which gives us ~10ms.

The limit switch should respond quickly enough so that an emergency stop initiated by the switch will stop the machine motion before it hits a mechanical stop. This time is dependent on a lot of different design parameters, but is probably at least 10ms.

The limited response speed required allows us some latitude for noise suppression.

Since all switch signals pass through the I2C expander for I/O, there is about 150 usec (0.15ms) added, see [[Stepper_Testing#timing|here]].

=Torch control=

Software can use an M code to start the cut (e.g. open cutting-oxygen valve, strike plasma arc).

A second M code could shut down the entire torch (e.g. at the end of an unsupervised cutting session).

See also [[CNC_Torch_Table/Research_Development#Cutting_Torch]]

==Plasma Torch==

[[Plasma_Cutter_Design#Plasma_Cutter_PC_Interface]]

[http://www.metalwebnews.com/howto/plasma/presentation.pdf This presentation] on plasma-cutting accurate holes also suggests that ramping down plasma current while torch is still moving is good practice. (It makes the electrodes last longer.)

[[Sensing_Distance_from_Work_Piece|Z-axis arc voltage height control]]. Needs design work.

[[Plasma_Cutter_Cut_Speed_as_a_Function_of_Metal_Thickness|Cutting speed]]

Hypertherm:

[[File:PlasmaSpeed.jpg|400px]]

==Oxyfuel (oxyacetylene, oxypropane, etc) cutting torch==

During cutting, an oxyfuel cutting torch is literally burning the steel with a blast of oxygen; most of the heat comes from oxidizing the iron. However to start a new cut ("piercing") you must preheat the steel, relying on the acetylene or LPG for heat. After the steel is red hot you boost the oxygen flow and make the cut. We will want an oxygen-rated valve controlled by the microprocessor. "Oxygen-rated" mostly means the valve is thoroughly cleaned of all oil or flammable solvents that tend to explode on contact with pure oxygen; good practical reference [http://www.gmcscuba.com/pdf/CONVERTING%20DIVE%20TANKS%20FOR%20OXYGEN%20SERVICE.pdf here]. A solenoid valve like [http://www.lesman.com/acatalog/ASCO_8210_Oxygen-Service_Valves.html this] in combination with an ordinary regulator would give basic on/off control, but see better suggestions below.

Fairly technical application note about how to do good oxyfuel machine cutting from ESAB: [http://www.esabna.com/literature/Gas%20Apparatus/Miscellaneous/Oxy-Fuel_Cutting_Quality_0558006464.pdf]

[http://www.cnczone.com/forums/cnc_plasma_waterjet_machines/98346-cnc_oxy_fuel_discussion-25.html#post778595 This] ''long'' forum thread contains a lot of information about implementing small-shop CNC oxyfuel with programmed preheat, pierce, and cutting gas controls, auto ignition, etc. Based partly on this information, here are some control design suggestions for an Arduino-based CNC like [[CoolRAMPS]] or [[CNC_Torch_Table_Control_Overview#Steppernug_Driver_and_Interface_.28alternative_to_CoolRamps.29|Steppernug/grbl]]:
* use dome loaded regulators (e.g. Victor DL700 [http://www.amazon.com/Victor-0780-1188-DL700-500-Dome-Regulator/dp/B0047684PG] [http://victortechnologies.com/IM_Uploads/doclib_8016_DocLib_2331_56-0679%20%20DL%20700%20External%20Dome-Loaded%20Regulator%20Part%20Bulletin.pdf]) driven by regulated shop air [[File:DL700.png|thumb]] [[File:VTS250.png|thumb]]
** general description of spring- and dome-loaded regulators [http://www.documentation.emersonprocess.com/groups/public/documents/bulletins/debul2008x012.pdf here]
** It appears that almost any standard screw-handle regulator can be converted to "dome loaded" by sealing up the housing cap and replacing the screw/spring with an air pressure fitting. See video below. A classic dual-stage like the [http://victortechnologies.com/IM_Uploads/doclib_8039_DocLib_2310_56-0623%20VTS%20250%20Series%20Regulators.pdf VTS250] should work very nicely for conversion
** As with manual regulators, if oxy- or fuel-tank pressure exceeds inlet rating of dome-loaded regulator, a first-stage tank regulator will be required.
** With the dome-loaded regulators, gas on/off as well as pressure setting can be obtained with low-cost shop air components and small valves (e.g [http://www.ebay.com/itm/4V130C-06-DC24V-Solenoid-Air-Valve-5-port-3-position-/290652595990 4V130C],[http://www.automationdirect.com/adc/Shopping/Catalog/Pneumatic_Components/Pneumatic_Valves_-a-_Accessories/Solenoid_Air_Valves_-a-_Accessories/5-port_(4-way),_3-pos.,_Body_Ported_-z-_Manifold_(AVS-5,AM_Series)/AVS-523C1-24D AVS-523C1])
** Using a [http://www.digikey.com/product-detail/en/MPXHZ6400AC6T1/MPXHZ6400AC6T1CT-ND/2057456 solid-state pressure sensor] for feedback, the Arduino can set the regulated pressures to programmed levels by actuating the pneumatic valves (increase/decrease loading pressure until feedback is correct). See video below and code on [http://github.com/chuck-h/ose-gaspressurecontrol github].
* use an electric igniter ([http://www.rvpartwholesaler.com/servlet/the-31/Dometic-2931132019-Refrigerator-Reignitor/Detail RV fridge igniter], [http://www.amazon.com/GrillPro-20620-Electric-Button-Igniter/dp/B000FJVKNM BBQ igniter], [https://www.sparkfun.com/products/11218 spark coil]).
* follow the sequencing of x,y,z motions, pressure changes, on/off, and ignition described by the folks on the forum thread above.
** Develop a library of pressure/time/positioning parameters for different material thicknesses and tip sizes that can be applied automatically by the G-code programming; this should minimize setup time and tweaking.

<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=H3Z3EHqTn44"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=WcUnHnZJ8xU"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=uwCbohxajOY"}
)
</script>
</html>

Installing a [http://www.clippard.com/part/MNV-1K needle valve] at the solenoid air valve improved control smoothness a bit compared to video above.

[[Image:ClippardNeedle.jpg|300px]]

=== oxygen ===

The cutting oxygen for the torch must be high purity (according to the ESAB note above less than 95% purity simply will not cut steel, and >99.5% is required for best quality). Until recently, this meant cryogenically separated oxygen, depending on a large capital plant, and thus the user must rely on commercially provided tank oxygen. For some 30 years, [http://en.wikipedia.org/wiki/Pressure_swing_adsorption pressure-swing-adsorption (PSA) separators] have been available, but standard designs do not remove argon and therefore result in about 95%-oxygen, 5%-argon output gas. PSA construction is low-tech and works very nicely at small scale, e.g. portable breathing-oxygen units, and would be quite suitable for OSE. 95% purity is probably adequate for the preheat flame (ChuckH conjecture). For higher-purity cutting oxygen, PSA can be extended with additional zeolite materials [http://www.ou.edu/class/che-design/a-design/projects-2007/Oxygen%20Generator-Presentation.pdf] or activated carbon [http://www.airsepcpd.com/airsepcpd/pdfs/12779.pdf]; despite [http://cr4.globalspec.com/blogentry/20384/To-Build-an-Oxygen-Concentrator-or-Not this discussion] there is no clear record of small-scale DIY implementation of 99% oxygen PSA.

=== oxyacetylene ===

Recommendations from Victor:

[[File:Victor_Oxy_Acetylene.jpg]]

Commercial oxy-fuel machine cutting heads
* [http://www.pierce.cz/production/components-for-building-and-retrofiting-cutting-machines/autogenni-motorizovana-rezaci-hlava.htm?lang=en Czech] one with capacitive height sensor feature

Components offered by JB: [[CNC_Torch_Table_Log#Oct._21.2C_2012]]

== Oxy-propane, -natural gas, etc ==
[http://www.cousesteel.com/AndysPlace/PropaneAcetylene.html Propane] instead of acetylene. Note the large preheat oxygen flow (not in a consistent stoichiometric ratio to fuel) in this chart. Odd.

[[File:VictorLPGcutting.png]]

Would [[Gasifier|gasifier-gas]] or [[biogas]] & oxygen work? Probably, as natural gas is primarily methane and is a commercially successful cutting-torch fuel.

=See Also=
[[Distributed_CNC_Motion_Control]]

[[Category:CNC Torch Table Prototype II]]
[[Category:Vann]]

CNC Torch Table 2/Control Overview

2013-10-31T22:49:45Z

Daniel Benamy: /* Marlin */

{{Template:Category=Torch Table}}

=Overview=
<html><img src="https://docs.google.com/drawings/pub?id=1SKGaBa6N21DPzXm9ILuqwPubc6nnRSBAARbkKaEU9hw&w=480&h=360"></html>

=Motor controller and drivers=

==RAMPS==
Dan's using [[RAMPS]] in Oct 2013 to get the table up and running ASAP. The plan is then to replace it with something beefier so we can go faster.

==Alternatives==
See [[Stepper Motor Controller]] and [[Stepper Motor Driver]].

=Software=

==G-code Prep==
[[File:Toolchain.svg|thumb|toolchain pathways]]
[[ImplicitCAD]] (see also [[Parametric_Design_Pilot_Project]])

[[Gcodetools]]

[[DXF_to_G-code_Conversion_Tutorial]]

[[Computer_to_Microcontroller]]

Nesting software would be useful. Example commercial product [http://www.mynesting.com/ here]. Anything open source?

[[DXF_to_G-code_Conversion_Tutorial#Piercing|Gcode preheat]]

Correction for torch cut kerf width ("cutter compensation" in CNC lingo) needed. G40/G41 but grbl does not interpret these.

==G Code Runner==
aka firmware aka motor controller (distinct from motor driver)

This is the firmware running on Arduino which converts a series of G-code commands to step/direction pulses for the drivers.

===Marlin===
When Dan Benamy was getting things going again in Oct 2013, he was using Marlin because grbl doesn't work with RAMPS out of the box.

Marlin will need some modifications if we want our 2 long axis motors to be on separate drivers rather than in parallel on one driver. See http://shapeoko.com/forum/viewtopic.php?f=4&t=1095 for someone doing this.

* I cloned marlin from github and checked out the Marlin_v1 tag.
* Edited Configuration.h
** #define MOTHERBOARD 35 - not sure if this is what we want
** #define DISABLE_E true // For all extruders
** #define TEMP_SENSOR_0 0 // Since we don't have temp sensors
** #define TEMP_SENSOR_1 0 // Since we don't have temp sensors
** #define DEFAULT_AXIS_STEPS_PER_UNIT {128.0537,144.2128,200.0*8/3,760*1.1} // x and y are the right ballpark for the ose torch table at fef, see https://github.com/OSE/CNC-Torch-Table-OSE/issues/4#issuecomment-27460371 for where these numbers came from
** I set the "*ENDSTOP_INVERTING" consts as appropriate for our buttons by running gcode M119, seeing if an endstop was triggered, pushing the button, and running M119 again. If the logic was backwards, I flipped the appropriate bool in marlin.
** I set the travel limits. There are 6 starting with "X_MAX_POS". I set the mins to 0. x and y max to 300 and z max to 150 for testing. Once we're calibrated and the table is fixed, there will be made much bigger.
* To make things a little easier to think about I made home = 0,0,0 = the corner of the torch table near the ping pong table & tool head fully up. Then I can stand at one end of the table and look down at it and it the standard x is right, y is up orientation.
* Edited Configuration_adv.h
** Uncommented "#define Y_DUAL_STEPPER_DRIVERS". I used Y because Marlin doesn't support dual drivers on X. We'll use Y as the long axis, X as the short axis, and Z as height. The 2nd Y will be output on the 2nd extruder port (E1, http://reprap.org/wiki/RAMPS_1.4#Wiring)
* Edited pins.h
** In the section for motherboards 33, 34 35, added "#define Y2_STEP_PIN 36", "#define Y2_DIR_PIN 34", and "#define Y2_ENABLE_PIN 30". This is a Marlin bug and I've submitted a fix upstream- https://github.com/ErikZalm/Marlin/pull/635
* Opened Marlin/Marlin/Marlin.pde in the arduino ide and clicked to compile and load it to the arduino.

=== grbl ===
When someone (Chuck?) was working on using the steppernug, they were running a modified grbl fork https://github.com/chuck-h/grbl/tree/edge. Changes from standard grbl [https://github.com/grbl/grbl]:
* Hardware I/O reassignment for steppernug interface
** different pin assignments on Arduino
** I2C extender
* substantially revised [[CNC_Torch_Table_Control_Overview#Limits_and_Homing|homing code]]
** dual X axis
** deep changes to stepper drive algorithm (implementing independent-axis trapezoidal move control during homing, as opposed to standard coordinated-axis move control for cutting) which should improve performance on long, limited-aceleration axes like torch table X and Y.

==Sending G Code to Firmware==

===Printrun===
This is what Dan's using in Oct 2013.

There's good installation instructions at https://github.com/kliment/Printrun. He wanted to do a source install but gave up when it wasn't easy with pip because it needs to use system wide python for access to the display.

* Change baud rate to 250000.
* Click connect.

===Other Software===
[[GcodeCommunications]]: other programs to send the g-code file from a host computer to a controller.

===Hardware===
Talk to Arduino with USB, or for longer distance RS422 e.g. [http://www.mouser.com/ProductDetail/Maxim-Integrated-Products/MAX3488ECSA+/?qs=sGAEpiMZZMvbyeSUH4qH%2fEqdkzg%252bEBoj MAX3488E]

== Testing ==
[[Stepper_Testing|Testing]]

=Limits and Homing=

==Dual-motor homing==
The x axis (long axis) has 2 stepper motors. In the steppernug system, these have separate driver modules which receive identical step, direction, and enable signals.

For zeroing, the x axis needs to decouple - so if we get the x axis out of parallel, we can jog the x axes back into parallel by hitting their home switches independently. Steppernug supports this by allowing the Arduino to control a gate which blocks step pulses to the second driver module; in this condition the second motor will freeze and only the first motor will move. There is no provision for moving the second motor without moving the first, but that function is not required for the homing algorithm.

==Axis sequence==
# We will home the Z axis to its upper position first, just in case there are obstructions to clear during the X and Y axis homing.
# X and Y axes will do their initial fast moves to find home simultaneously (overlapped homing) to save time.
# The Y precision home movement will be performed.
# The dual-X-axis precision home maneuver will be performed.

==Limit and home switch configuration==

[[File:HomeLimit.PNG]]

''(TODO: add illustration showing distance coded reference mark options)''

''(Unconfirmed proposal at this time)'' [[User:ChuckH|ChuckH]] 23:42, 20 October 2012 (CEST)

Each axis has two switches: a '''limit switch''' and a '''home switch'''.
* The '''limit switch''' is activated at *either* end of travel. Its function is to protect against machine damage.
** Attempting to move further into the limit when the limit switch is active will cause all axis movement to stop, the torch to be shut off, and any other "safe shutdown" operation to be performed.
** The limit switch could be hit if the program erroneously commands the tool to move beyond the edge of the table
** The limit switch could also be hit if the torch table loses step (e.g. by hitting an obstruction) and subsequently performs a movement which takes it to the edge of the table
** The limit switch ''may'' be implemented as two physical switches wired in parallel, or the machine construction may permit a single switch to be used.
** Repeatable precision of actuation point is not very critical.
** This function is especially important if the table is expected to do automated cutting without constant human supervision.
* The '''home switch''' transitions between inactive and active at a point partway through the legal travel of the machine.
** For example, it might be active at the negative end of travel, and go inactive after 6 inches of movement.
** The home switch is used only for locating a repeatable zero position when the machine is powered on (or when recovering from lost steps)
*** Note that the logical "machine zero" coordinate may be placed at any programmed position relative to the physical home switch.
** Repeatable precision may be important
*** For the dual-motor axis, to establish accurate squareness
*** For all axes, to pick up in the middle of an interrupted job
*** If fixturing is used for repeat "production style" operations
** (''update, 14-July-2103:'') Instead of responding to a single flag location, the home switch could be actuated many times by multiple flags along the travel, with carefully designed nonuniform spacing between flags
*** This implements "distance coded reference marks" (DCRM), e.g. [[http://www.rls.si/en/dcrm-distance-coded-reference-mark-system--15934]], [[http://www.heidenhain.de/presentation/posa/en/index/N10584/N108A7/N10926.html]], [[http://www.newall.com/upload/content/file/SHG-TC%20-%20Distance-Coded%20Protocol%20-%20USA%20Ver%2004-07-05.pdf]]
*** DCRM is often applied to incremental linear encoder systems; the same principle is effective here using motor step count as the "incremental scale".
*** Using DCRM, the axis only needs to traverse two flag transitions after startup in order to unambiguously determine absolute position.
** By construction, the home switch is active at one end of travel and inactive at the other
*** This allows the machine to know which end of travel it is at in the event the limit switch is activated
*** This, in turn, allows the machine to permit recovery movement from the limit condition back into legal travel, while ignoring a command to go further into the limit zone.

There is an alternative switch configuration which places individual limit switches at the positive and negative limits of legal travel. However the configuration above is preferred because it supports faster homing and simpler control logic. Specifically:
# The substantial distance between the end of travel and the home switch location gives the machine overtravel room to do a controlled stop from high speed: maximum slewing speed can be used during initial homing without risk of slamming into the physical end-of-travel.
# Home switch placement can minimize the typical startup time.
#* If an axis is usually parked near one end of travel, the home switch can be placed there
#* If the axis position on startup is random, placing the home switch in the center of travel will minimize the average seek time.
#* DCRM can be implemented to obtain short startup/home times no matter what the starting position.
# The "safety shutdown" limit-switch function can be always active, and is independent of homing
#* The alternative approach requires logically repurposing a limit switch as home switch during home operations

==Switch Types==

The steppernug interface provides 5V power to sensor switches so either electronic or mechanical switches are easily accommodated.
* Mechanical microswitches are simple and effective.
* A Hall switch (e.g. [[Hall_Effect_Sensor_Module|this]]) is rugged but its position precision is probably only suitable for limits, not home switches.
* An optical interrupter (e.g. [http://www.mouser.com/ProductDetail/Sharp-Microelectronics/GP1A75EJ000F/?qs=%2fha2pyFaduhmXejJv184BikaBEqZykWweNnmsglkeuWVbMieAKIiNg%3d%3d Sharp GP1A75EJ000F]) can give precisely repeatable homing.

== Switch response time ==

The home switch should respond within one motor step time at the "creep speed" used for final approach. This speed might be ~100 steps/sec which gives us ~10ms.

The limit switch should respond quickly enough so that an emergency stop initiated by the switch will stop the machine motion before it hits a mechanical stop. This time is dependent on a lot of different design parameters, but is probably at least 10ms.

The limited response speed required allows us some latitude for noise suppression.

Since all switch signals pass through the I2C expander for I/O, there is about 150 usec (0.15ms) added, see [[Stepper_Testing#timing|here]].

=Torch control=

Software can use an M code to start the cut (e.g. open cutting-oxygen valve, strike plasma arc).

A second M code could shut down the entire torch (e.g. at the end of an unsupervised cutting session).

See also [[CNC_Torch_Table/Research_Development#Cutting_Torch]]

==Plasma Torch==

[[Plasma_Cutter_Design#Plasma_Cutter_PC_Interface]]

[http://www.metalwebnews.com/howto/plasma/presentation.pdf This presentation] on plasma-cutting accurate holes also suggests that ramping down plasma current while torch is still moving is good practice. (It makes the electrodes last longer.)

[[Sensing_Distance_from_Work_Piece|Z-axis arc voltage height control]]. Needs design work.

[[Plasma_Cutter_Cut_Speed_as_a_Function_of_Metal_Thickness|Cutting speed]]

Hypertherm:

[[File:PlasmaSpeed.jpg|400px]]

==Oxyfuel (oxyacetylene, oxypropane, etc) cutting torch==

During cutting, an oxyfuel cutting torch is literally burning the steel with a blast of oxygen; most of the heat comes from oxidizing the iron. However to start a new cut ("piercing") you must preheat the steel, relying on the acetylene or LPG for heat. After the steel is red hot you boost the oxygen flow and make the cut. We will want an oxygen-rated valve controlled by the microprocessor. "Oxygen-rated" mostly means the valve is thoroughly cleaned of all oil or flammable solvents that tend to explode on contact with pure oxygen; good practical reference [http://www.gmcscuba.com/pdf/CONVERTING%20DIVE%20TANKS%20FOR%20OXYGEN%20SERVICE.pdf here]. A solenoid valve like [http://www.lesman.com/acatalog/ASCO_8210_Oxygen-Service_Valves.html this] in combination with an ordinary regulator would give basic on/off control, but see better suggestions below.

Fairly technical application note about how to do good oxyfuel machine cutting from ESAB: [http://www.esabna.com/literature/Gas%20Apparatus/Miscellaneous/Oxy-Fuel_Cutting_Quality_0558006464.pdf]

[http://www.cnczone.com/forums/cnc_plasma_waterjet_machines/98346-cnc_oxy_fuel_discussion-25.html#post778595 This] ''long'' forum thread contains a lot of information about implementing small-shop CNC oxyfuel with programmed preheat, pierce, and cutting gas controls, auto ignition, etc. Based partly on this information, here are some control design suggestions for an Arduino-based CNC like [[CoolRAMPS]] or [[CNC_Torch_Table_Control_Overview#Steppernug_Driver_and_Interface_.28alternative_to_CoolRamps.29|Steppernug/grbl]]:
* use dome loaded regulators (e.g. Victor DL700 [http://www.amazon.com/Victor-0780-1188-DL700-500-Dome-Regulator/dp/B0047684PG] [http://victortechnologies.com/IM_Uploads/doclib_8016_DocLib_2331_56-0679%20%20DL%20700%20External%20Dome-Loaded%20Regulator%20Part%20Bulletin.pdf]) driven by regulated shop air [[File:DL700.png|thumb]] [[File:VTS250.png|thumb]]
** general description of spring- and dome-loaded regulators [http://www.documentation.emersonprocess.com/groups/public/documents/bulletins/debul2008x012.pdf here]
** It appears that almost any standard screw-handle regulator can be converted to "dome loaded" by sealing up the housing cap and replacing the screw/spring with an air pressure fitting. See video below. A classic dual-stage like the [http://victortechnologies.com/IM_Uploads/doclib_8039_DocLib_2310_56-0623%20VTS%20250%20Series%20Regulators.pdf VTS250] should work very nicely for conversion
** As with manual regulators, if oxy- or fuel-tank pressure exceeds inlet rating of dome-loaded regulator, a first-stage tank regulator will be required.
** With the dome-loaded regulators, gas on/off as well as pressure setting can be obtained with low-cost shop air components and small valves (e.g [http://www.ebay.com/itm/4V130C-06-DC24V-Solenoid-Air-Valve-5-port-3-position-/290652595990 4V130C],[http://www.automationdirect.com/adc/Shopping/Catalog/Pneumatic_Components/Pneumatic_Valves_-a-_Accessories/Solenoid_Air_Valves_-a-_Accessories/5-port_(4-way),_3-pos.,_Body_Ported_-z-_Manifold_(AVS-5,AM_Series)/AVS-523C1-24D AVS-523C1])
** Using a [http://www.digikey.com/product-detail/en/MPXHZ6400AC6T1/MPXHZ6400AC6T1CT-ND/2057456 solid-state pressure sensor] for feedback, the Arduino can set the regulated pressures to programmed levels by actuating the pneumatic valves (increase/decrease loading pressure until feedback is correct). See video below and code on [http://github.com/chuck-h/ose-gaspressurecontrol github].
* use an electric igniter ([http://www.rvpartwholesaler.com/servlet/the-31/Dometic-2931132019-Refrigerator-Reignitor/Detail RV fridge igniter], [http://www.amazon.com/GrillPro-20620-Electric-Button-Igniter/dp/B000FJVKNM BBQ igniter], [https://www.sparkfun.com/products/11218 spark coil]).
* follow the sequencing of x,y,z motions, pressure changes, on/off, and ignition described by the folks on the forum thread above.
** Develop a library of pressure/time/positioning parameters for different material thicknesses and tip sizes that can be applied automatically by the G-code programming; this should minimize setup time and tweaking.

<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=H3Z3EHqTn44"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=WcUnHnZJ8xU"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=uwCbohxajOY"}
)
</script>
</html>

Installing a [http://www.clippard.com/part/MNV-1K needle valve] at the solenoid air valve improved control smoothness a bit compared to video above.

[[Image:ClippardNeedle.jpg|300px]]

=== oxygen ===

The cutting oxygen for the torch must be high purity (according to the ESAB note above less than 95% purity simply will not cut steel, and >99.5% is required for best quality). Until recently, this meant cryogenically separated oxygen, depending on a large capital plant, and thus the user must rely on commercially provided tank oxygen. For some 30 years, [http://en.wikipedia.org/wiki/Pressure_swing_adsorption pressure-swing-adsorption (PSA) separators] have been available, but standard designs do not remove argon and therefore result in about 95%-oxygen, 5%-argon output gas. PSA construction is low-tech and works very nicely at small scale, e.g. portable breathing-oxygen units, and would be quite suitable for OSE. 95% purity is probably adequate for the preheat flame (ChuckH conjecture). For higher-purity cutting oxygen, PSA can be extended with additional zeolite materials [http://www.ou.edu/class/che-design/a-design/projects-2007/Oxygen%20Generator-Presentation.pdf] or activated carbon [http://www.airsepcpd.com/airsepcpd/pdfs/12779.pdf]; despite [http://cr4.globalspec.com/blogentry/20384/To-Build-an-Oxygen-Concentrator-or-Not this discussion] there is no clear record of small-scale DIY implementation of 99% oxygen PSA.

=== oxyacetylene ===

Recommendations from Victor:

[[File:Victor_Oxy_Acetylene.jpg]]

Commercial oxy-fuel machine cutting heads
* [http://www.pierce.cz/production/components-for-building-and-retrofiting-cutting-machines/autogenni-motorizovana-rezaci-hlava.htm?lang=en Czech] one with capacitive height sensor feature

Components offered by JB: [[CNC_Torch_Table_Log#Oct._21.2C_2012]]

== Oxy-propane, -natural gas, etc ==
[http://www.cousesteel.com/AndysPlace/PropaneAcetylene.html Propane] instead of acetylene. Note the large preheat oxygen flow (not in a consistent stoichiometric ratio to fuel) in this chart. Odd.

[[File:VictorLPGcutting.png]]

Would [[Gasifier|gasifier-gas]] or [[biogas]] & oxygen work? Probably, as natural gas is primarily methane and is a commercially successful cutting-torch fuel.

=See Also=
[[Distributed_CNC_Motion_Control]]

[[Category:CNC Torch Table Prototype II]]
[[Category:Vann]]

CNC Torch Table 2/Research Development

2013-10-31T17:42:17Z

Daniel Benamy: /* Next Steps */

CNC Torch Table 2/Research Development

2013-10-31T17:37:45Z

Daniel Benamy: /* Next Steps */

Ironworker 3/Bill of Materials

2013-10-31T15:01:59Z

Daniel Benamy:

{{GVCS Header}}

Dan started developing a [https://github.com/OSE/documentation/blob/master/bom_generator.py program] which generates the BOM based on the dozuki assembly guides. The program is still rough and the guides need some more work but here's what the output looks like so far:


<pre>
This BOM was generated from the dozuki guides on 2013-10-28 03:28:48.874711

WARNING: If you hand-edit this list, your changes will be lost when the BOM is regenerated. If anything is wrong, you should update the parts entries in dozuki, fix bom_generator.py, or make a note in a section other than the generated list.

Count: 2, Part: 1" x 2" bolts
Used by: How to assemble all the pieces of the Ironworker (in progress), step 14
Count: 2, Part: 1" x 6" bolts
Used by: How to assemble the shear table of the Ironworker (in progress), step 6
Count: 6, Part: 1" x 7" bolts
Used by: How to assemble the top frame of the Ironworker (in progress), step 7
Count: 14, Part: 1" x 8" bolts
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 7
Used by: How to assemble the top frame of the Ironworker (in progress), step 2
Used by: How to assemble the top frame of the Ironworker (in progress), step 8
Count: 2, Part: 10" x 1" hardened bolts
Used by: How to assemble all the pieces of the Ironworker (in progress), step 5
Used by: How to assemble all the pieces of the Ironworker (in progress), step 4
Count: 24, Part: 7" x 1" bolts
Used by: How to assemble all the pieces of the Ironworker (in progress), step 20
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 5
Used by: How to assemble all the pieces of the Ironworker (in progress), step 17
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 2
Count: 6, Part: 8" x 1" bolts
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 3
Count: 4, Part: pivot plates without bushings
Used by: How to assemble the top frame of the Ironworker (in progress), step 6
Count: 4.5, Part: ounces of greases
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 12
Used by: How to assemble the top frame of the Ironworker (in progress), step 4
Used by: How to assemble all the pieces of the Ironworker (in progress), step 25
Count: 1, Part: oz greases
Used by: How to assemble all the pieces of the Ironworker (in progress), step 9
Count: 107, Part: 1" nuts
Used by: How to assemble the shear table of the Ironworker (in progress), step 1
Used by: How to assemble the shear table of the Ironworker (in progress), step 3
Used by: How to assemble the shear table of the Ironworker (in progress), step 2
Used by: How to assemble the shear table of the Ironworker (in progress), step 4
Used by: How to assemble the shear table of the Ironworker (in progress), step 6
Used by: How to assemble the top frame of the Ironworker (in progress), step 8
Used by: How to assemble the top frame of the Ironworker (in progress), step 6
Used by: How to assemble the top frame of the Ironworker (in progress), step 7
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 10
Used by: How to assemble the top frame of the Ironworker (in progress), step 2
Used by: How to assemble all the pieces of the Ironworker (in progress), step 8
Used by: How to assemble all the pieces of the Ironworker (in progress), step 3
Used by: How to assemble all the pieces of the Ironworker (in progress), step 5
Used by: How to assemble all the pieces of the Ironworker (in progress), step 4
Used by: How to assemble all the pieces of the Ironworker (in progress), step 19
Used by: How to assemble all the pieces of the Ironworker (in progress), step 18
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 9
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 7
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 5
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 3
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 2
Used by: How to assemble all the pieces of the Ironworker (in progress), step 28
Used by: How to assemble all the pieces of the Ironworker (in progress), step 22
Used by: How to assemble all the pieces of the Ironworker (in progress), step 24
Used by: How to assemble all the pieces of the Ironworker (in progress), step 26
Used by: How to assemble the top frame of the Ironworker (in progress), step 10
Count: 4, Part: 1 hole x 5 hole plates
Used by: How to assemble all the pieces of the Ironworker (in progress), step 16
Count: 1, Part: 1" x 8" x 16" plates
Used by: How to assemble all the pieces of the Ironworker (in progress), step 12
Count: 4, Part: 2 hole x 2 hole plates
Used by: How to assemble the top frame of the Ironworker (in progress), step 5
Count: 6, Part: 2 hole x 3 hole plates
Used by: How to assemble the top frame of the Ironworker (in progress), step 7
Used by: How to assemble the top frame of the Ironworker (in progress), step 8
Count: 16, Part: 2 hole x 4 hole plates
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 6
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 5
Used by: How to assemble the top frame of the Ironworker (in progress), step 2
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 3
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 2
Count: 8, Part: pivot plates
Used by: How to assemble the top frame of the Ironworker (in progress), step 4
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 10
Count: 2, Part: 1" x TODO" threaded robs
Used by: How to assemble the shear table of the Ironworker (in progress), step 1
Count: 2, Part: 1" x 15" threaded rods
Used by: How to assemble the top frame of the Ironworker (in progress), step 10
Count: 5, Part: 1" x 16" threaded rods
Used by: How to assemble all the pieces of the Ironworker (in progress), step 28
Used by: How to assemble the shear table of the Ironworker (in progress), step 4
Count: 2, Part: 11"x1" threaded rods
Used by: How to assemble all the pieces of the Ironworker (in progress), step 29
Count: 4, Part: 13" x 1" threaded rods
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 6
Count: 4, Part: 14" x 1" threaded rods
Used by: How to assemble the top frame of the Ironworker (in progress), step 3
Count: 3, Part: 15" x 1" threaded rods
Used by: How to assemble all the pieces of the Ironworker (in progress), step 26
Count: 1, Part: 16.5" x 1" threaded rods
Used by: How to assemble all the pieces of the Ironworker (in progress), step 19
Count: 2, Part: 26" x 1" threaded rods
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 8
Count: 1, Part: 3" x 8" solid shafts
Used by: How to assemble all the pieces of the Ironworker (in progress), step 8
Count: 2, Part: 1" springs
Used by: How to assemble the shear table of the Ironworker (in progress), step 2
Count: 2, Part: 1 hole 0.5" tubes
Used by: How to assemble the shear table of the Ironworker (in progress), step 1
Count: 2, Part: 1 hole 1/2" tubes
Used by: How to assemble all the pieces of the Ironworker (in progress), step 10
Count: 1, Part: 1/2" 12 hole tubes
Used by: How to assemble all the pieces of the Ironworker (in progress), step 27
Count: 2, Part: 12 hole 1/2" tubes
Used by: How to assemble all the pieces of the Ironworker (in progress), step 28
Count: 1, Part: 14 hole 1/2" tubes
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 1
Count: 1, Part: 17 hole 1/2" tubes
Used by: How to assemble the top frame of the Ironworker (in progress), step 1
Count: 5, Part: 19 hole 1/2" tubes
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 1
Used by: How to assemble the top frame of the Ironworker (in progress), step 1
Count: 4, Part: 2 hole long 1/4" tubes
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 9
Count: 1, Part: 4 hole, 0.25" tubes
Used by: How to assemble the shear table of the Ironworker (in progress), step 6
Count: 2, Part: 6 hole, 0.25" tubes
Used by: How to assemble the shear table of the Ironworker (in progress), step 3
Used by: How to assemble the shear table of the Ironworker (in progress), step 5
Count: 59, Part: 1" washers
Used by: How to assemble the shear table of the Ironworker (in progress), step 3
Used by: How to assemble the shear table of the Ironworker (in progress), step 2
Used by: How to assemble the shear table of the Ironworker (in progress), step 5
Used by: How to assemble the shear table of the Ironworker (in progress), step 4
Used by: How to assemble the shear table of the Ironworker (in progress), step 6
Used by: How to assemble all the pieces of the Ironworker (in progress), step 24
Used by: How to assemble all the pieces of the Ironworker (in progress), step 5
Used by: How to assemble all the pieces of the Ironworker (in progress), step 4
Used by: How to assemble all the pieces of the Ironworker (in progress), step 20
Used by: How to assemble all the pieces of the Ironworker (in progress), step 28
Used by: How to assemble all the pieces of the Ironworker (in progress), step 22
Used by: How to assemble all the pieces of the Ironworker (in progress), step 19
Used by: How to assemble all the pieces of the Ironworker (in progress), step 18
Used by: How to assemble the bottom frame of the Ironworker (in progress), step 9
Used by: How to assemble the top frame of the Ironworker (in progress), step 10
Used by: How to assemble all the pieces of the Ironworker (in progress), step 14
Used by: How to assemble all the pieces of the Ironworker (in progress), step 17
Used by: How to assemble all the pieces of the Ironworker (in progress), step 26
</pre>

CNC Torch Table 2/Research Development

2013-10-31T05:18:44Z

Daniel Benamy: /* Next Steps */

{{GVCS Header}}

=Status=

This is Dan Benamy's understanding as of Oct 2013:

There have been various ambitious projects over the past few years to do amazing things with the torch table. Unfortunately none of them seem to have reached the finish line (including integration with all the other work).

For the short term Dan plans to get the version 2 table up and running ASAP with the [[RAMPS]] system so we can get something working and build momentum. Then we can quickly iterate to incorporate better modules such as the [[Steppernug]], [[CoolDRV]], or [[CoolRAMPS]] which will allow us to cut faster, sensors for more reliable operation, fuel control for more efficient fuel usage, etc.

Generally, Dan's strategy is to '''make lots of quick iterations with self-contained improvements''' so we almost always have a working table and project handoff is simpler. I'm also focusing on '''getting something working''' at FeF that we can use to cut parts we need for other machines, '''rather than something that's easily reproducible or perfectly documented'''. I'm trading off reproducibility and user friendly docs for getting it working for two reasons: 1- being able to cut [[Warehouse]] parts will save lots of time and money on all other development. 2- it will also be a waste of effort to carefully document stuff that turns out not to work well. Once we get to the point where we can cut useful stuff, I (or you!) will need to make any changes needed for ease of reproduction, and create awesome manufacturing guides so others can copy it.

Lots of info on the control systems at [[CNC Torch Table 2/Control Overview]].

=Next Steps=

* Run a simple test gcode program- https://github.com/grbl/grbl/wiki/G-Code-Examples.
* Draw a rectangle in librecad, run it through [[DXF to G-code Conversion Tutorial | dxf2gcode]] and use [http://reprap.org/wiki/Pronterface Printrun] to stream it to the arduino. Get the table to draw the rectangle.

Then I'd do incremental improvements, keeping the table working after each step so if I had to leave or something didn't work, it'd be easy to revert to the most recent working stuff.

Tasks in github (link below). Sort by milestone.

=Developement Board=
<html><iframe width=80% height='400' frameborder='0' src='https://docs.google.com/spreadsheet/pub?key=0Av4ZjQn4DHJHdDBNVmlFTmZ5S3YxckY3ZkxZc01ISHc&output=html&widget=true'></iframe></html>

[https://docs.google.com/spreadsheet/ccc?key=0Av4ZjQn4DHJHdDBNVmlFTmZ5S3YxckY3ZkxZc01ISHc#gid=2 edit]

=Resources=
* Issue Tracker- https://github.com/OSE/CNC-Torch-Table-OSE/issues
* 3d models
** Github (solidworks 3d models and issues) - https://github.com/OSE/CNC-Torch-Table-OSE. '''Use this for new development'''
** This was originally developed at an [https://github.com/Fractal618/CNC-Torch-Table-OSE old repo] and we forked it into the OSE org. '''Do not use the old repo.'''
** [http://opensourceecology.org/w/images/7/79/CNC_Torch_Table_-_Sketchup_Model.zip] - Sketchup files - I don't know if there are conversions of the solidworks files in github or something else.
* 2d drawings- [http://opensourceecology.org/w/images/d/d1/Creation_Flame_CNC_Torch_Table_Drawings.zip] - DXFs of motor mounts

=Design=
[[Image:Table_Frame.JPG|none|360px|Torch Table Prototype II Design.]]

Lots of information about the control system in [[CNC Torch Table 2/Control Overview]].

Additional discussion at [[TorchTableModularTooling]]

=Additional Notes=
*As a large x-y-z coordinate table, the Torch Table has potential applications with other tooling besides a cutting torch. One limitation is that the drive system is not powerful enough or stiff enough to support heavy cutting-tool forces.

CNC Torch Table 2/Control Overview

2013-10-31T04:24:38Z

Daniel Benamy: /* Marlin */

{{Template:Category=Torch Table}}

=Overview=
<html><img src="https://docs.google.com/drawings/pub?id=1SKGaBa6N21DPzXm9ILuqwPubc6nnRSBAARbkKaEU9hw&w=480&h=360"></html>

=Motor controller and drivers=

==RAMPS==
Dan's using [[RAMPS]] in Oct 2013 to get the table up and running ASAP. The plan is then to replace it with something beefier so we can go faster.

==Alternatives==
See [[Stepper Motor Controller]] and [[Stepper Motor Driver]].

=Software=

==G-code Prep==
[[File:Toolchain.svg|thumb|toolchain pathways]]
[[ImplicitCAD]] (see also [[Parametric_Design_Pilot_Project]])

[[Gcodetools]]

[[DXF_to_G-code_Conversion_Tutorial]]

[[Computer_to_Microcontroller]]

Nesting software would be useful. Example commercial product [http://www.mynesting.com/ here]. Anything open source?

[[DXF_to_G-code_Conversion_Tutorial#Piercing|Gcode preheat]]

Correction for torch cut kerf width ("cutter compensation" in CNC lingo) needed. G40/G41 but grbl does not interpret these.

==G Code Runner==
aka firmware aka motor controller (distinct from motor driver)

This is the firmware running on Arduino which converts a series of G-code commands to step/direction pulses for the drivers.

===Marlin===
When Dan Benamy was getting things going again in Oct 2013, he was using Marlin because grbl doesn't work with RAMPS out of the box.

Marlin will need some modifications if we want our 2 long axis motors to be on separate drivers rather than in parallel on one driver. See http://shapeoko.com/forum/viewtopic.php?f=4&t=1095 for someone doing this.

* I cloned marlin from github and checked out the Marlin_v1 tag.
* Edited Configuration.h
** #define MOTHERBOARD 35 - not sure if this is what we want
** #define DISABLE_E true // For all extruders
** #define TEMP_SENSOR_0 0 // Since we don't have temp sensors
** #define TEMP_SENSOR_1 0 // Since we don't have temp sensors
** #define DEFAULT_AXIS_STEPS_PER_UNIT {128.0537,144.2128,200.0*8/3,760*1.1} // x and y are the right ballpark for the ose torch table at fef, see https://github.com/OSE/CNC-Torch-Table-OSE/issues/4#issuecomment-27460371 for where these numbers came from
* Edited Configuration_adv.h
** Uncommented "#define Y_DUAL_STEPPER_DRIVERS". I used Y because Marlin doesn't support dual drivers on X. We'll use Y as the long axis, X as the short axis, and Z as height. The 2nd Y will be output on the 2nd extruder port (E1, http://reprap.org/wiki/RAMPS_1.4#Wiring)
* Edited pins.h
** In the section for motherboards 33, 34 35, added "#define Y2_STEP_PIN 36", "#define Y2_DIR_PIN 34", and "#define Y2_ENABLE_PIN 30". This is a Marlin bug and I've submitted a fix upstream- https://github.com/ErikZalm/Marlin/pull/635
* Opened Marlin/Marlin/Marlin.pde in the arduino ide and clicked to compile and load it to the arduino.

=== grbl ===
When someone (Chuck?) was working on using the steppernug, they were running a modified grbl fork https://github.com/chuck-h/grbl/tree/edge. Changes from standard grbl [https://github.com/grbl/grbl]:
* Hardware I/O reassignment for steppernug interface
** different pin assignments on Arduino
** I2C extender
* substantially revised [[CNC_Torch_Table_Control_Overview#Limits_and_Homing|homing code]]
** dual X axis
** deep changes to stepper drive algorithm (implementing independent-axis trapezoidal move control during homing, as opposed to standard coordinated-axis move control for cutting) which should improve performance on long, limited-aceleration axes like torch table X and Y.

==Sending G Code to Firmware==

===Printrun===
This is what Dan's using in Oct 2013.

There's good installation instructions at https://github.com/kliment/Printrun. He wanted to do a source install but gave up when it wasn't easy with pip because it needs to use system wide python for access to the display.

* Change baud rate to 250000.
* Click connect.

===Other Software===
[[GcodeCommunications]]: other programs to send the g-code file from a host computer to a controller.

===Hardware===
Talk to Arduino with USB, or for longer distance RS422 e.g. [http://www.mouser.com/ProductDetail/Maxim-Integrated-Products/MAX3488ECSA+/?qs=sGAEpiMZZMvbyeSUH4qH%2fEqdkzg%252bEBoj MAX3488E]

== Testing ==
[[Stepper_Testing|Testing]]

=Limits and Homing=

==Dual-motor homing==
The x axis (long axis) has 2 stepper motors. In the steppernug system, these have separate driver modules which receive identical step, direction, and enable signals.

For zeroing, the x axis needs to decouple - so if we get the x axis out of parallel, we can jog the x axes back into parallel by hitting their home switches independently. Steppernug supports this by allowing the Arduino to control a gate which blocks step pulses to the second driver module; in this condition the second motor will freeze and only the first motor will move. There is no provision for moving the second motor without moving the first, but that function is not required for the homing algorithm.

==Axis sequence==
# We will home the Z axis to its upper position first, just in case there are obstructions to clear during the X and Y axis homing.
# X and Y axes will do their initial fast moves to find home simultaneously (overlapped homing) to save time.
# The Y precision home movement will be performed.
# The dual-X-axis precision home maneuver will be performed.

==Limit and home switch configuration==

[[File:HomeLimit.PNG]]

''(TODO: add illustration showing distance coded reference mark options)''

''(Unconfirmed proposal at this time)'' [[User:ChuckH|ChuckH]] 23:42, 20 October 2012 (CEST)

Each axis has two switches: a '''limit switch''' and a '''home switch'''.
* The '''limit switch''' is activated at *either* end of travel. Its function is to protect against machine damage.
** Attempting to move further into the limit when the limit switch is active will cause all axis movement to stop, the torch to be shut off, and any other "safe shutdown" operation to be performed.
** The limit switch could be hit if the program erroneously commands the tool to move beyond the edge of the table
** The limit switch could also be hit if the torch table loses step (e.g. by hitting an obstruction) and subsequently performs a movement which takes it to the edge of the table
** The limit switch ''may'' be implemented as two physical switches wired in parallel, or the machine construction may permit a single switch to be used.
** Repeatable precision of actuation point is not very critical.
** This function is especially important if the table is expected to do automated cutting without constant human supervision.
* The '''home switch''' transitions between inactive and active at a point partway through the legal travel of the machine.
** For example, it might be active at the negative end of travel, and go inactive after 6 inches of movement.
** The home switch is used only for locating a repeatable zero position when the machine is powered on (or when recovering from lost steps)
*** Note that the logical "machine zero" coordinate may be placed at any programmed position relative to the physical home switch.
** Repeatable precision may be important
*** For the dual-motor axis, to establish accurate squareness
*** For all axes, to pick up in the middle of an interrupted job
*** If fixturing is used for repeat "production style" operations
** (''update, 14-July-2103:'') Instead of responding to a single flag location, the home switch could be actuated many times by multiple flags along the travel, with carefully designed nonuniform spacing between flags
*** This implements "distance coded reference marks" (DCRM), e.g. [[http://www.rls.si/en/dcrm-distance-coded-reference-mark-system--15934]], [[http://www.heidenhain.de/presentation/posa/en/index/N10584/N108A7/N10926.html]], [[http://www.newall.com/upload/content/file/SHG-TC%20-%20Distance-Coded%20Protocol%20-%20USA%20Ver%2004-07-05.pdf]]
*** DCRM is often applied to incremental linear encoder systems; the same principle is effective here using motor step count as the "incremental scale".
*** Using DCRM, the axis only needs to traverse two flag transitions after startup in order to unambiguously determine absolute position.
** By construction, the home switch is active at one end of travel and inactive at the other
*** This allows the machine to know which end of travel it is at in the event the limit switch is activated
*** This, in turn, allows the machine to permit recovery movement from the limit condition back into legal travel, while ignoring a command to go further into the limit zone.

There is an alternative switch configuration which places individual limit switches at the positive and negative limits of legal travel. However the configuration above is preferred because it supports faster homing and simpler control logic. Specifically:
# The substantial distance between the end of travel and the home switch location gives the machine overtravel room to do a controlled stop from high speed: maximum slewing speed can be used during initial homing without risk of slamming into the physical end-of-travel.
# Home switch placement can minimize the typical startup time.
#* If an axis is usually parked near one end of travel, the home switch can be placed there
#* If the axis position on startup is random, placing the home switch in the center of travel will minimize the average seek time.
#* DCRM can be implemented to obtain short startup/home times no matter what the starting position.
# The "safety shutdown" limit-switch function can be always active, and is independent of homing
#* The alternative approach requires logically repurposing a limit switch as home switch during home operations

==Switch Types==

The steppernug interface provides 5V power to sensor switches so either electronic or mechanical switches are easily accommodated.
* Mechanical microswitches are simple and effective.
* A Hall switch (e.g. [[Hall_Effect_Sensor_Module|this]]) is rugged but its position precision is probably only suitable for limits, not home switches.
* An optical interrupter (e.g. [http://www.mouser.com/ProductDetail/Sharp-Microelectronics/GP1A75EJ000F/?qs=%2fha2pyFaduhmXejJv184BikaBEqZykWweNnmsglkeuWVbMieAKIiNg%3d%3d Sharp GP1A75EJ000F]) can give precisely repeatable homing.

== Switch response time ==

The home switch should respond within one motor step time at the "creep speed" used for final approach. This speed might be ~100 steps/sec which gives us ~10ms.

The limit switch should respond quickly enough so that an emergency stop initiated by the switch will stop the machine motion before it hits a mechanical stop. This time is dependent on a lot of different design parameters, but is probably at least 10ms.

The limited response speed required allows us some latitude for noise suppression.

Since all switch signals pass through the I2C expander for I/O, there is about 150 usec (0.15ms) added, see [[Stepper_Testing#timing|here]].

=Torch control=

Software can use an M code to start the cut (e.g. open cutting-oxygen valve, strike plasma arc).

A second M code could shut down the entire torch (e.g. at the end of an unsupervised cutting session).

See also [[CNC_Torch_Table/Research_Development#Cutting_Torch]]

==Plasma Torch==

[[Plasma_Cutter_Design#Plasma_Cutter_PC_Interface]]

[http://www.metalwebnews.com/howto/plasma/presentation.pdf This presentation] on plasma-cutting accurate holes also suggests that ramping down plasma current while torch is still moving is good practice. (It makes the electrodes last longer.)

[[Sensing_Distance_from_Work_Piece|Z-axis arc voltage height control]]. Needs design work.

[[Plasma_Cutter_Cut_Speed_as_a_Function_of_Metal_Thickness|Cutting speed]]

Hypertherm:

[[File:PlasmaSpeed.jpg|400px]]

==Oxyfuel (oxyacetylene, oxypropane, etc) cutting torch==

During cutting, an oxyfuel cutting torch is literally burning the steel with a blast of oxygen; most of the heat comes from oxidizing the iron. However to start a new cut ("piercing") you must preheat the steel, relying on the acetylene or LPG for heat. After the steel is red hot you boost the oxygen flow and make the cut. We will want an oxygen-rated valve controlled by the microprocessor. "Oxygen-rated" mostly means the valve is thoroughly cleaned of all oil or flammable solvents that tend to explode on contact with pure oxygen; good practical reference [http://www.gmcscuba.com/pdf/CONVERTING%20DIVE%20TANKS%20FOR%20OXYGEN%20SERVICE.pdf here]. A solenoid valve like [http://www.lesman.com/acatalog/ASCO_8210_Oxygen-Service_Valves.html this] in combination with an ordinary regulator would give basic on/off control, but see better suggestions below.

Fairly technical application note about how to do good oxyfuel machine cutting from ESAB: [http://www.esabna.com/literature/Gas%20Apparatus/Miscellaneous/Oxy-Fuel_Cutting_Quality_0558006464.pdf]

[http://www.cnczone.com/forums/cnc_plasma_waterjet_machines/98346-cnc_oxy_fuel_discussion-25.html#post778595 This] ''long'' forum thread contains a lot of information about implementing small-shop CNC oxyfuel with programmed preheat, pierce, and cutting gas controls, auto ignition, etc. Based partly on this information, here are some control design suggestions for an Arduino-based CNC like [[CoolRAMPS]] or [[CNC_Torch_Table_Control_Overview#Steppernug_Driver_and_Interface_.28alternative_to_CoolRamps.29|Steppernug/grbl]]:
* use dome loaded regulators (e.g. Victor DL700 [http://www.amazon.com/Victor-0780-1188-DL700-500-Dome-Regulator/dp/B0047684PG] [http://victortechnologies.com/IM_Uploads/doclib_8016_DocLib_2331_56-0679%20%20DL%20700%20External%20Dome-Loaded%20Regulator%20Part%20Bulletin.pdf]) driven by regulated shop air [[File:DL700.png|thumb]] [[File:VTS250.png|thumb]]
** general description of spring- and dome-loaded regulators [http://www.documentation.emersonprocess.com/groups/public/documents/bulletins/debul2008x012.pdf here]
** It appears that almost any standard screw-handle regulator can be converted to "dome loaded" by sealing up the housing cap and replacing the screw/spring with an air pressure fitting. See video below. A classic dual-stage like the [http://victortechnologies.com/IM_Uploads/doclib_8039_DocLib_2310_56-0623%20VTS%20250%20Series%20Regulators.pdf VTS250] should work very nicely for conversion
** As with manual regulators, if oxy- or fuel-tank pressure exceeds inlet rating of dome-loaded regulator, a first-stage tank regulator will be required.
** With the dome-loaded regulators, gas on/off as well as pressure setting can be obtained with low-cost shop air components and small valves (e.g [http://www.ebay.com/itm/4V130C-06-DC24V-Solenoid-Air-Valve-5-port-3-position-/290652595990 4V130C],[http://www.automationdirect.com/adc/Shopping/Catalog/Pneumatic_Components/Pneumatic_Valves_-a-_Accessories/Solenoid_Air_Valves_-a-_Accessories/5-port_(4-way),_3-pos.,_Body_Ported_-z-_Manifold_(AVS-5,AM_Series)/AVS-523C1-24D AVS-523C1])
** Using a [http://www.digikey.com/product-detail/en/MPXHZ6400AC6T1/MPXHZ6400AC6T1CT-ND/2057456 solid-state pressure sensor] for feedback, the Arduino can set the regulated pressures to programmed levels by actuating the pneumatic valves (increase/decrease loading pressure until feedback is correct). See video below and code on [http://github.com/chuck-h/ose-gaspressurecontrol github].
* use an electric igniter ([http://www.rvpartwholesaler.com/servlet/the-31/Dometic-2931132019-Refrigerator-Reignitor/Detail RV fridge igniter], [http://www.amazon.com/GrillPro-20620-Electric-Button-Igniter/dp/B000FJVKNM BBQ igniter], [https://www.sparkfun.com/products/11218 spark coil]).
* follow the sequencing of x,y,z motions, pressure changes, on/off, and ignition described by the folks on the forum thread above.
** Develop a library of pressure/time/positioning parameters for different material thicknesses and tip sizes that can be applied automatically by the G-code programming; this should minimize setup time and tweaking.

<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=H3Z3EHqTn44"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=WcUnHnZJ8xU"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=uwCbohxajOY"}
)
</script>
</html>

Installing a [http://www.clippard.com/part/MNV-1K needle valve] at the solenoid air valve improved control smoothness a bit compared to video above.

[[Image:ClippardNeedle.jpg|300px]]

=== oxygen ===

The cutting oxygen for the torch must be high purity (according to the ESAB note above less than 95% purity simply will not cut steel, and >99.5% is required for best quality). Until recently, this meant cryogenically separated oxygen, depending on a large capital plant, and thus the user must rely on commercially provided tank oxygen. For some 30 years, [http://en.wikipedia.org/wiki/Pressure_swing_adsorption pressure-swing-adsorption (PSA) separators] have been available, but standard designs do not remove argon and therefore result in about 95%-oxygen, 5%-argon output gas. PSA construction is low-tech and works very nicely at small scale, e.g. portable breathing-oxygen units, and would be quite suitable for OSE. 95% purity is probably adequate for the preheat flame (ChuckH conjecture). For higher-purity cutting oxygen, PSA can be extended with additional zeolite materials [http://www.ou.edu/class/che-design/a-design/projects-2007/Oxygen%20Generator-Presentation.pdf] or activated carbon [http://www.airsepcpd.com/airsepcpd/pdfs/12779.pdf]; despite [http://cr4.globalspec.com/blogentry/20384/To-Build-an-Oxygen-Concentrator-or-Not this discussion] there is no clear record of small-scale DIY implementation of 99% oxygen PSA.

=== oxyacetylene ===

Recommendations from Victor:

[[File:Victor_Oxy_Acetylene.jpg]]

Commercial oxy-fuel machine cutting heads
* [http://www.pierce.cz/production/components-for-building-and-retrofiting-cutting-machines/autogenni-motorizovana-rezaci-hlava.htm?lang=en Czech] one with capacitive height sensor feature

Components offered by JB: [[CNC_Torch_Table_Log#Oct._21.2C_2012]]

== Oxy-propane, -natural gas, etc ==
[http://www.cousesteel.com/AndysPlace/PropaneAcetylene.html Propane] instead of acetylene. Note the large preheat oxygen flow (not in a consistent stoichiometric ratio to fuel) in this chart. Odd.

[[File:VictorLPGcutting.png]]

Would [[Gasifier|gasifier-gas]] or [[biogas]] & oxygen work? Probably, as natural gas is primarily methane and is a commercially successful cutting-torch fuel.

=See Also=
[[Distributed_CNC_Motion_Control]]

[[Category:CNC Torch Table Prototype II]]
[[Category:Vann]]

CNC Torch Table 2/Research Development

2013-10-31T02:47:01Z

Daniel Benamy: /* Next Steps */

{{GVCS Header}}

=Status=

This is Dan Benamy's understanding as of Oct 2013:

There have been various ambitious projects over the past few years to do amazing things with the torch table. Unfortunately none of them seem to have reached the finish line (including integration with all the other work).

For the short term Dan plans to get the version 2 table up and running ASAP with the [[RAMPS]] system so we can get something working and build momentum. Then we can quickly iterate to incorporate better modules such as the [[Steppernug]], [[CoolDRV]], or [[CoolRAMPS]] which will allow us to cut faster, sensors for more reliable operation, fuel control for more efficient fuel usage, etc.

Generally, Dan's strategy is to '''make lots of quick iterations with self-contained improvements''' so we almost always have a working table and project handoff is simpler. I'm also focusing on '''getting something working''' at FeF that we can use to cut parts we need for other machines, '''rather than something that's easily reproducible or perfectly documented'''. I'm trading off reproducibility and user friendly docs for getting it working for two reasons: 1- being able to cut [[Warehouse]] parts will save lots of time and money on all other development. 2- it will also be a waste of effort to carefully document stuff that turns out not to work well. Once we get to the point where we can cut useful stuff, I (or you!) will need to make any changes needed for ease of reproduction, and create awesome manufacturing guides so others can copy it.

Lots of info on the control systems at [[CNC Torch Table 2/Control Overview]].

=Next Steps=

* Run a simple test gcode program- https://github.com/grbl/grbl/wiki/G-Code-Examples.
* Draw a rectangle in librecad, run it through [[DXF to G-code Conversion Tutorial | dxf2gcode]] and use [http://reprap.org/wiki/Pronterface Printrun] to stream it to the arduino. Get the table to draw the rectangle.

Then I'd do incremental improvements, keeping the table working after each step so if I had to leave or something didn't work, it'd be easy to revert to the most recent working stuff. Steps until we could use the table to actually make parts for fabricating other machines:
* Add a circle to the dxf that's not touching the rectangle. Re-run and make sure the head lifts up between the shapes.
* Add [[DXF_to_G-code_Conversion_Tutorial#Piercing | gcode postprocessing]] if still needed for piercing and torch width. The "torch" should move back and forth while making an initial "pierce". For the circle, I think it should make the pieces inside the circle. I'm not sure if it should pierce the rectangle inside or on one edge. We want it to make the pierce in a part of the metal we won't use. I wonder how the piercing code knows what that is... There's a conversation [https://groups.google.com/forum/#!msg/dxf2gcode-dev/6ZnNcX3O5i4/d-3NeBfHpbUJ here] about integrating this functionality into dxf2gcode which would be great for ease of use and gives us a gui where maybe we could click where we want the pierce to be.
* Try it with the real torch!!! For future steps, I'd switch back to the sharpie for testing and only use the torch once things look good.

If we're lucky, this gets us to milestone 1 - can cut useful warehouse plates.

Tasks for milestone 2 and beyond are in github (link below).

=Developement Board=
<html><iframe width=80% height='400' frameborder='0' src='https://docs.google.com/spreadsheet/pub?key=0Av4ZjQn4DHJHdDBNVmlFTmZ5S3YxckY3ZkxZc01ISHc&output=html&widget=true'></iframe></html>

[https://docs.google.com/spreadsheet/ccc?key=0Av4ZjQn4DHJHdDBNVmlFTmZ5S3YxckY3ZkxZc01ISHc#gid=2 edit]

=Resources=
* Issue Tracker- https://github.com/OSE/CNC-Torch-Table-OSE/issues
* 3d models
** Github (solidworks 3d models and issues) - https://github.com/OSE/CNC-Torch-Table-OSE. '''Use this for new development'''
** This was originally developed at an [https://github.com/Fractal618/CNC-Torch-Table-OSE old repo] and we forked it into the OSE org. '''Do not use the old repo.'''
** [http://opensourceecology.org/w/images/7/79/CNC_Torch_Table_-_Sketchup_Model.zip] - Sketchup files - I don't know if there are conversions of the solidworks files in github or something else.
* 2d drawings- [http://opensourceecology.org/w/images/d/d1/Creation_Flame_CNC_Torch_Table_Drawings.zip] - DXFs of motor mounts

=Design=
[[Image:Table_Frame.JPG|none|360px|Torch Table Prototype II Design.]]

Lots of information about the control system in [[CNC Torch Table 2/Control Overview]].

Additional discussion at [[TorchTableModularTooling]]

=Additional Notes=
*As a large x-y-z coordinate table, the Torch Table has potential applications with other tooling besides a cutting torch. One limitation is that the drive system is not powerful enough or stiff enough to support heavy cutting-tool forces.

CNC Torch Table 2/Control Overview

2013-10-31T02:46:49Z

Daniel Benamy: /* Marlin */

{{Template:Category=Torch Table}}

=Overview=
<html><img src="https://docs.google.com/drawings/pub?id=1SKGaBa6N21DPzXm9ILuqwPubc6nnRSBAARbkKaEU9hw&w=480&h=360"></html>

=Motor controller and drivers=

==RAMPS==
Dan's using [[RAMPS]] in Oct 2013 to get the table up and running ASAP. The plan is then to replace it with something beefier so we can go faster.

==Alternatives==
See [[Stepper Motor Controller]] and [[Stepper Motor Driver]].

=Software=

==G-code Prep==
[[File:Toolchain.svg|thumb|toolchain pathways]]
[[ImplicitCAD]] (see also [[Parametric_Design_Pilot_Project]])

[[Gcodetools]]

[[DXF_to_G-code_Conversion_Tutorial]]

[[Computer_to_Microcontroller]]

Nesting software would be useful. Example commercial product [http://www.mynesting.com/ here]. Anything open source?

[[DXF_to_G-code_Conversion_Tutorial#Piercing|Gcode preheat]]

Correction for torch cut kerf width ("cutter compensation" in CNC lingo) needed. G40/G41 but grbl does not interpret these.

==G Code Runner==
aka firmware aka motor controller (distinct from motor driver)

This is the firmware running on Arduino which converts a series of G-code commands to step/direction pulses for the drivers.

===Marlin===
When Dan Benamy was getting things going again in Oct 2013, he was using Marlin because grbl doesn't work with RAMPS out of the box.

Marlin will need some modifications if we want our 2 long axis motors to be on separate drivers rather than in parallel on one driver. See http://shapeoko.com/forum/viewtopic.php?f=4&t=1095 for someone doing this.

* I cloned marlin from github and checked out the Marlin_v1 tag.
* Edited Configuration.h
** #define MOTHERBOARD 35 - not sure if this is what we want
** #define DISABLE_E true // For all extruders
** #define TEMP_SENSOR_0 0 // Since we don't have temp sensors
** #define TEMP_SENSOR_1 0 // Since we don't have temp sensors
* Edited Configuration_adv.h
** Uncommented "#define Y_DUAL_STEPPER_DRIVERS". I used Y because Marlin doesn't support dual drivers on X. We'll use Y as the long axis, X as the short axis, and Z as height. The 2nd Y will be output on the 2nd extruder port (http://reprap.org/wiki/RAMPS_1.4#Wiring)
* Edited pins.h
** In the section for motherboards 33, 34 35, added "#define Y2_STEP_PIN 36", "#define Y2_DIR_PIN 34", and "#define Y2_ENABLE_PIN 30". This is a Marlin bug and I've submitted a fix upstream- https://github.com/ErikZalm/Marlin/pull/635
* Opened Marlin/Marlin/Marlin.pde in the arduino ide and clicked to compile and load it to the arduino.

=== grbl ===
When someone (Chuck?) was working on using the steppernug, they were running a modified grbl fork https://github.com/chuck-h/grbl/tree/edge. Changes from standard grbl [https://github.com/grbl/grbl]:
* Hardware I/O reassignment for steppernug interface
** different pin assignments on Arduino
** I2C extender
* substantially revised [[CNC_Torch_Table_Control_Overview#Limits_and_Homing|homing code]]
** dual X axis
** deep changes to stepper drive algorithm (implementing independent-axis trapezoidal move control during homing, as opposed to standard coordinated-axis move control for cutting) which should improve performance on long, limited-aceleration axes like torch table X and Y.

==Sending G Code to Firmware==

===Printrun===
This is what Dan's using in Oct 2013.

There's good installation instructions at https://github.com/kliment/Printrun. He wanted to do a source install but gave up when it wasn't easy with pip because it needs to use system wide python for access to the display.

* Change baud rate to 250000.
* Click connect.

===Other Software===
[[GcodeCommunications]]: other programs to send the g-code file from a host computer to a controller.

===Hardware===
Talk to Arduino with USB, or for longer distance RS422 e.g. [http://www.mouser.com/ProductDetail/Maxim-Integrated-Products/MAX3488ECSA+/?qs=sGAEpiMZZMvbyeSUH4qH%2fEqdkzg%252bEBoj MAX3488E]

== Testing ==
[[Stepper_Testing|Testing]]

=Limits and Homing=

==Dual-motor homing==
The x axis (long axis) has 2 stepper motors. In the steppernug system, these have separate driver modules which receive identical step, direction, and enable signals.

For zeroing, the x axis needs to decouple - so if we get the x axis out of parallel, we can jog the x axes back into parallel by hitting their home switches independently. Steppernug supports this by allowing the Arduino to control a gate which blocks step pulses to the second driver module; in this condition the second motor will freeze and only the first motor will move. There is no provision for moving the second motor without moving the first, but that function is not required for the homing algorithm.

==Axis sequence==
# We will home the Z axis to its upper position first, just in case there are obstructions to clear during the X and Y axis homing.
# X and Y axes will do their initial fast moves to find home simultaneously (overlapped homing) to save time.
# The Y precision home movement will be performed.
# The dual-X-axis precision home maneuver will be performed.

==Limit and home switch configuration==

[[File:HomeLimit.PNG]]

''(TODO: add illustration showing distance coded reference mark options)''

''(Unconfirmed proposal at this time)'' [[User:ChuckH|ChuckH]] 23:42, 20 October 2012 (CEST)

Each axis has two switches: a '''limit switch''' and a '''home switch'''.
* The '''limit switch''' is activated at *either* end of travel. Its function is to protect against machine damage.
** Attempting to move further into the limit when the limit switch is active will cause all axis movement to stop, the torch to be shut off, and any other "safe shutdown" operation to be performed.
** The limit switch could be hit if the program erroneously commands the tool to move beyond the edge of the table
** The limit switch could also be hit if the torch table loses step (e.g. by hitting an obstruction) and subsequently performs a movement which takes it to the edge of the table
** The limit switch ''may'' be implemented as two physical switches wired in parallel, or the machine construction may permit a single switch to be used.
** Repeatable precision of actuation point is not very critical.
** This function is especially important if the table is expected to do automated cutting without constant human supervision.
* The '''home switch''' transitions between inactive and active at a point partway through the legal travel of the machine.
** For example, it might be active at the negative end of travel, and go inactive after 6 inches of movement.
** The home switch is used only for locating a repeatable zero position when the machine is powered on (or when recovering from lost steps)
*** Note that the logical "machine zero" coordinate may be placed at any programmed position relative to the physical home switch.
** Repeatable precision may be important
*** For the dual-motor axis, to establish accurate squareness
*** For all axes, to pick up in the middle of an interrupted job
*** If fixturing is used for repeat "production style" operations
** (''update, 14-July-2103:'') Instead of responding to a single flag location, the home switch could be actuated many times by multiple flags along the travel, with carefully designed nonuniform spacing between flags
*** This implements "distance coded reference marks" (DCRM), e.g. [[http://www.rls.si/en/dcrm-distance-coded-reference-mark-system--15934]], [[http://www.heidenhain.de/presentation/posa/en/index/N10584/N108A7/N10926.html]], [[http://www.newall.com/upload/content/file/SHG-TC%20-%20Distance-Coded%20Protocol%20-%20USA%20Ver%2004-07-05.pdf]]
*** DCRM is often applied to incremental linear encoder systems; the same principle is effective here using motor step count as the "incremental scale".
*** Using DCRM, the axis only needs to traverse two flag transitions after startup in order to unambiguously determine absolute position.
** By construction, the home switch is active at one end of travel and inactive at the other
*** This allows the machine to know which end of travel it is at in the event the limit switch is activated
*** This, in turn, allows the machine to permit recovery movement from the limit condition back into legal travel, while ignoring a command to go further into the limit zone.

There is an alternative switch configuration which places individual limit switches at the positive and negative limits of legal travel. However the configuration above is preferred because it supports faster homing and simpler control logic. Specifically:
# The substantial distance between the end of travel and the home switch location gives the machine overtravel room to do a controlled stop from high speed: maximum slewing speed can be used during initial homing without risk of slamming into the physical end-of-travel.
# Home switch placement can minimize the typical startup time.
#* If an axis is usually parked near one end of travel, the home switch can be placed there
#* If the axis position on startup is random, placing the home switch in the center of travel will minimize the average seek time.
#* DCRM can be implemented to obtain short startup/home times no matter what the starting position.
# The "safety shutdown" limit-switch function can be always active, and is independent of homing
#* The alternative approach requires logically repurposing a limit switch as home switch during home operations

==Switch Types==

The steppernug interface provides 5V power to sensor switches so either electronic or mechanical switches are easily accommodated.
* Mechanical microswitches are simple and effective.
* A Hall switch (e.g. [[Hall_Effect_Sensor_Module|this]]) is rugged but its position precision is probably only suitable for limits, not home switches.
* An optical interrupter (e.g. [http://www.mouser.com/ProductDetail/Sharp-Microelectronics/GP1A75EJ000F/?qs=%2fha2pyFaduhmXejJv184BikaBEqZykWweNnmsglkeuWVbMieAKIiNg%3d%3d Sharp GP1A75EJ000F]) can give precisely repeatable homing.

== Switch response time ==

The home switch should respond within one motor step time at the "creep speed" used for final approach. This speed might be ~100 steps/sec which gives us ~10ms.

The limit switch should respond quickly enough so that an emergency stop initiated by the switch will stop the machine motion before it hits a mechanical stop. This time is dependent on a lot of different design parameters, but is probably at least 10ms.

The limited response speed required allows us some latitude for noise suppression.

Since all switch signals pass through the I2C expander for I/O, there is about 150 usec (0.15ms) added, see [[Stepper_Testing#timing|here]].

=Torch control=

Software can use an M code to start the cut (e.g. open cutting-oxygen valve, strike plasma arc).

A second M code could shut down the entire torch (e.g. at the end of an unsupervised cutting session).

See also [[CNC_Torch_Table/Research_Development#Cutting_Torch]]

==Plasma Torch==

[[Plasma_Cutter_Design#Plasma_Cutter_PC_Interface]]

[http://www.metalwebnews.com/howto/plasma/presentation.pdf This presentation] on plasma-cutting accurate holes also suggests that ramping down plasma current while torch is still moving is good practice. (It makes the electrodes last longer.)

[[Sensing_Distance_from_Work_Piece|Z-axis arc voltage height control]]. Needs design work.

[[Plasma_Cutter_Cut_Speed_as_a_Function_of_Metal_Thickness|Cutting speed]]

Hypertherm:

[[File:PlasmaSpeed.jpg|400px]]

==Oxyfuel (oxyacetylene, oxypropane, etc) cutting torch==

During cutting, an oxyfuel cutting torch is literally burning the steel with a blast of oxygen; most of the heat comes from oxidizing the iron. However to start a new cut ("piercing") you must preheat the steel, relying on the acetylene or LPG for heat. After the steel is red hot you boost the oxygen flow and make the cut. We will want an oxygen-rated valve controlled by the microprocessor. "Oxygen-rated" mostly means the valve is thoroughly cleaned of all oil or flammable solvents that tend to explode on contact with pure oxygen; good practical reference [http://www.gmcscuba.com/pdf/CONVERTING%20DIVE%20TANKS%20FOR%20OXYGEN%20SERVICE.pdf here]. A solenoid valve like [http://www.lesman.com/acatalog/ASCO_8210_Oxygen-Service_Valves.html this] in combination with an ordinary regulator would give basic on/off control, but see better suggestions below.

Fairly technical application note about how to do good oxyfuel machine cutting from ESAB: [http://www.esabna.com/literature/Gas%20Apparatus/Miscellaneous/Oxy-Fuel_Cutting_Quality_0558006464.pdf]

[http://www.cnczone.com/forums/cnc_plasma_waterjet_machines/98346-cnc_oxy_fuel_discussion-25.html#post778595 This] ''long'' forum thread contains a lot of information about implementing small-shop CNC oxyfuel with programmed preheat, pierce, and cutting gas controls, auto ignition, etc. Based partly on this information, here are some control design suggestions for an Arduino-based CNC like [[CoolRAMPS]] or [[CNC_Torch_Table_Control_Overview#Steppernug_Driver_and_Interface_.28alternative_to_CoolRamps.29|Steppernug/grbl]]:
* use dome loaded regulators (e.g. Victor DL700 [http://www.amazon.com/Victor-0780-1188-DL700-500-Dome-Regulator/dp/B0047684PG] [http://victortechnologies.com/IM_Uploads/doclib_8016_DocLib_2331_56-0679%20%20DL%20700%20External%20Dome-Loaded%20Regulator%20Part%20Bulletin.pdf]) driven by regulated shop air [[File:DL700.png|thumb]] [[File:VTS250.png|thumb]]
** general description of spring- and dome-loaded regulators [http://www.documentation.emersonprocess.com/groups/public/documents/bulletins/debul2008x012.pdf here]
** It appears that almost any standard screw-handle regulator can be converted to "dome loaded" by sealing up the housing cap and replacing the screw/spring with an air pressure fitting. See video below. A classic dual-stage like the [http://victortechnologies.com/IM_Uploads/doclib_8039_DocLib_2310_56-0623%20VTS%20250%20Series%20Regulators.pdf VTS250] should work very nicely for conversion
** As with manual regulators, if oxy- or fuel-tank pressure exceeds inlet rating of dome-loaded regulator, a first-stage tank regulator will be required.
** With the dome-loaded regulators, gas on/off as well as pressure setting can be obtained with low-cost shop air components and small valves (e.g [http://www.ebay.com/itm/4V130C-06-DC24V-Solenoid-Air-Valve-5-port-3-position-/290652595990 4V130C],[http://www.automationdirect.com/adc/Shopping/Catalog/Pneumatic_Components/Pneumatic_Valves_-a-_Accessories/Solenoid_Air_Valves_-a-_Accessories/5-port_(4-way),_3-pos.,_Body_Ported_-z-_Manifold_(AVS-5,AM_Series)/AVS-523C1-24D AVS-523C1])
** Using a [http://www.digikey.com/product-detail/en/MPXHZ6400AC6T1/MPXHZ6400AC6T1CT-ND/2057456 solid-state pressure sensor] for feedback, the Arduino can set the regulated pressures to programmed levels by actuating the pneumatic valves (increase/decrease loading pressure until feedback is correct). See video below and code on [http://github.com/chuck-h/ose-gaspressurecontrol github].
* use an electric igniter ([http://www.rvpartwholesaler.com/servlet/the-31/Dometic-2931132019-Refrigerator-Reignitor/Detail RV fridge igniter], [http://www.amazon.com/GrillPro-20620-Electric-Button-Igniter/dp/B000FJVKNM BBQ igniter], [https://www.sparkfun.com/products/11218 spark coil]).
* follow the sequencing of x,y,z motions, pressure changes, on/off, and ignition described by the folks on the forum thread above.
** Develop a library of pressure/time/positioning parameters for different material thicknesses and tip sizes that can be applied automatically by the G-code programming; this should minimize setup time and tweaking.

<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=H3Z3EHqTn44"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=WcUnHnZJ8xU"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=uwCbohxajOY"}
)
</script>
</html>

Installing a [http://www.clippard.com/part/MNV-1K needle valve] at the solenoid air valve improved control smoothness a bit compared to video above.

[[Image:ClippardNeedle.jpg|300px]]

=== oxygen ===

The cutting oxygen for the torch must be high purity (according to the ESAB note above less than 95% purity simply will not cut steel, and >99.5% is required for best quality). Until recently, this meant cryogenically separated oxygen, depending on a large capital plant, and thus the user must rely on commercially provided tank oxygen. For some 30 years, [http://en.wikipedia.org/wiki/Pressure_swing_adsorption pressure-swing-adsorption (PSA) separators] have been available, but standard designs do not remove argon and therefore result in about 95%-oxygen, 5%-argon output gas. PSA construction is low-tech and works very nicely at small scale, e.g. portable breathing-oxygen units, and would be quite suitable for OSE. 95% purity is probably adequate for the preheat flame (ChuckH conjecture). For higher-purity cutting oxygen, PSA can be extended with additional zeolite materials [http://www.ou.edu/class/che-design/a-design/projects-2007/Oxygen%20Generator-Presentation.pdf] or activated carbon [http://www.airsepcpd.com/airsepcpd/pdfs/12779.pdf]; despite [http://cr4.globalspec.com/blogentry/20384/To-Build-an-Oxygen-Concentrator-or-Not this discussion] there is no clear record of small-scale DIY implementation of 99% oxygen PSA.

=== oxyacetylene ===

Recommendations from Victor:

[[File:Victor_Oxy_Acetylene.jpg]]

Commercial oxy-fuel machine cutting heads
* [http://www.pierce.cz/production/components-for-building-and-retrofiting-cutting-machines/autogenni-motorizovana-rezaci-hlava.htm?lang=en Czech] one with capacitive height sensor feature

Components offered by JB: [[CNC_Torch_Table_Log#Oct._21.2C_2012]]

== Oxy-propane, -natural gas, etc ==
[http://www.cousesteel.com/AndysPlace/PropaneAcetylene.html Propane] instead of acetylene. Note the large preheat oxygen flow (not in a consistent stoichiometric ratio to fuel) in this chart. Odd.

[[File:VictorLPGcutting.png]]

Would [[Gasifier|gasifier-gas]] or [[biogas]] & oxygen work? Probably, as natural gas is primarily methane and is a commercially successful cutting-torch fuel.

=See Also=
[[Distributed_CNC_Motion_Control]]

[[Category:CNC Torch Table Prototype II]]
[[Category:Vann]]

CNC Torch Table 2/Control Overview

2013-10-31T02:39:57Z

Daniel Benamy: /* Marlin */

{{Template:Category=Torch Table}}

=Overview=
<html><img src="https://docs.google.com/drawings/pub?id=1SKGaBa6N21DPzXm9ILuqwPubc6nnRSBAARbkKaEU9hw&w=480&h=360"></html>

=Motor controller and drivers=

==RAMPS==
Dan's using [[RAMPS]] in Oct 2013 to get the table up and running ASAP. The plan is then to replace it with something beefier so we can go faster.

==Alternatives==
See [[Stepper Motor Controller]] and [[Stepper Motor Driver]].

=Software=

==G-code Prep==
[[File:Toolchain.svg|thumb|toolchain pathways]]
[[ImplicitCAD]] (see also [[Parametric_Design_Pilot_Project]])

[[Gcodetools]]

[[DXF_to_G-code_Conversion_Tutorial]]

[[Computer_to_Microcontroller]]

Nesting software would be useful. Example commercial product [http://www.mynesting.com/ here]. Anything open source?

[[DXF_to_G-code_Conversion_Tutorial#Piercing|Gcode preheat]]

Correction for torch cut kerf width ("cutter compensation" in CNC lingo) needed. G40/G41 but grbl does not interpret these.

==G Code Runner==
aka firmware aka motor controller (distinct from motor driver)

This is the firmware running on Arduino which converts a series of G-code commands to step/direction pulses for the drivers.

===Marlin===
When Dan Benamy was getting things going again in Oct 2013, he was using Marlin because grbl doesn't work with RAMPS out of the box.

Marlin will need some modifications if we want our 2 long axis motors to be on separate drivers rather than in parallel on one driver. See http://shapeoko.com/forum/viewtopic.php?f=4&t=1095 for someone doing this.

* I cloned marlin from github and checked out the Marlin_v1 tag.
* Edited Configuration.h
** #define MOTHERBOARD 35 - not sure if this is what we want
** #define DISABLE_E true // For all extruders
** #define TEMP_SENSOR_0 0 // Since we don't have temp sensors
** #define TEMP_SENSOR_1 0 // Since we don't have temp sensors
* Edited Configuration_adv.h
** Uncommented "#define Y_DUAL_STEPPER_DRIVERS". I used Y because Marlin doesn't support dual drivers on X. We'll use Y as the long axis, X as the short axis, and Z as height. The 2nd Y will be output on the 2nd extruder port (http://reprap.org/wiki/RAMPS_1.4#Wiring)
* Edited pins.h
** In the section for motherboards 33, 34 35, added "#define Y2_STEP_PIN 36", "#define Y2_DIR_PIN 34", and "#define Y2_ENABLE_PIN 30". This is a Marlin bug and I've submitted a fix upstream- https://github.com/ErikZalm/Marlin/pull/634
* Opened Marlin/Marlin/Marlin.pde in the arduino ide and clicked to compile and load it to the arduino.

=== grbl ===
When someone (Chuck?) was working on using the steppernug, they were running a modified grbl fork https://github.com/chuck-h/grbl/tree/edge. Changes from standard grbl [https://github.com/grbl/grbl]:
* Hardware I/O reassignment for steppernug interface
** different pin assignments on Arduino
** I2C extender
* substantially revised [[CNC_Torch_Table_Control_Overview#Limits_and_Homing|homing code]]
** dual X axis
** deep changes to stepper drive algorithm (implementing independent-axis trapezoidal move control during homing, as opposed to standard coordinated-axis move control for cutting) which should improve performance on long, limited-aceleration axes like torch table X and Y.

==Sending G Code to Firmware==

===Printrun===
This is what Dan's using in Oct 2013.

There's good installation instructions at https://github.com/kliment/Printrun. He wanted to do a source install but gave up when it wasn't easy with pip because it needs to use system wide python for access to the display.

* Change baud rate to 250000.
* Click connect.

===Other Software===
[[GcodeCommunications]]: other programs to send the g-code file from a host computer to a controller.

===Hardware===
Talk to Arduino with USB, or for longer distance RS422 e.g. [http://www.mouser.com/ProductDetail/Maxim-Integrated-Products/MAX3488ECSA+/?qs=sGAEpiMZZMvbyeSUH4qH%2fEqdkzg%252bEBoj MAX3488E]

== Testing ==
[[Stepper_Testing|Testing]]

=Limits and Homing=

==Dual-motor homing==
The x axis (long axis) has 2 stepper motors. In the steppernug system, these have separate driver modules which receive identical step, direction, and enable signals.

For zeroing, the x axis needs to decouple - so if we get the x axis out of parallel, we can jog the x axes back into parallel by hitting their home switches independently. Steppernug supports this by allowing the Arduino to control a gate which blocks step pulses to the second driver module; in this condition the second motor will freeze and only the first motor will move. There is no provision for moving the second motor without moving the first, but that function is not required for the homing algorithm.

==Axis sequence==
# We will home the Z axis to its upper position first, just in case there are obstructions to clear during the X and Y axis homing.
# X and Y axes will do their initial fast moves to find home simultaneously (overlapped homing) to save time.
# The Y precision home movement will be performed.
# The dual-X-axis precision home maneuver will be performed.

==Limit and home switch configuration==

[[File:HomeLimit.PNG]]

''(TODO: add illustration showing distance coded reference mark options)''

''(Unconfirmed proposal at this time)'' [[User:ChuckH|ChuckH]] 23:42, 20 October 2012 (CEST)

Each axis has two switches: a '''limit switch''' and a '''home switch'''.
* The '''limit switch''' is activated at *either* end of travel. Its function is to protect against machine damage.
** Attempting to move further into the limit when the limit switch is active will cause all axis movement to stop, the torch to be shut off, and any other "safe shutdown" operation to be performed.
** The limit switch could be hit if the program erroneously commands the tool to move beyond the edge of the table
** The limit switch could also be hit if the torch table loses step (e.g. by hitting an obstruction) and subsequently performs a movement which takes it to the edge of the table
** The limit switch ''may'' be implemented as two physical switches wired in parallel, or the machine construction may permit a single switch to be used.
** Repeatable precision of actuation point is not very critical.
** This function is especially important if the table is expected to do automated cutting without constant human supervision.
* The '''home switch''' transitions between inactive and active at a point partway through the legal travel of the machine.
** For example, it might be active at the negative end of travel, and go inactive after 6 inches of movement.
** The home switch is used only for locating a repeatable zero position when the machine is powered on (or when recovering from lost steps)
*** Note that the logical "machine zero" coordinate may be placed at any programmed position relative to the physical home switch.
** Repeatable precision may be important
*** For the dual-motor axis, to establish accurate squareness
*** For all axes, to pick up in the middle of an interrupted job
*** If fixturing is used for repeat "production style" operations
** (''update, 14-July-2103:'') Instead of responding to a single flag location, the home switch could be actuated many times by multiple flags along the travel, with carefully designed nonuniform spacing between flags
*** This implements "distance coded reference marks" (DCRM), e.g. [[http://www.rls.si/en/dcrm-distance-coded-reference-mark-system--15934]], [[http://www.heidenhain.de/presentation/posa/en/index/N10584/N108A7/N10926.html]], [[http://www.newall.com/upload/content/file/SHG-TC%20-%20Distance-Coded%20Protocol%20-%20USA%20Ver%2004-07-05.pdf]]
*** DCRM is often applied to incremental linear encoder systems; the same principle is effective here using motor step count as the "incremental scale".
*** Using DCRM, the axis only needs to traverse two flag transitions after startup in order to unambiguously determine absolute position.
** By construction, the home switch is active at one end of travel and inactive at the other
*** This allows the machine to know which end of travel it is at in the event the limit switch is activated
*** This, in turn, allows the machine to permit recovery movement from the limit condition back into legal travel, while ignoring a command to go further into the limit zone.

There is an alternative switch configuration which places individual limit switches at the positive and negative limits of legal travel. However the configuration above is preferred because it supports faster homing and simpler control logic. Specifically:
# The substantial distance between the end of travel and the home switch location gives the machine overtravel room to do a controlled stop from high speed: maximum slewing speed can be used during initial homing without risk of slamming into the physical end-of-travel.
# Home switch placement can minimize the typical startup time.
#* If an axis is usually parked near one end of travel, the home switch can be placed there
#* If the axis position on startup is random, placing the home switch in the center of travel will minimize the average seek time.
#* DCRM can be implemented to obtain short startup/home times no matter what the starting position.
# The "safety shutdown" limit-switch function can be always active, and is independent of homing
#* The alternative approach requires logically repurposing a limit switch as home switch during home operations

==Switch Types==

The steppernug interface provides 5V power to sensor switches so either electronic or mechanical switches are easily accommodated.
* Mechanical microswitches are simple and effective.
* A Hall switch (e.g. [[Hall_Effect_Sensor_Module|this]]) is rugged but its position precision is probably only suitable for limits, not home switches.
* An optical interrupter (e.g. [http://www.mouser.com/ProductDetail/Sharp-Microelectronics/GP1A75EJ000F/?qs=%2fha2pyFaduhmXejJv184BikaBEqZykWweNnmsglkeuWVbMieAKIiNg%3d%3d Sharp GP1A75EJ000F]) can give precisely repeatable homing.

== Switch response time ==

The home switch should respond within one motor step time at the "creep speed" used for final approach. This speed might be ~100 steps/sec which gives us ~10ms.

The limit switch should respond quickly enough so that an emergency stop initiated by the switch will stop the machine motion before it hits a mechanical stop. This time is dependent on a lot of different design parameters, but is probably at least 10ms.

The limited response speed required allows us some latitude for noise suppression.

Since all switch signals pass through the I2C expander for I/O, there is about 150 usec (0.15ms) added, see [[Stepper_Testing#timing|here]].

=Torch control=

Software can use an M code to start the cut (e.g. open cutting-oxygen valve, strike plasma arc).

A second M code could shut down the entire torch (e.g. at the end of an unsupervised cutting session).

See also [[CNC_Torch_Table/Research_Development#Cutting_Torch]]

==Plasma Torch==

[[Plasma_Cutter_Design#Plasma_Cutter_PC_Interface]]

[http://www.metalwebnews.com/howto/plasma/presentation.pdf This presentation] on plasma-cutting accurate holes also suggests that ramping down plasma current while torch is still moving is good practice. (It makes the electrodes last longer.)

[[Sensing_Distance_from_Work_Piece|Z-axis arc voltage height control]]. Needs design work.

[[Plasma_Cutter_Cut_Speed_as_a_Function_of_Metal_Thickness|Cutting speed]]

Hypertherm:

[[File:PlasmaSpeed.jpg|400px]]

==Oxyfuel (oxyacetylene, oxypropane, etc) cutting torch==

During cutting, an oxyfuel cutting torch is literally burning the steel with a blast of oxygen; most of the heat comes from oxidizing the iron. However to start a new cut ("piercing") you must preheat the steel, relying on the acetylene or LPG for heat. After the steel is red hot you boost the oxygen flow and make the cut. We will want an oxygen-rated valve controlled by the microprocessor. "Oxygen-rated" mostly means the valve is thoroughly cleaned of all oil or flammable solvents that tend to explode on contact with pure oxygen; good practical reference [http://www.gmcscuba.com/pdf/CONVERTING%20DIVE%20TANKS%20FOR%20OXYGEN%20SERVICE.pdf here]. A solenoid valve like [http://www.lesman.com/acatalog/ASCO_8210_Oxygen-Service_Valves.html this] in combination with an ordinary regulator would give basic on/off control, but see better suggestions below.

Fairly technical application note about how to do good oxyfuel machine cutting from ESAB: [http://www.esabna.com/literature/Gas%20Apparatus/Miscellaneous/Oxy-Fuel_Cutting_Quality_0558006464.pdf]

[http://www.cnczone.com/forums/cnc_plasma_waterjet_machines/98346-cnc_oxy_fuel_discussion-25.html#post778595 This] ''long'' forum thread contains a lot of information about implementing small-shop CNC oxyfuel with programmed preheat, pierce, and cutting gas controls, auto ignition, etc. Based partly on this information, here are some control design suggestions for an Arduino-based CNC like [[CoolRAMPS]] or [[CNC_Torch_Table_Control_Overview#Steppernug_Driver_and_Interface_.28alternative_to_CoolRamps.29|Steppernug/grbl]]:
* use dome loaded regulators (e.g. Victor DL700 [http://www.amazon.com/Victor-0780-1188-DL700-500-Dome-Regulator/dp/B0047684PG] [http://victortechnologies.com/IM_Uploads/doclib_8016_DocLib_2331_56-0679%20%20DL%20700%20External%20Dome-Loaded%20Regulator%20Part%20Bulletin.pdf]) driven by regulated shop air [[File:DL700.png|thumb]] [[File:VTS250.png|thumb]]
** general description of spring- and dome-loaded regulators [http://www.documentation.emersonprocess.com/groups/public/documents/bulletins/debul2008x012.pdf here]
** It appears that almost any standard screw-handle regulator can be converted to "dome loaded" by sealing up the housing cap and replacing the screw/spring with an air pressure fitting. See video below. A classic dual-stage like the [http://victortechnologies.com/IM_Uploads/doclib_8039_DocLib_2310_56-0623%20VTS%20250%20Series%20Regulators.pdf VTS250] should work very nicely for conversion
** As with manual regulators, if oxy- or fuel-tank pressure exceeds inlet rating of dome-loaded regulator, a first-stage tank regulator will be required.
** With the dome-loaded regulators, gas on/off as well as pressure setting can be obtained with low-cost shop air components and small valves (e.g [http://www.ebay.com/itm/4V130C-06-DC24V-Solenoid-Air-Valve-5-port-3-position-/290652595990 4V130C],[http://www.automationdirect.com/adc/Shopping/Catalog/Pneumatic_Components/Pneumatic_Valves_-a-_Accessories/Solenoid_Air_Valves_-a-_Accessories/5-port_(4-way),_3-pos.,_Body_Ported_-z-_Manifold_(AVS-5,AM_Series)/AVS-523C1-24D AVS-523C1])
** Using a [http://www.digikey.com/product-detail/en/MPXHZ6400AC6T1/MPXHZ6400AC6T1CT-ND/2057456 solid-state pressure sensor] for feedback, the Arduino can set the regulated pressures to programmed levels by actuating the pneumatic valves (increase/decrease loading pressure until feedback is correct). See video below and code on [http://github.com/chuck-h/ose-gaspressurecontrol github].
* use an electric igniter ([http://www.rvpartwholesaler.com/servlet/the-31/Dometic-2931132019-Refrigerator-Reignitor/Detail RV fridge igniter], [http://www.amazon.com/GrillPro-20620-Electric-Button-Igniter/dp/B000FJVKNM BBQ igniter], [https://www.sparkfun.com/products/11218 spark coil]).
* follow the sequencing of x,y,z motions, pressure changes, on/off, and ignition described by the folks on the forum thread above.
** Develop a library of pressure/time/positioning parameters for different material thicknesses and tip sizes that can be applied automatically by the G-code programming; this should minimize setup time and tweaking.

<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=H3Z3EHqTn44"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=WcUnHnZJ8xU"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=uwCbohxajOY"}
)
</script>
</html>

Installing a [http://www.clippard.com/part/MNV-1K needle valve] at the solenoid air valve improved control smoothness a bit compared to video above.

[[Image:ClippardNeedle.jpg|300px]]

=== oxygen ===

The cutting oxygen for the torch must be high purity (according to the ESAB note above less than 95% purity simply will not cut steel, and >99.5% is required for best quality). Until recently, this meant cryogenically separated oxygen, depending on a large capital plant, and thus the user must rely on commercially provided tank oxygen. For some 30 years, [http://en.wikipedia.org/wiki/Pressure_swing_adsorption pressure-swing-adsorption (PSA) separators] have been available, but standard designs do not remove argon and therefore result in about 95%-oxygen, 5%-argon output gas. PSA construction is low-tech and works very nicely at small scale, e.g. portable breathing-oxygen units, and would be quite suitable for OSE. 95% purity is probably adequate for the preheat flame (ChuckH conjecture). For higher-purity cutting oxygen, PSA can be extended with additional zeolite materials [http://www.ou.edu/class/che-design/a-design/projects-2007/Oxygen%20Generator-Presentation.pdf] or activated carbon [http://www.airsepcpd.com/airsepcpd/pdfs/12779.pdf]; despite [http://cr4.globalspec.com/blogentry/20384/To-Build-an-Oxygen-Concentrator-or-Not this discussion] there is no clear record of small-scale DIY implementation of 99% oxygen PSA.

=== oxyacetylene ===

Recommendations from Victor:

[[File:Victor_Oxy_Acetylene.jpg]]

Commercial oxy-fuel machine cutting heads
* [http://www.pierce.cz/production/components-for-building-and-retrofiting-cutting-machines/autogenni-motorizovana-rezaci-hlava.htm?lang=en Czech] one with capacitive height sensor feature

Components offered by JB: [[CNC_Torch_Table_Log#Oct._21.2C_2012]]

== Oxy-propane, -natural gas, etc ==
[http://www.cousesteel.com/AndysPlace/PropaneAcetylene.html Propane] instead of acetylene. Note the large preheat oxygen flow (not in a consistent stoichiometric ratio to fuel) in this chart. Odd.

[[File:VictorLPGcutting.png]]

Would [[Gasifier|gasifier-gas]] or [[biogas]] & oxygen work? Probably, as natural gas is primarily methane and is a commercially successful cutting-torch fuel.

=See Also=
[[Distributed_CNC_Motion_Control]]

[[Category:CNC Torch Table Prototype II]]
[[Category:Vann]]

CNC Torch Table 2/Control Overview

2013-10-31T01:10:13Z

Daniel Benamy: /* Marlin */

{{Template:Category=Torch Table}}

=Overview=
<html><img src="https://docs.google.com/drawings/pub?id=1SKGaBa6N21DPzXm9ILuqwPubc6nnRSBAARbkKaEU9hw&w=480&h=360"></html>

=Motor controller and drivers=

==RAMPS==
Dan's using [[RAMPS]] in Oct 2013 to get the table up and running ASAP. The plan is then to replace it with something beefier so we can go faster.

==Alternatives==
See [[Stepper Motor Controller]] and [[Stepper Motor Driver]].

=Software=

==G-code Prep==
[[File:Toolchain.svg|thumb|toolchain pathways]]
[[ImplicitCAD]] (see also [[Parametric_Design_Pilot_Project]])

[[Gcodetools]]

[[DXF_to_G-code_Conversion_Tutorial]]

[[Computer_to_Microcontroller]]

Nesting software would be useful. Example commercial product [http://www.mynesting.com/ here]. Anything open source?

[[DXF_to_G-code_Conversion_Tutorial#Piercing|Gcode preheat]]

Correction for torch cut kerf width ("cutter compensation" in CNC lingo) needed. G40/G41 but grbl does not interpret these.

==G Code Runner==
aka firmware aka motor controller (distinct from motor driver)

This is the firmware running on Arduino which converts a series of G-code commands to step/direction pulses for the drivers.

===Marlin===
When Dan Benamy was getting things going again in Oct 2013, he was using Marlin because grbl doesn't work with RAMPS out of the box.

Marlin will need some modifications if we want our 2 long axis motors to be on separate drivers rather than in parallel on one driver. See http://shapeoko.com/forum/viewtopic.php?f=4&t=1095 for someone doing this.

* I cloned marlin from github and checked out the Marlin_v1 tag.
* Edited Configuration.h
** #define MOTHERBOARD 35 - not sure if this is what we want
** #define DISABLE_E true // For all extruders
** #define TEMP_SENSOR_0 0 // Since we don't have temp sensors
** #define TEMP_SENSOR_1 0 // Since we don't have temp sensors
* Edited Configuration_adv.h
** Uncommented "#define Y_DUAL_STEPPER_DRIVERS". I used Y because Marlin doesn't support dual drivers on X. We'll use Y as the long axis, X as the short axis, and Z as height. The 2nd Y will be output on the 2nd extruder port (http://reprap.org/wiki/RAMPS_1.4#Wiring)
* Edited pins.h
** In the section for motherboards 33, 34 35, added "#define Y2_STEP_PIN 26", "#define Y2_DIR_PIN 28", and "#define Y2_ENABLE_PIN 24". This is a Marlin bug and I've submitted a fix upstream- https://github.com/ErikZalm/Marlin/pull/634
* Opened Marlin/Marlin/Marlin.pde in the arduino ide and clicked to compile and load it to the arduino.

=== grbl ===
When someone (Chuck?) was working on using the steppernug, they were running a modified grbl fork https://github.com/chuck-h/grbl/tree/edge. Changes from standard grbl [https://github.com/grbl/grbl]:
* Hardware I/O reassignment for steppernug interface
** different pin assignments on Arduino
** I2C extender
* substantially revised [[CNC_Torch_Table_Control_Overview#Limits_and_Homing|homing code]]
** dual X axis
** deep changes to stepper drive algorithm (implementing independent-axis trapezoidal move control during homing, as opposed to standard coordinated-axis move control for cutting) which should improve performance on long, limited-aceleration axes like torch table X and Y.

==Sending G Code to Firmware==

===Printrun===
This is what Dan's using in Oct 2013.

There's good installation instructions at https://github.com/kliment/Printrun. He wanted to do a source install but gave up when it wasn't easy with pip because it needs to use system wide python for access to the display.

* Change baud rate to 250000.
* Click connect.

===Other Software===
[[GcodeCommunications]]: other programs to send the g-code file from a host computer to a controller.

===Hardware===
Talk to Arduino with USB, or for longer distance RS422 e.g. [http://www.mouser.com/ProductDetail/Maxim-Integrated-Products/MAX3488ECSA+/?qs=sGAEpiMZZMvbyeSUH4qH%2fEqdkzg%252bEBoj MAX3488E]

== Testing ==
[[Stepper_Testing|Testing]]

=Limits and Homing=

==Dual-motor homing==
The x axis (long axis) has 2 stepper motors. In the steppernug system, these have separate driver modules which receive identical step, direction, and enable signals.

For zeroing, the x axis needs to decouple - so if we get the x axis out of parallel, we can jog the x axes back into parallel by hitting their home switches independently. Steppernug supports this by allowing the Arduino to control a gate which blocks step pulses to the second driver module; in this condition the second motor will freeze and only the first motor will move. There is no provision for moving the second motor without moving the first, but that function is not required for the homing algorithm.

==Axis sequence==
# We will home the Z axis to its upper position first, just in case there are obstructions to clear during the X and Y axis homing.
# X and Y axes will do their initial fast moves to find home simultaneously (overlapped homing) to save time.
# The Y precision home movement will be performed.
# The dual-X-axis precision home maneuver will be performed.

==Limit and home switch configuration==

[[File:HomeLimit.PNG]]

''(TODO: add illustration showing distance coded reference mark options)''

''(Unconfirmed proposal at this time)'' [[User:ChuckH|ChuckH]] 23:42, 20 October 2012 (CEST)

Each axis has two switches: a '''limit switch''' and a '''home switch'''.
* The '''limit switch''' is activated at *either* end of travel. Its function is to protect against machine damage.
** Attempting to move further into the limit when the limit switch is active will cause all axis movement to stop, the torch to be shut off, and any other "safe shutdown" operation to be performed.
** The limit switch could be hit if the program erroneously commands the tool to move beyond the edge of the table
** The limit switch could also be hit if the torch table loses step (e.g. by hitting an obstruction) and subsequently performs a movement which takes it to the edge of the table
** The limit switch ''may'' be implemented as two physical switches wired in parallel, or the machine construction may permit a single switch to be used.
** Repeatable precision of actuation point is not very critical.
** This function is especially important if the table is expected to do automated cutting without constant human supervision.
* The '''home switch''' transitions between inactive and active at a point partway through the legal travel of the machine.
** For example, it might be active at the negative end of travel, and go inactive after 6 inches of movement.
** The home switch is used only for locating a repeatable zero position when the machine is powered on (or when recovering from lost steps)
*** Note that the logical "machine zero" coordinate may be placed at any programmed position relative to the physical home switch.
** Repeatable precision may be important
*** For the dual-motor axis, to establish accurate squareness
*** For all axes, to pick up in the middle of an interrupted job
*** If fixturing is used for repeat "production style" operations
** (''update, 14-July-2103:'') Instead of responding to a single flag location, the home switch could be actuated many times by multiple flags along the travel, with carefully designed nonuniform spacing between flags
*** This implements "distance coded reference marks" (DCRM), e.g. [[http://www.rls.si/en/dcrm-distance-coded-reference-mark-system--15934]], [[http://www.heidenhain.de/presentation/posa/en/index/N10584/N108A7/N10926.html]], [[http://www.newall.com/upload/content/file/SHG-TC%20-%20Distance-Coded%20Protocol%20-%20USA%20Ver%2004-07-05.pdf]]
*** DCRM is often applied to incremental linear encoder systems; the same principle is effective here using motor step count as the "incremental scale".
*** Using DCRM, the axis only needs to traverse two flag transitions after startup in order to unambiguously determine absolute position.
** By construction, the home switch is active at one end of travel and inactive at the other
*** This allows the machine to know which end of travel it is at in the event the limit switch is activated
*** This, in turn, allows the machine to permit recovery movement from the limit condition back into legal travel, while ignoring a command to go further into the limit zone.

There is an alternative switch configuration which places individual limit switches at the positive and negative limits of legal travel. However the configuration above is preferred because it supports faster homing and simpler control logic. Specifically:
# The substantial distance between the end of travel and the home switch location gives the machine overtravel room to do a controlled stop from high speed: maximum slewing speed can be used during initial homing without risk of slamming into the physical end-of-travel.
# Home switch placement can minimize the typical startup time.
#* If an axis is usually parked near one end of travel, the home switch can be placed there
#* If the axis position on startup is random, placing the home switch in the center of travel will minimize the average seek time.
#* DCRM can be implemented to obtain short startup/home times no matter what the starting position.
# The "safety shutdown" limit-switch function can be always active, and is independent of homing
#* The alternative approach requires logically repurposing a limit switch as home switch during home operations

==Switch Types==

The steppernug interface provides 5V power to sensor switches so either electronic or mechanical switches are easily accommodated.
* Mechanical microswitches are simple and effective.
* A Hall switch (e.g. [[Hall_Effect_Sensor_Module|this]]) is rugged but its position precision is probably only suitable for limits, not home switches.
* An optical interrupter (e.g. [http://www.mouser.com/ProductDetail/Sharp-Microelectronics/GP1A75EJ000F/?qs=%2fha2pyFaduhmXejJv184BikaBEqZykWweNnmsglkeuWVbMieAKIiNg%3d%3d Sharp GP1A75EJ000F]) can give precisely repeatable homing.

== Switch response time ==

The home switch should respond within one motor step time at the "creep speed" used for final approach. This speed might be ~100 steps/sec which gives us ~10ms.

The limit switch should respond quickly enough so that an emergency stop initiated by the switch will stop the machine motion before it hits a mechanical stop. This time is dependent on a lot of different design parameters, but is probably at least 10ms.

The limited response speed required allows us some latitude for noise suppression.

Since all switch signals pass through the I2C expander for I/O, there is about 150 usec (0.15ms) added, see [[Stepper_Testing#timing|here]].

=Torch control=

Software can use an M code to start the cut (e.g. open cutting-oxygen valve, strike plasma arc).

A second M code could shut down the entire torch (e.g. at the end of an unsupervised cutting session).

See also [[CNC_Torch_Table/Research_Development#Cutting_Torch]]

==Plasma Torch==

[[Plasma_Cutter_Design#Plasma_Cutter_PC_Interface]]

[http://www.metalwebnews.com/howto/plasma/presentation.pdf This presentation] on plasma-cutting accurate holes also suggests that ramping down plasma current while torch is still moving is good practice. (It makes the electrodes last longer.)

[[Sensing_Distance_from_Work_Piece|Z-axis arc voltage height control]]. Needs design work.

[[Plasma_Cutter_Cut_Speed_as_a_Function_of_Metal_Thickness|Cutting speed]]

Hypertherm:

[[File:PlasmaSpeed.jpg|400px]]

==Oxyfuel (oxyacetylene, oxypropane, etc) cutting torch==

During cutting, an oxyfuel cutting torch is literally burning the steel with a blast of oxygen; most of the heat comes from oxidizing the iron. However to start a new cut ("piercing") you must preheat the steel, relying on the acetylene or LPG for heat. After the steel is red hot you boost the oxygen flow and make the cut. We will want an oxygen-rated valve controlled by the microprocessor. "Oxygen-rated" mostly means the valve is thoroughly cleaned of all oil or flammable solvents that tend to explode on contact with pure oxygen; good practical reference [http://www.gmcscuba.com/pdf/CONVERTING%20DIVE%20TANKS%20FOR%20OXYGEN%20SERVICE.pdf here]. A solenoid valve like [http://www.lesman.com/acatalog/ASCO_8210_Oxygen-Service_Valves.html this] in combination with an ordinary regulator would give basic on/off control, but see better suggestions below.

Fairly technical application note about how to do good oxyfuel machine cutting from ESAB: [http://www.esabna.com/literature/Gas%20Apparatus/Miscellaneous/Oxy-Fuel_Cutting_Quality_0558006464.pdf]

[http://www.cnczone.com/forums/cnc_plasma_waterjet_machines/98346-cnc_oxy_fuel_discussion-25.html#post778595 This] ''long'' forum thread contains a lot of information about implementing small-shop CNC oxyfuel with programmed preheat, pierce, and cutting gas controls, auto ignition, etc. Based partly on this information, here are some control design suggestions for an Arduino-based CNC like [[CoolRAMPS]] or [[CNC_Torch_Table_Control_Overview#Steppernug_Driver_and_Interface_.28alternative_to_CoolRamps.29|Steppernug/grbl]]:
* use dome loaded regulators (e.g. Victor DL700 [http://www.amazon.com/Victor-0780-1188-DL700-500-Dome-Regulator/dp/B0047684PG] [http://victortechnologies.com/IM_Uploads/doclib_8016_DocLib_2331_56-0679%20%20DL%20700%20External%20Dome-Loaded%20Regulator%20Part%20Bulletin.pdf]) driven by regulated shop air [[File:DL700.png|thumb]] [[File:VTS250.png|thumb]]
** general description of spring- and dome-loaded regulators [http://www.documentation.emersonprocess.com/groups/public/documents/bulletins/debul2008x012.pdf here]
** It appears that almost any standard screw-handle regulator can be converted to "dome loaded" by sealing up the housing cap and replacing the screw/spring with an air pressure fitting. See video below. A classic dual-stage like the [http://victortechnologies.com/IM_Uploads/doclib_8039_DocLib_2310_56-0623%20VTS%20250%20Series%20Regulators.pdf VTS250] should work very nicely for conversion
** As with manual regulators, if oxy- or fuel-tank pressure exceeds inlet rating of dome-loaded regulator, a first-stage tank regulator will be required.
** With the dome-loaded regulators, gas on/off as well as pressure setting can be obtained with low-cost shop air components and small valves (e.g [http://www.ebay.com/itm/4V130C-06-DC24V-Solenoid-Air-Valve-5-port-3-position-/290652595990 4V130C],[http://www.automationdirect.com/adc/Shopping/Catalog/Pneumatic_Components/Pneumatic_Valves_-a-_Accessories/Solenoid_Air_Valves_-a-_Accessories/5-port_(4-way),_3-pos.,_Body_Ported_-z-_Manifold_(AVS-5,AM_Series)/AVS-523C1-24D AVS-523C1])
** Using a [http://www.digikey.com/product-detail/en/MPXHZ6400AC6T1/MPXHZ6400AC6T1CT-ND/2057456 solid-state pressure sensor] for feedback, the Arduino can set the regulated pressures to programmed levels by actuating the pneumatic valves (increase/decrease loading pressure until feedback is correct). See video below and code on [http://github.com/chuck-h/ose-gaspressurecontrol github].
* use an electric igniter ([http://www.rvpartwholesaler.com/servlet/the-31/Dometic-2931132019-Refrigerator-Reignitor/Detail RV fridge igniter], [http://www.amazon.com/GrillPro-20620-Electric-Button-Igniter/dp/B000FJVKNM BBQ igniter], [https://www.sparkfun.com/products/11218 spark coil]).
* follow the sequencing of x,y,z motions, pressure changes, on/off, and ignition described by the folks on the forum thread above.
** Develop a library of pressure/time/positioning parameters for different material thicknesses and tip sizes that can be applied automatically by the G-code programming; this should minimize setup time and tweaking.

<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=H3Z3EHqTn44"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=WcUnHnZJ8xU"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=uwCbohxajOY"}
)
</script>
</html>

Installing a [http://www.clippard.com/part/MNV-1K needle valve] at the solenoid air valve improved control smoothness a bit compared to video above.

[[Image:ClippardNeedle.jpg|300px]]

=== oxygen ===

The cutting oxygen for the torch must be high purity (according to the ESAB note above less than 95% purity simply will not cut steel, and >99.5% is required for best quality). Until recently, this meant cryogenically separated oxygen, depending on a large capital plant, and thus the user must rely on commercially provided tank oxygen. For some 30 years, [http://en.wikipedia.org/wiki/Pressure_swing_adsorption pressure-swing-adsorption (PSA) separators] have been available, but standard designs do not remove argon and therefore result in about 95%-oxygen, 5%-argon output gas. PSA construction is low-tech and works very nicely at small scale, e.g. portable breathing-oxygen units, and would be quite suitable for OSE. 95% purity is probably adequate for the preheat flame (ChuckH conjecture). For higher-purity cutting oxygen, PSA can be extended with additional zeolite materials [http://www.ou.edu/class/che-design/a-design/projects-2007/Oxygen%20Generator-Presentation.pdf] or activated carbon [http://www.airsepcpd.com/airsepcpd/pdfs/12779.pdf]; despite [http://cr4.globalspec.com/blogentry/20384/To-Build-an-Oxygen-Concentrator-or-Not this discussion] there is no clear record of small-scale DIY implementation of 99% oxygen PSA.

=== oxyacetylene ===

Recommendations from Victor:

[[File:Victor_Oxy_Acetylene.jpg]]

Commercial oxy-fuel machine cutting heads
* [http://www.pierce.cz/production/components-for-building-and-retrofiting-cutting-machines/autogenni-motorizovana-rezaci-hlava.htm?lang=en Czech] one with capacitive height sensor feature

Components offered by JB: [[CNC_Torch_Table_Log#Oct._21.2C_2012]]

== Oxy-propane, -natural gas, etc ==
[http://www.cousesteel.com/AndysPlace/PropaneAcetylene.html Propane] instead of acetylene. Note the large preheat oxygen flow (not in a consistent stoichiometric ratio to fuel) in this chart. Odd.

[[File:VictorLPGcutting.png]]

Would [[Gasifier|gasifier-gas]] or [[biogas]] & oxygen work? Probably, as natural gas is primarily methane and is a commercially successful cutting-torch fuel.

=See Also=
[[Distributed_CNC_Motion_Control]]

[[Category:CNC Torch Table Prototype II]]
[[Category:Vann]]

CNC Torch Table 2/Control Overview

2013-10-31T00:48:58Z

Daniel Benamy: /* Marlin */

{{Template:Category=Torch Table}}

=Overview=
<html><img src="https://docs.google.com/drawings/pub?id=1SKGaBa6N21DPzXm9ILuqwPubc6nnRSBAARbkKaEU9hw&w=480&h=360"></html>

=Motor controller and drivers=

==RAMPS==
Dan's using [[RAMPS]] in Oct 2013 to get the table up and running ASAP. The plan is then to replace it with something beefier so we can go faster.

==Alternatives==
See [[Stepper Motor Controller]] and [[Stepper Motor Driver]].

=Software=

==G-code Prep==
[[File:Toolchain.svg|thumb|toolchain pathways]]
[[ImplicitCAD]] (see also [[Parametric_Design_Pilot_Project]])

[[Gcodetools]]

[[DXF_to_G-code_Conversion_Tutorial]]

[[Computer_to_Microcontroller]]

Nesting software would be useful. Example commercial product [http://www.mynesting.com/ here]. Anything open source?

[[DXF_to_G-code_Conversion_Tutorial#Piercing|Gcode preheat]]

Correction for torch cut kerf width ("cutter compensation" in CNC lingo) needed. G40/G41 but grbl does not interpret these.

==G Code Runner==
aka firmware aka motor controller (distinct from motor driver)

This is the firmware running on Arduino which converts a series of G-code commands to step/direction pulses for the drivers.

===Marlin===
When Dan Benamy was getting things going again in Oct 2013, he was using Marlin because grbl doesn't work with RAMPS out of the box.

Marlin will need some modifications if we want our 2 long axis motors to be on separate drivers rather than in parallel on one driver. See http://shapeoko.com/forum/viewtopic.php?f=4&t=1095 for someone doing this.

* I cloned marlin from github and checked out the Marlin_v1 tag.
* Edited Configuration.h
** #define MOTHERBOARD 35 - not sure if this is what we want
** #define DISABLE_E true // For all extruders
** #define TEMP_SENSOR_0 0 // Since we don't have temp sensors
** #define TEMP_SENSOR_1 0 // Since we don't have temp sensors
* Edited Configuration_adv.h
** Uncommented "#define Y_DUAL_STEPPER_DRIVERS". I used Y because Marlin doesn't support dual drivers on X. We'll use Y as the long axis, X as the short axis, and Z as height. The 2nd Y will be output on the 2nd extruder port (http://reprap.org/wiki/RAMPS_1.4#Wiring)
* Opened Marlin/Marlin/Marlin.pde in the arduino ide and clicked to compile and load it to the arduio.

=== grbl ===
When someone (Chuck?) was working on using the steppernug, they were running a modified grbl fork https://github.com/chuck-h/grbl/tree/edge. Changes from standard grbl [https://github.com/grbl/grbl]:
* Hardware I/O reassignment for steppernug interface
** different pin assignments on Arduino
** I2C extender
* substantially revised [[CNC_Torch_Table_Control_Overview#Limits_and_Homing|homing code]]
** dual X axis
** deep changes to stepper drive algorithm (implementing independent-axis trapezoidal move control during homing, as opposed to standard coordinated-axis move control for cutting) which should improve performance on long, limited-aceleration axes like torch table X and Y.

==Sending G Code to Firmware==

===Printrun===
This is what Dan's using in Oct 2013.

There's good installation instructions at https://github.com/kliment/Printrun. He wanted to do a source install but gave up when it wasn't easy with pip because it needs to use system wide python for access to the display.

* Change baud rate to 250000.
* Click connect.

===Other Software===
[[GcodeCommunications]]: other programs to send the g-code file from a host computer to a controller.

===Hardware===
Talk to Arduino with USB, or for longer distance RS422 e.g. [http://www.mouser.com/ProductDetail/Maxim-Integrated-Products/MAX3488ECSA+/?qs=sGAEpiMZZMvbyeSUH4qH%2fEqdkzg%252bEBoj MAX3488E]

== Testing ==
[[Stepper_Testing|Testing]]

=Limits and Homing=

==Dual-motor homing==
The x axis (long axis) has 2 stepper motors. In the steppernug system, these have separate driver modules which receive identical step, direction, and enable signals.

For zeroing, the x axis needs to decouple - so if we get the x axis out of parallel, we can jog the x axes back into parallel by hitting their home switches independently. Steppernug supports this by allowing the Arduino to control a gate which blocks step pulses to the second driver module; in this condition the second motor will freeze and only the first motor will move. There is no provision for moving the second motor without moving the first, but that function is not required for the homing algorithm.

==Axis sequence==
# We will home the Z axis to its upper position first, just in case there are obstructions to clear during the X and Y axis homing.
# X and Y axes will do their initial fast moves to find home simultaneously (overlapped homing) to save time.
# The Y precision home movement will be performed.
# The dual-X-axis precision home maneuver will be performed.

==Limit and home switch configuration==

[[File:HomeLimit.PNG]]

''(TODO: add illustration showing distance coded reference mark options)''

''(Unconfirmed proposal at this time)'' [[User:ChuckH|ChuckH]] 23:42, 20 October 2012 (CEST)

Each axis has two switches: a '''limit switch''' and a '''home switch'''.
* The '''limit switch''' is activated at *either* end of travel. Its function is to protect against machine damage.
** Attempting to move further into the limit when the limit switch is active will cause all axis movement to stop, the torch to be shut off, and any other "safe shutdown" operation to be performed.
** The limit switch could be hit if the program erroneously commands the tool to move beyond the edge of the table
** The limit switch could also be hit if the torch table loses step (e.g. by hitting an obstruction) and subsequently performs a movement which takes it to the edge of the table
** The limit switch ''may'' be implemented as two physical switches wired in parallel, or the machine construction may permit a single switch to be used.
** Repeatable precision of actuation point is not very critical.
** This function is especially important if the table is expected to do automated cutting without constant human supervision.
* The '''home switch''' transitions between inactive and active at a point partway through the legal travel of the machine.
** For example, it might be active at the negative end of travel, and go inactive after 6 inches of movement.
** The home switch is used only for locating a repeatable zero position when the machine is powered on (or when recovering from lost steps)
*** Note that the logical "machine zero" coordinate may be placed at any programmed position relative to the physical home switch.
** Repeatable precision may be important
*** For the dual-motor axis, to establish accurate squareness
*** For all axes, to pick up in the middle of an interrupted job
*** If fixturing is used for repeat "production style" operations
** (''update, 14-July-2103:'') Instead of responding to a single flag location, the home switch could be actuated many times by multiple flags along the travel, with carefully designed nonuniform spacing between flags
*** This implements "distance coded reference marks" (DCRM), e.g. [[http://www.rls.si/en/dcrm-distance-coded-reference-mark-system--15934]], [[http://www.heidenhain.de/presentation/posa/en/index/N10584/N108A7/N10926.html]], [[http://www.newall.com/upload/content/file/SHG-TC%20-%20Distance-Coded%20Protocol%20-%20USA%20Ver%2004-07-05.pdf]]
*** DCRM is often applied to incremental linear encoder systems; the same principle is effective here using motor step count as the "incremental scale".
*** Using DCRM, the axis only needs to traverse two flag transitions after startup in order to unambiguously determine absolute position.
** By construction, the home switch is active at one end of travel and inactive at the other
*** This allows the machine to know which end of travel it is at in the event the limit switch is activated
*** This, in turn, allows the machine to permit recovery movement from the limit condition back into legal travel, while ignoring a command to go further into the limit zone.

There is an alternative switch configuration which places individual limit switches at the positive and negative limits of legal travel. However the configuration above is preferred because it supports faster homing and simpler control logic. Specifically:
# The substantial distance between the end of travel and the home switch location gives the machine overtravel room to do a controlled stop from high speed: maximum slewing speed can be used during initial homing without risk of slamming into the physical end-of-travel.
# Home switch placement can minimize the typical startup time.
#* If an axis is usually parked near one end of travel, the home switch can be placed there
#* If the axis position on startup is random, placing the home switch in the center of travel will minimize the average seek time.
#* DCRM can be implemented to obtain short startup/home times no matter what the starting position.
# The "safety shutdown" limit-switch function can be always active, and is independent of homing
#* The alternative approach requires logically repurposing a limit switch as home switch during home operations

==Switch Types==

The steppernug interface provides 5V power to sensor switches so either electronic or mechanical switches are easily accommodated.
* Mechanical microswitches are simple and effective.
* A Hall switch (e.g. [[Hall_Effect_Sensor_Module|this]]) is rugged but its position precision is probably only suitable for limits, not home switches.
* An optical interrupter (e.g. [http://www.mouser.com/ProductDetail/Sharp-Microelectronics/GP1A75EJ000F/?qs=%2fha2pyFaduhmXejJv184BikaBEqZykWweNnmsglkeuWVbMieAKIiNg%3d%3d Sharp GP1A75EJ000F]) can give precisely repeatable homing.

== Switch response time ==

The home switch should respond within one motor step time at the "creep speed" used for final approach. This speed might be ~100 steps/sec which gives us ~10ms.

The limit switch should respond quickly enough so that an emergency stop initiated by the switch will stop the machine motion before it hits a mechanical stop. This time is dependent on a lot of different design parameters, but is probably at least 10ms.

The limited response speed required allows us some latitude for noise suppression.

Since all switch signals pass through the I2C expander for I/O, there is about 150 usec (0.15ms) added, see [[Stepper_Testing#timing|here]].

=Torch control=

Software can use an M code to start the cut (e.g. open cutting-oxygen valve, strike plasma arc).

A second M code could shut down the entire torch (e.g. at the end of an unsupervised cutting session).

See also [[CNC_Torch_Table/Research_Development#Cutting_Torch]]

==Plasma Torch==

[[Plasma_Cutter_Design#Plasma_Cutter_PC_Interface]]

[http://www.metalwebnews.com/howto/plasma/presentation.pdf This presentation] on plasma-cutting accurate holes also suggests that ramping down plasma current while torch is still moving is good practice. (It makes the electrodes last longer.)

[[Sensing_Distance_from_Work_Piece|Z-axis arc voltage height control]]. Needs design work.

[[Plasma_Cutter_Cut_Speed_as_a_Function_of_Metal_Thickness|Cutting speed]]

Hypertherm:

[[File:PlasmaSpeed.jpg|400px]]

==Oxyfuel (oxyacetylene, oxypropane, etc) cutting torch==

During cutting, an oxyfuel cutting torch is literally burning the steel with a blast of oxygen; most of the heat comes from oxidizing the iron. However to start a new cut ("piercing") you must preheat the steel, relying on the acetylene or LPG for heat. After the steel is red hot you boost the oxygen flow and make the cut. We will want an oxygen-rated valve controlled by the microprocessor. "Oxygen-rated" mostly means the valve is thoroughly cleaned of all oil or flammable solvents that tend to explode on contact with pure oxygen; good practical reference [http://www.gmcscuba.com/pdf/CONVERTING%20DIVE%20TANKS%20FOR%20OXYGEN%20SERVICE.pdf here]. A solenoid valve like [http://www.lesman.com/acatalog/ASCO_8210_Oxygen-Service_Valves.html this] in combination with an ordinary regulator would give basic on/off control, but see better suggestions below.

Fairly technical application note about how to do good oxyfuel machine cutting from ESAB: [http://www.esabna.com/literature/Gas%20Apparatus/Miscellaneous/Oxy-Fuel_Cutting_Quality_0558006464.pdf]

[http://www.cnczone.com/forums/cnc_plasma_waterjet_machines/98346-cnc_oxy_fuel_discussion-25.html#post778595 This] ''long'' forum thread contains a lot of information about implementing small-shop CNC oxyfuel with programmed preheat, pierce, and cutting gas controls, auto ignition, etc. Based partly on this information, here are some control design suggestions for an Arduino-based CNC like [[CoolRAMPS]] or [[CNC_Torch_Table_Control_Overview#Steppernug_Driver_and_Interface_.28alternative_to_CoolRamps.29|Steppernug/grbl]]:
* use dome loaded regulators (e.g. Victor DL700 [http://www.amazon.com/Victor-0780-1188-DL700-500-Dome-Regulator/dp/B0047684PG] [http://victortechnologies.com/IM_Uploads/doclib_8016_DocLib_2331_56-0679%20%20DL%20700%20External%20Dome-Loaded%20Regulator%20Part%20Bulletin.pdf]) driven by regulated shop air [[File:DL700.png|thumb]] [[File:VTS250.png|thumb]]
** general description of spring- and dome-loaded regulators [http://www.documentation.emersonprocess.com/groups/public/documents/bulletins/debul2008x012.pdf here]
** It appears that almost any standard screw-handle regulator can be converted to "dome loaded" by sealing up the housing cap and replacing the screw/spring with an air pressure fitting. See video below. A classic dual-stage like the [http://victortechnologies.com/IM_Uploads/doclib_8039_DocLib_2310_56-0623%20VTS%20250%20Series%20Regulators.pdf VTS250] should work very nicely for conversion
** As with manual regulators, if oxy- or fuel-tank pressure exceeds inlet rating of dome-loaded regulator, a first-stage tank regulator will be required.
** With the dome-loaded regulators, gas on/off as well as pressure setting can be obtained with low-cost shop air components and small valves (e.g [http://www.ebay.com/itm/4V130C-06-DC24V-Solenoid-Air-Valve-5-port-3-position-/290652595990 4V130C],[http://www.automationdirect.com/adc/Shopping/Catalog/Pneumatic_Components/Pneumatic_Valves_-a-_Accessories/Solenoid_Air_Valves_-a-_Accessories/5-port_(4-way),_3-pos.,_Body_Ported_-z-_Manifold_(AVS-5,AM_Series)/AVS-523C1-24D AVS-523C1])
** Using a [http://www.digikey.com/product-detail/en/MPXHZ6400AC6T1/MPXHZ6400AC6T1CT-ND/2057456 solid-state pressure sensor] for feedback, the Arduino can set the regulated pressures to programmed levels by actuating the pneumatic valves (increase/decrease loading pressure until feedback is correct). See video below and code on [http://github.com/chuck-h/ose-gaspressurecontrol github].
* use an electric igniter ([http://www.rvpartwholesaler.com/servlet/the-31/Dometic-2931132019-Refrigerator-Reignitor/Detail RV fridge igniter], [http://www.amazon.com/GrillPro-20620-Electric-Button-Igniter/dp/B000FJVKNM BBQ igniter], [https://www.sparkfun.com/products/11218 spark coil]).
* follow the sequencing of x,y,z motions, pressure changes, on/off, and ignition described by the folks on the forum thread above.
** Develop a library of pressure/time/positioning parameters for different material thicknesses and tip sizes that can be applied automatically by the G-code programming; this should minimize setup time and tweaking.

<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=H3Z3EHqTn44"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=WcUnHnZJ8xU"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=uwCbohxajOY"}
)
</script>
</html>

Installing a [http://www.clippard.com/part/MNV-1K needle valve] at the solenoid air valve improved control smoothness a bit compared to video above.

[[Image:ClippardNeedle.jpg|300px]]

=== oxygen ===

The cutting oxygen for the torch must be high purity (according to the ESAB note above less than 95% purity simply will not cut steel, and >99.5% is required for best quality). Until recently, this meant cryogenically separated oxygen, depending on a large capital plant, and thus the user must rely on commercially provided tank oxygen. For some 30 years, [http://en.wikipedia.org/wiki/Pressure_swing_adsorption pressure-swing-adsorption (PSA) separators] have been available, but standard designs do not remove argon and therefore result in about 95%-oxygen, 5%-argon output gas. PSA construction is low-tech and works very nicely at small scale, e.g. portable breathing-oxygen units, and would be quite suitable for OSE. 95% purity is probably adequate for the preheat flame (ChuckH conjecture). For higher-purity cutting oxygen, PSA can be extended with additional zeolite materials [http://www.ou.edu/class/che-design/a-design/projects-2007/Oxygen%20Generator-Presentation.pdf] or activated carbon [http://www.airsepcpd.com/airsepcpd/pdfs/12779.pdf]; despite [http://cr4.globalspec.com/blogentry/20384/To-Build-an-Oxygen-Concentrator-or-Not this discussion] there is no clear record of small-scale DIY implementation of 99% oxygen PSA.

=== oxyacetylene ===

Recommendations from Victor:

[[File:Victor_Oxy_Acetylene.jpg]]

Commercial oxy-fuel machine cutting heads
* [http://www.pierce.cz/production/components-for-building-and-retrofiting-cutting-machines/autogenni-motorizovana-rezaci-hlava.htm?lang=en Czech] one with capacitive height sensor feature

Components offered by JB: [[CNC_Torch_Table_Log#Oct._21.2C_2012]]

== Oxy-propane, -natural gas, etc ==
[http://www.cousesteel.com/AndysPlace/PropaneAcetylene.html Propane] instead of acetylene. Note the large preheat oxygen flow (not in a consistent stoichiometric ratio to fuel) in this chart. Odd.

[[File:VictorLPGcutting.png]]

Would [[Gasifier|gasifier-gas]] or [[biogas]] & oxygen work? Probably, as natural gas is primarily methane and is a commercially successful cutting-torch fuel.

=See Also=
[[Distributed_CNC_Motion_Control]]

[[Category:CNC Torch Table Prototype II]]
[[Category:Vann]]

CNC Torch Table 2/Control Overview

2013-10-31T00:48:13Z

Daniel Benamy: /* Marlin */

{{Template:Category=Torch Table}}

=Overview=
<html><img src="https://docs.google.com/drawings/pub?id=1SKGaBa6N21DPzXm9ILuqwPubc6nnRSBAARbkKaEU9hw&w=480&h=360"></html>

=Motor controller and drivers=

==RAMPS==
Dan's using [[RAMPS]] in Oct 2013 to get the table up and running ASAP. The plan is then to replace it with something beefier so we can go faster.

==Alternatives==
See [[Stepper Motor Controller]] and [[Stepper Motor Driver]].

=Software=

==G-code Prep==
[[File:Toolchain.svg|thumb|toolchain pathways]]
[[ImplicitCAD]] (see also [[Parametric_Design_Pilot_Project]])

[[Gcodetools]]

[[DXF_to_G-code_Conversion_Tutorial]]

[[Computer_to_Microcontroller]]

Nesting software would be useful. Example commercial product [http://www.mynesting.com/ here]. Anything open source?

[[DXF_to_G-code_Conversion_Tutorial#Piercing|Gcode preheat]]

Correction for torch cut kerf width ("cutter compensation" in CNC lingo) needed. G40/G41 but grbl does not interpret these.

==G Code Runner==
aka firmware aka motor controller (distinct from motor driver)

This is the firmware running on Arduino which converts a series of G-code commands to step/direction pulses for the drivers.

===Marlin===
When Dan Benamy was getting things going again in Oct 2013, he was using Marlin because grbl doesn't work with RAMPS out of the box.

Marlin will need some modifications if we want our 2 long axis motors to be on separate drivers rather than in parallel on one driver. See http://shapeoko.com/forum/viewtopic.php?f=4&t=1095 for someone doing this.

* I cloned marlin from github and checked out the Marlin_v1 tag.
* Opened Marlin/Marlin/Marlin.pde
* Edited Configuration.h
** #define MOTHERBOARD 35 - not sure if this is what we want
** #define DISABLE_E true // For all extruders
** #define TEMP_SENSOR_0 0 // Since we don't have temp sensors
** #define TEMP_SENSOR_1 0 // Since we don't have temp sensors
* Edited Configuration_adv.h
** Uncommented "#define Y_DUAL_STEPPER_DRIVERS". I used Y because Marlin doesn't support dual drivers on X. We'll use Y as the long axis, X as the short axis, and Z as height. The 2nd Y will be output on the 2nd extruder port (http://reprap.org/wiki/RAMPS_1.4#Wiring)

=== grbl ===
When someone (Chuck?) was working on using the steppernug, they were running a modified grbl fork https://github.com/chuck-h/grbl/tree/edge. Changes from standard grbl [https://github.com/grbl/grbl]:
* Hardware I/O reassignment for steppernug interface
** different pin assignments on Arduino
** I2C extender
* substantially revised [[CNC_Torch_Table_Control_Overview#Limits_and_Homing|homing code]]
** dual X axis
** deep changes to stepper drive algorithm (implementing independent-axis trapezoidal move control during homing, as opposed to standard coordinated-axis move control for cutting) which should improve performance on long, limited-aceleration axes like torch table X and Y.

==Sending G Code to Firmware==

===Printrun===
This is what Dan's using in Oct 2013.

There's good installation instructions at https://github.com/kliment/Printrun. He wanted to do a source install but gave up when it wasn't easy with pip because it needs to use system wide python for access to the display.

* Change baud rate to 250000.
* Click connect.

===Other Software===
[[GcodeCommunications]]: other programs to send the g-code file from a host computer to a controller.

===Hardware===
Talk to Arduino with USB, or for longer distance RS422 e.g. [http://www.mouser.com/ProductDetail/Maxim-Integrated-Products/MAX3488ECSA+/?qs=sGAEpiMZZMvbyeSUH4qH%2fEqdkzg%252bEBoj MAX3488E]

== Testing ==
[[Stepper_Testing|Testing]]

=Limits and Homing=

==Dual-motor homing==
The x axis (long axis) has 2 stepper motors. In the steppernug system, these have separate driver modules which receive identical step, direction, and enable signals.

For zeroing, the x axis needs to decouple - so if we get the x axis out of parallel, we can jog the x axes back into parallel by hitting their home switches independently. Steppernug supports this by allowing the Arduino to control a gate which blocks step pulses to the second driver module; in this condition the second motor will freeze and only the first motor will move. There is no provision for moving the second motor without moving the first, but that function is not required for the homing algorithm.

==Axis sequence==
# We will home the Z axis to its upper position first, just in case there are obstructions to clear during the X and Y axis homing.
# X and Y axes will do their initial fast moves to find home simultaneously (overlapped homing) to save time.
# The Y precision home movement will be performed.
# The dual-X-axis precision home maneuver will be performed.

==Limit and home switch configuration==

[[File:HomeLimit.PNG]]

''(TODO: add illustration showing distance coded reference mark options)''

''(Unconfirmed proposal at this time)'' [[User:ChuckH|ChuckH]] 23:42, 20 October 2012 (CEST)

Each axis has two switches: a '''limit switch''' and a '''home switch'''.
* The '''limit switch''' is activated at *either* end of travel. Its function is to protect against machine damage.
** Attempting to move further into the limit when the limit switch is active will cause all axis movement to stop, the torch to be shut off, and any other "safe shutdown" operation to be performed.
** The limit switch could be hit if the program erroneously commands the tool to move beyond the edge of the table
** The limit switch could also be hit if the torch table loses step (e.g. by hitting an obstruction) and subsequently performs a movement which takes it to the edge of the table
** The limit switch ''may'' be implemented as two physical switches wired in parallel, or the machine construction may permit a single switch to be used.
** Repeatable precision of actuation point is not very critical.
** This function is especially important if the table is expected to do automated cutting without constant human supervision.
* The '''home switch''' transitions between inactive and active at a point partway through the legal travel of the machine.
** For example, it might be active at the negative end of travel, and go inactive after 6 inches of movement.
** The home switch is used only for locating a repeatable zero position when the machine is powered on (or when recovering from lost steps)
*** Note that the logical "machine zero" coordinate may be placed at any programmed position relative to the physical home switch.
** Repeatable precision may be important
*** For the dual-motor axis, to establish accurate squareness
*** For all axes, to pick up in the middle of an interrupted job
*** If fixturing is used for repeat "production style" operations
** (''update, 14-July-2103:'') Instead of responding to a single flag location, the home switch could be actuated many times by multiple flags along the travel, with carefully designed nonuniform spacing between flags
*** This implements "distance coded reference marks" (DCRM), e.g. [[http://www.rls.si/en/dcrm-distance-coded-reference-mark-system--15934]], [[http://www.heidenhain.de/presentation/posa/en/index/N10584/N108A7/N10926.html]], [[http://www.newall.com/upload/content/file/SHG-TC%20-%20Distance-Coded%20Protocol%20-%20USA%20Ver%2004-07-05.pdf]]
*** DCRM is often applied to incremental linear encoder systems; the same principle is effective here using motor step count as the "incremental scale".
*** Using DCRM, the axis only needs to traverse two flag transitions after startup in order to unambiguously determine absolute position.
** By construction, the home switch is active at one end of travel and inactive at the other
*** This allows the machine to know which end of travel it is at in the event the limit switch is activated
*** This, in turn, allows the machine to permit recovery movement from the limit condition back into legal travel, while ignoring a command to go further into the limit zone.

There is an alternative switch configuration which places individual limit switches at the positive and negative limits of legal travel. However the configuration above is preferred because it supports faster homing and simpler control logic. Specifically:
# The substantial distance between the end of travel and the home switch location gives the machine overtravel room to do a controlled stop from high speed: maximum slewing speed can be used during initial homing without risk of slamming into the physical end-of-travel.
# Home switch placement can minimize the typical startup time.
#* If an axis is usually parked near one end of travel, the home switch can be placed there
#* If the axis position on startup is random, placing the home switch in the center of travel will minimize the average seek time.
#* DCRM can be implemented to obtain short startup/home times no matter what the starting position.
# The "safety shutdown" limit-switch function can be always active, and is independent of homing
#* The alternative approach requires logically repurposing a limit switch as home switch during home operations

==Switch Types==

The steppernug interface provides 5V power to sensor switches so either electronic or mechanical switches are easily accommodated.
* Mechanical microswitches are simple and effective.
* A Hall switch (e.g. [[Hall_Effect_Sensor_Module|this]]) is rugged but its position precision is probably only suitable for limits, not home switches.
* An optical interrupter (e.g. [http://www.mouser.com/ProductDetail/Sharp-Microelectronics/GP1A75EJ000F/?qs=%2fha2pyFaduhmXejJv184BikaBEqZykWweNnmsglkeuWVbMieAKIiNg%3d%3d Sharp GP1A75EJ000F]) can give precisely repeatable homing.

== Switch response time ==

The home switch should respond within one motor step time at the "creep speed" used for final approach. This speed might be ~100 steps/sec which gives us ~10ms.

The limit switch should respond quickly enough so that an emergency stop initiated by the switch will stop the machine motion before it hits a mechanical stop. This time is dependent on a lot of different design parameters, but is probably at least 10ms.

The limited response speed required allows us some latitude for noise suppression.

Since all switch signals pass through the I2C expander for I/O, there is about 150 usec (0.15ms) added, see [[Stepper_Testing#timing|here]].

=Torch control=

Software can use an M code to start the cut (e.g. open cutting-oxygen valve, strike plasma arc).

A second M code could shut down the entire torch (e.g. at the end of an unsupervised cutting session).

See also [[CNC_Torch_Table/Research_Development#Cutting_Torch]]

==Plasma Torch==

[[Plasma_Cutter_Design#Plasma_Cutter_PC_Interface]]

[http://www.metalwebnews.com/howto/plasma/presentation.pdf This presentation] on plasma-cutting accurate holes also suggests that ramping down plasma current while torch is still moving is good practice. (It makes the electrodes last longer.)

[[Sensing_Distance_from_Work_Piece|Z-axis arc voltage height control]]. Needs design work.

[[Plasma_Cutter_Cut_Speed_as_a_Function_of_Metal_Thickness|Cutting speed]]

Hypertherm:

[[File:PlasmaSpeed.jpg|400px]]

==Oxyfuel (oxyacetylene, oxypropane, etc) cutting torch==

During cutting, an oxyfuel cutting torch is literally burning the steel with a blast of oxygen; most of the heat comes from oxidizing the iron. However to start a new cut ("piercing") you must preheat the steel, relying on the acetylene or LPG for heat. After the steel is red hot you boost the oxygen flow and make the cut. We will want an oxygen-rated valve controlled by the microprocessor. "Oxygen-rated" mostly means the valve is thoroughly cleaned of all oil or flammable solvents that tend to explode on contact with pure oxygen; good practical reference [http://www.gmcscuba.com/pdf/CONVERTING%20DIVE%20TANKS%20FOR%20OXYGEN%20SERVICE.pdf here]. A solenoid valve like [http://www.lesman.com/acatalog/ASCO_8210_Oxygen-Service_Valves.html this] in combination with an ordinary regulator would give basic on/off control, but see better suggestions below.

Fairly technical application note about how to do good oxyfuel machine cutting from ESAB: [http://www.esabna.com/literature/Gas%20Apparatus/Miscellaneous/Oxy-Fuel_Cutting_Quality_0558006464.pdf]

[http://www.cnczone.com/forums/cnc_plasma_waterjet_machines/98346-cnc_oxy_fuel_discussion-25.html#post778595 This] ''long'' forum thread contains a lot of information about implementing small-shop CNC oxyfuel with programmed preheat, pierce, and cutting gas controls, auto ignition, etc. Based partly on this information, here are some control design suggestions for an Arduino-based CNC like [[CoolRAMPS]] or [[CNC_Torch_Table_Control_Overview#Steppernug_Driver_and_Interface_.28alternative_to_CoolRamps.29|Steppernug/grbl]]:
* use dome loaded regulators (e.g. Victor DL700 [http://www.amazon.com/Victor-0780-1188-DL700-500-Dome-Regulator/dp/B0047684PG] [http://victortechnologies.com/IM_Uploads/doclib_8016_DocLib_2331_56-0679%20%20DL%20700%20External%20Dome-Loaded%20Regulator%20Part%20Bulletin.pdf]) driven by regulated shop air [[File:DL700.png|thumb]] [[File:VTS250.png|thumb]]
** general description of spring- and dome-loaded regulators [http://www.documentation.emersonprocess.com/groups/public/documents/bulletins/debul2008x012.pdf here]
** It appears that almost any standard screw-handle regulator can be converted to "dome loaded" by sealing up the housing cap and replacing the screw/spring with an air pressure fitting. See video below. A classic dual-stage like the [http://victortechnologies.com/IM_Uploads/doclib_8039_DocLib_2310_56-0623%20VTS%20250%20Series%20Regulators.pdf VTS250] should work very nicely for conversion
** As with manual regulators, if oxy- or fuel-tank pressure exceeds inlet rating of dome-loaded regulator, a first-stage tank regulator will be required.
** With the dome-loaded regulators, gas on/off as well as pressure setting can be obtained with low-cost shop air components and small valves (e.g [http://www.ebay.com/itm/4V130C-06-DC24V-Solenoid-Air-Valve-5-port-3-position-/290652595990 4V130C],[http://www.automationdirect.com/adc/Shopping/Catalog/Pneumatic_Components/Pneumatic_Valves_-a-_Accessories/Solenoid_Air_Valves_-a-_Accessories/5-port_(4-way),_3-pos.,_Body_Ported_-z-_Manifold_(AVS-5,AM_Series)/AVS-523C1-24D AVS-523C1])
** Using a [http://www.digikey.com/product-detail/en/MPXHZ6400AC6T1/MPXHZ6400AC6T1CT-ND/2057456 solid-state pressure sensor] for feedback, the Arduino can set the regulated pressures to programmed levels by actuating the pneumatic valves (increase/decrease loading pressure until feedback is correct). See video below and code on [http://github.com/chuck-h/ose-gaspressurecontrol github].
* use an electric igniter ([http://www.rvpartwholesaler.com/servlet/the-31/Dometic-2931132019-Refrigerator-Reignitor/Detail RV fridge igniter], [http://www.amazon.com/GrillPro-20620-Electric-Button-Igniter/dp/B000FJVKNM BBQ igniter], [https://www.sparkfun.com/products/11218 spark coil]).
* follow the sequencing of x,y,z motions, pressure changes, on/off, and ignition described by the folks on the forum thread above.
** Develop a library of pressure/time/positioning parameters for different material thicknesses and tip sizes that can be applied automatically by the G-code programming; this should minimize setup time and tweaking.

<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=H3Z3EHqTn44"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=WcUnHnZJ8xU"}
)
</script>
</html>
<html>
<script type="text/javascript" src="http://s3.www.universalsubtitles.org/embed.js">
(
{"video_url": "http://www.youtube.com/watch/?v=uwCbohxajOY"}
)
</script>
</html>

Installing a [http://www.clippard.com/part/MNV-1K needle valve] at the solenoid air valve improved control smoothness a bit compared to video above.

[[Image:ClippardNeedle.jpg|300px]]

=== oxygen ===

The cutting oxygen for the torch must be high purity (according to the ESAB note above less than 95% purity simply will not cut steel, and >99.5% is required for best quality). Until recently, this meant cryogenically separated oxygen, depending on a large capital plant, and thus the user must rely on commercially provided tank oxygen. For some 30 years, [http://en.wikipedia.org/wiki/Pressure_swing_adsorption pressure-swing-adsorption (PSA) separators] have been available, but standard designs do not remove argon and therefore result in about 95%-oxygen, 5%-argon output gas. PSA construction is low-tech and works very nicely at small scale, e.g. portable breathing-oxygen units, and would be quite suitable for OSE. 95% purity is probably adequate for the preheat flame (ChuckH conjecture). For higher-purity cutting oxygen, PSA can be extended with additional zeolite materials [http://www.ou.edu/class/che-design/a-design/projects-2007/Oxygen%20Generator-Presentation.pdf] or activated carbon [http://www.airsepcpd.com/airsepcpd/pdfs/12779.pdf]; despite [http://cr4.globalspec.com/blogentry/20384/To-Build-an-Oxygen-Concentrator-or-Not this discussion] there is no clear record of small-scale DIY implementation of 99% oxygen PSA.

=== oxyacetylene ===

Recommendations from Victor:

[[File:Victor_Oxy_Acetylene.jpg]]

Commercial oxy-fuel machine cutting heads
* [http://www.pierce.cz/production/components-for-building-and-retrofiting-cutting-machines/autogenni-motorizovana-rezaci-hlava.htm?lang=en Czech] one with capacitive height sensor feature

Components offered by JB: [[CNC_Torch_Table_Log#Oct._21.2C_2012]]

== Oxy-propane, -natural gas, etc ==
[http://www.cousesteel.com/AndysPlace/PropaneAcetylene.html Propane] instead of acetylene. Note the large preheat oxygen flow (not in a consistent stoichiometric ratio to fuel) in this chart. Odd.

[[File:VictorLPGcutting.png]]

Would [[Gasifier|gasifier-gas]] or [[biogas]] & oxygen work? Probably, as natural gas is primarily methane and is a commercially successful cutting-torch fuel.

=See Also=
[[Distributed_CNC_Motion_Control]]

[[Category:CNC Torch Table Prototype II]]
[[Category:Vann]]

CNC Torch Table 2/Research Development

2013-10-31T00:36:34Z

Daniel Benamy:

{{GVCS Header}}

=Status=

This is Dan Benamy's understanding as of Oct 2013:

There have been various ambitious projects over the past few years to do amazing things with the torch table. Unfortunately none of them seem to have reached the finish line (including integration with all the other work).

For the short term Dan plans to get the version 2 table up and running ASAP with the [[RAMPS]] system so we can get something working and build momentum. Then we can quickly iterate to incorporate better modules such as the [[Steppernug]], [[CoolDRV]], or [[CoolRAMPS]] which will allow us to cut faster, sensors for more reliable operation, fuel control for more efficient fuel usage, etc.

Generally, Dan's strategy is to '''make lots of quick iterations with self-contained improvements''' so we almost always have a working table and project handoff is simpler. I'm also focusing on '''getting something working''' at FeF that we can use to cut parts we need for other machines, '''rather than something that's easily reproducible or perfectly documented'''. I'm trading off reproducibility and user friendly docs for getting it working for two reasons: 1- being able to cut [[Warehouse]] parts will save lots of time and money on all other development. 2- it will also be a waste of effort to carefully document stuff that turns out not to work well. Once we get to the point where we can cut useful stuff, I (or you!) will need to make any changes needed for ease of reproduction, and create awesome manufacturing guides so others can copy it.

Lots of info on the control systems at [[CNC Torch Table 2/Control Overview]].

=Next Steps=

* Fix stiff long axis motor.
* The standard RAMPS setup for 2 motors on one axis is to run them in parallel off one driver. Since our motors draw a fair amount of current, try to use a separate driver for each motor and [http://shapeoko.com/forum/viewtopic.php?f=4&t=1095 modify marlin] to drive those two drivers identically.
* Run a simple test gcode program- https://github.com/grbl/grbl/wiki/G-Code-Examples.
* Draw a rectangle in librecad, run it through [[DXF to G-code Conversion Tutorial | dxf2gcode]] and use [http://reprap.org/wiki/Pronterface Printrun] to stream it to the arduino. Get the table to draw the rectangle.

Then I'd do incremental improvements, keeping the table working after each step so if I had to leave or something didn't work, it'd be easy to revert to the most recent working stuff. Steps until we could use the table to actually make parts for fabricating other machines:
* Add a circle to the dxf that's not touching the rectangle. Re-run and make sure the head lifts up between the shapes.
* Add [[DXF_to_G-code_Conversion_Tutorial#Piercing | gcode postprocessing]] if still needed for piercing and torch width. The "torch" should move back and forth while making an initial "pierce". For the circle, I think it should make the pieces inside the circle. I'm not sure if it should pierce the rectangle inside or on one edge. We want it to make the pierce in a part of the metal we won't use. I wonder how the piercing code knows what that is... There's a conversation [https://groups.google.com/forum/#!msg/dxf2gcode-dev/6ZnNcX3O5i4/d-3NeBfHpbUJ here] about integrating this functionality into dxf2gcode which would be great for ease of use and gives us a gui where maybe we could click where we want the pierce to be.
* Try it with the real torch!!! For future steps, I'd switch back to the sharpie for testing and only use the torch once things look good.

If we're lucky, this gets us to milestone 1 - can cut useful warehouse plates.

Tasks for milestone 2 and beyond are in github (link below).

=Developement Board=
<html><iframe width=80% height='400' frameborder='0' src='https://docs.google.com/spreadsheet/pub?key=0Av4ZjQn4DHJHdDBNVmlFTmZ5S3YxckY3ZkxZc01ISHc&output=html&widget=true'></iframe></html>

[https://docs.google.com/spreadsheet/ccc?key=0Av4ZjQn4DHJHdDBNVmlFTmZ5S3YxckY3ZkxZc01ISHc#gid=2 edit]

=Resources=
* Issue Tracker- https://github.com/OSE/CNC-Torch-Table-OSE/issues
* 3d models
** Github (solidworks 3d models and issues) - https://github.com/OSE/CNC-Torch-Table-OSE. '''Use this for new development'''
** This was originally developed at an [https://github.com/Fractal618/CNC-Torch-Table-OSE old repo] and we forked it into the OSE org. '''Do not use the old repo.'''
** [http://opensourceecology.org/w/images/7/79/CNC_Torch_Table_-_Sketchup_Model.zip] - Sketchup files - I don't know if there are conversions of the solidworks files in github or something else.
* 2d drawings- [http://opensourceecology.org/w/images/d/d1/Creation_Flame_CNC_Torch_Table_Drawings.zip] - DXFs of motor mounts

=Design=
[[Image:Table_Frame.JPG|none|360px|Torch Table Prototype II Design.]]

Lots of information about the control system in [[CNC Torch Table 2/Control Overview]].

Additional discussion at [[TorchTableModularTooling]]

=Additional Notes=
*As a large x-y-z coordinate table, the Torch Table has potential applications with other tooling besides a cutting torch. One limitation is that the drive system is not powerful enough or stiff enough to support heavy cutting-tool forces.

CNC Torch Table 2/Research Development

2013-10-31T00:30:07Z

Daniel Benamy: /* Next Steps */

{{GVCS Header}}

=Status=

This is Dan Benamy's understanding as of Oct 2013:

There have been various ambitious projects over the past few years to do amazing things with the torch table. Unfortunately none of them seem to have reached the finish line (including integration with all the other work).

For the short term Dan plans to get the version 2 table up and running ASAP with the [[RAMPS]] system so we can get something working and build momentum. Then we can quickly iterate to incorporate better modules such as the [[Steppernug]], [[CoolDRV]], or [[CoolRAMPS]] which will allow us to cut faster, sensors for more reliable operation, fuel control for more efficient fuel usage, etc.

Generally, Dan's strategy is to '''make lots of quick iterations with self-contained improvements''' so we almost always have a working table and project handoff is simpler. I'm also focusing on '''getting something working''' at FeF that we can use to cut parts we need for other machines, '''rather than something that's easily reproducible or perfectly documented'''. I'm trading off reproducibility and user friendly docs for getting it working for two reasons: 1- being able to cut [[Warehouse]] parts will save lots of time and money on all other development. 2- it will also be a waste of effort to carefully document stuff that turns out not to work well. Once we get to the point where we can cut useful stuff, I (or you!) will need to make any changes needed for ease of reproduction, and create awesome manufacturing guides so others can copy it.

Lots of info on the control systems at [[CNC Torch Table 2/Control Overview]].

=Next Steps=

* Fix stiff long axis motor.
* The standard RAMPS setup for 2 motors on one axis is to run them in parallel off one driver. Since our motors draw a fair amount of current, try to use a separate driver for each motor and [http://shapeoko.com/forum/viewtopic.php?f=4&t=1095 modify marlin] to drive those two drivers identically.
* Run a simple test gcode program- https://github.com/grbl/grbl/wiki/G-Code-Examples.
* Draw a rectangle in librecad, run it through [[DXF to G-code Conversion Tutorial | dxf2gcode]] and use [http://reprap.org/wiki/Pronterface Printrun] to stream it to the arduino. Get the table to draw the rectangle.

Then I'd do incremental improvements, keeping the table working after each step so if I had to leave or something didn't work, it'd be easy to revert to the most recent working stuff. Steps until we could use the table to actually make parts for fabricating other machines:
* Add a circle to the dxf that's not touching the rectangle. Re-run and make sure the head lifts up between the shapes.
* Add [[DXF_to_G-code_Conversion_Tutorial#Piercing | gcode postprocessing]] if still needed for piercing and torch width. The "torch" should move back and forth while making an initial "pierce". For the circle, I think it should make the pieces inside the circle. I'm not sure if it should pierce the rectangle inside or on one edge. We want it to make the pierce in a part of the metal we won't use. I wonder how the piercing code knows what that is... There's a conversation [https://groups.google.com/forum/#!msg/dxf2gcode-dev/6ZnNcX3O5i4/d-3NeBfHpbUJ here] about integrating this functionality into dxf2gcode which would be great for ease of use and gives us a gui where maybe we could click where we want the pierce to be.
* Try it with the real torch!!! For future steps, I'd switch back to the sharpie for testing and only use the torch once things look good.

If we're lucky, this gets us to milestone 1 - can cut useful warehouse plates.

Tasks for milestone 2 and beyond are in github (link below).

=Developement Board=
<html><iframe width=80% height='500' frameborder='0' src='https://docs.google.com/spreadsheet/pub?key=0Av4ZjQn4DHJHdDBNVmlFTmZ5S3YxckY3ZkxZc01ISHc&output=html&widget=true'></iframe></html>

[https://docs.google.com/spreadsheet/ccc?key=0Av4ZjQn4DHJHdDBNVmlFTmZ5S3YxckY3ZkxZc01ISHc#gid=2 edit]

=Design=
[[Image:Table_Frame.JPG|none|360px|Torch Table Prototype II Design.]]

Lots of information about the control system in [[CNC Torch Table 2/Control Overview]].

Additional discussion at [[TorchTableModularTooling]]

=Resources=
* Issue Tracker- https://github.com/OSE/CNC-Torch-Table-OSE/issues
* 3d models
** Github (solidworks 3d models and issues) - https://github.com/OSE/CNC-Torch-Table-OSE. '''Use this for new development'''
** This was originally developed at an [https://github.com/Fractal618/CNC-Torch-Table-OSE old repo] and we forked it into the OSE org. '''Do not use the old repo.'''
** [http://opensourceecology.org/w/images/7/79/CNC_Torch_Table_-_Sketchup_Model.zip] - Sketchup files - I don't know if there are conversions of the solidworks files in github or something else.
* 2d drawings- [http://opensourceecology.org/w/images/d/d1/Creation_Flame_CNC_Torch_Table_Drawings.zip] - DXFs of motor mounts

=Additional Notes=
*As a large x-y-z coordinate table, the Torch Table has potential applications with other tooling besides a cutting torch. One limitation is that the drive system is not powerful enough or stiff enough to support heavy cutting-tool forces.

CNC Torch Table 2/Research Development

2013-10-31T00:27:09Z

Daniel Benamy: /* Next Steps */

{{GVCS Header}}

=Status=

This is Dan Benamy's understanding as of Oct 2013:

There have been various ambitious projects over the past few years to do amazing things with the torch table. Unfortunately none of them seem to have reached the finish line (including integration with all the other work).

For the short term Dan plans to get the version 2 table up and running ASAP with the [[RAMPS]] system so we can get something working and build momentum. Then we can quickly iterate to incorporate better modules such as the [[Steppernug]], [[CoolDRV]], or [[CoolRAMPS]] which will allow us to cut faster, sensors for more reliable operation, fuel control for more efficient fuel usage, etc.

Generally, Dan's strategy is to '''make lots of quick iterations with self-contained improvements''' so we almost always have a working table and project handoff is simpler. I'm also focusing on '''getting something working''' at FeF that we can use to cut parts we need for other machines, '''rather than something that's easily reproducible or perfectly documented'''. I'm trading off reproducibility and user friendly docs for getting it working for two reasons: 1- being able to cut [[Warehouse]] parts will save lots of time and money on all other development. 2- it will also be a waste of effort to carefully document stuff that turns out not to work well. Once we get to the point where we can cut useful stuff, I (or you!) will need to make any changes needed for ease of reproduction, and create awesome manufacturing guides so others can copy it.

Lots of info on the control systems at [[CNC Torch Table 2/Control Overview]].

=Next Steps=

* Fix stiff long axis motor.
* The standard RAMPS setup for 2 motors on one axis is to run them in parallel off one driver. Since our motors draw a fair amount of current, try to use a separate driver for each motor and [http://shapeoko.com/forum/viewtopic.php?f=4&t=1095 modify marlin] to drive those two drivers identically.
* Run a simple test gcode program- https://github.com/grbl/grbl/wiki/G-Code-Examples.
* Draw a rectangle in librecad, run it through [[DXF to G-code Conversion Tutorial | dxf2gcode]] and use [http://reprap.org/wiki/Pronterface Printrun] to stream it to the arduino. Get the table to draw the rectangle.

Then I'd do incremental improvements, keeping the table working after each step so if I had to leave or something didn't work, it'd be easy to revert to the most recent working stuff. Steps until we could use the table to actually make parts for fabricating other machines:
* Add a circle to the dxf that's not touching the rectangle. Re-run and make sure the head lifts up between the shapes.
* Add [[DXF_to_G-code_Conversion_Tutorial#Piercing | gcode postprocessing]] if still needed for piercing and torch width. The "torch" should move back and forth while making an initial "pierce". For the circle, I think it should make the pieces inside the circle. I'm not sure if it should pierce the rectangle inside or on one edge. We want it to make the pierce in a part of the metal we won't use. I wonder how the piercing code knows what that is... There's a conversation [https://groups.google.com/forum/#!msg/dxf2gcode-dev/6ZnNcX3O5i4/d-3NeBfHpbUJ here] about integrating this functionality into dxf2gcode which would be great for ease of use and gives us a gui where maybe we could click where we want the pierce to be.
* Try it with the real torch!!! For future steps, I'd switch back to the sharpie for testing and only use the torch once things look good.

More in github (see below).

=Developement Board=
<html><iframe width=80% height='500' frameborder='0' src='https://docs.google.com/spreadsheet/pub?key=0Av4ZjQn4DHJHdDBNVmlFTmZ5S3YxckY3ZkxZc01ISHc&output=html&widget=true'></iframe></html>

[https://docs.google.com/spreadsheet/ccc?key=0Av4ZjQn4DHJHdDBNVmlFTmZ5S3YxckY3ZkxZc01ISHc#gid=2 edit]

=Design=
[[Image:Table_Frame.JPG|none|360px|Torch Table Prototype II Design.]]

Lots of information about the control system in [[CNC Torch Table 2/Control Overview]].

Additional discussion at [[TorchTableModularTooling]]

=Resources=
* Issue Tracker- https://github.com/OSE/CNC-Torch-Table-OSE/issues
* 3d models
** Github (solidworks 3d models and issues) - https://github.com/OSE/CNC-Torch-Table-OSE. '''Use this for new development'''
** This was originally developed at an [https://github.com/Fractal618/CNC-Torch-Table-OSE old repo] and we forked it into the OSE org. '''Do not use the old repo.'''
** [http://opensourceecology.org/w/images/7/79/CNC_Torch_Table_-_Sketchup_Model.zip] - Sketchup files - I don't know if there are conversions of the solidworks files in github or something else.
* 2d drawings- [http://opensourceecology.org/w/images/d/d1/Creation_Flame_CNC_Torch_Table_Drawings.zip] - DXFs of motor mounts

=Additional Notes=
*As a large x-y-z coordinate table, the Torch Table has potential applications with other tooling besides a cutting torch. One limitation is that the drive system is not powerful enough or stiff enough to support heavy cutting-tool forces.