https://reprap.org/mediawiki/api.php?action=feedcontributions&user=Bobc&feedformat=atomRepRap - User contributions [en]2024-03-28T11:27:31ZUser contributionsMediaWiki 1.30.0https://reprap.org/mediawiki/index.php?title=Packed_Binary_GCode&diff=179823Packed Binary GCode2017-07-08T10:47:22Z<p>Bobc: </p>
<hr />
<div>=Packed Binary GCode (PBG)=<br />
<br />
Bob Cousins<br />
<br />
28 August 2012<br />
<br />
Version 0.4<br />
<br />
==Goals:==<br />
<br />
* Reduce size of [[G-code]] data<br />
* Compatible with RS274/NGC spec for all types of machine, e.g. for printers, milling, lasers etc<br />
* Should be able to completely recreate ASCII GCode from compressed GCode with no loss of precision/data, comments<br />
* Independent of machine, i.e. does not use machine units<br />
* Extension for string parameters<br />
* Doesn't require significant extra RAM for decoding<br />
* Streamable format, not context dependent<br />
<br />
''Todo: embed binary data?''<br />
<br />
''Todo: add bcd, or double?''<br />
<br />
==Method==<br />
<br />
# GCode blocks are generally a list of <word letter> <number>, e.g. "G1", "Z1.5".<br />
# There are 26 letters, plus a few other items like comments, checksum<br />
# Therefore code letter is stored in 5 bits (0-31).<br />
# Integers can be stored in 1,2 or 4 bytes, signed or unsigned<br />
# Signed decimals stored in float (4 bytes)<br />
# Comments and uncompressed data stored as null terminated string<br />
# Therefore type stored in 3 bits (0-7)<br />
<br />
==Syntax==<br />
<pre><br />
BNF syntax:<br />
<br />
gcode_line ::= { gcode_command … } EOL_MARK;<br />
gcode_command ::= { gcode_word ... } EOC_MARK ;<br />
gcode_word ::= code_type {parameter};<br />
<br />
code_type ::= BYTE ( code << 3 | type );<br />
code ::= 0..30;<br />
type ::= 0..7;<br />
parameter ::= BYTE … ; // 1,2,4 bytes or zero terminated string<br />
<br />
EOC_MARK ::= 0xF8<br />
EOL_MARK ::= 0xF9<br />
<br />
</pre><br />
<br />
==GCode word encoding==<br />
<br />
+--- 1 byte ---+-/ 0 to N bytes /-+<br />
| CODE . TYPE | data |<br />
+--------------+-/ /--------------+<br />
<br />
CODE + TYPE stored in 1 byte:<br />
<br />
<pre> <br />
0000 0ttt CODE 0 = Checksum (*) (numeric data)<br />
0000 1ttt CODE 1 = A (numeric data)<br />
...<br />
1101 0ttt CODE 26 = Z (numeric data)<br />
1101 1ttt CODE 27 = spare<br />
<br />
1110 0111 CODE 28 = Comment (type=string)<br />
1110 1111 CODE 29 = Uncompressed text (type=string)<br />
1111 0111 CODE 30 = String parameter (no word letter)<br />
<br />
1111 1000 CODE 31 = No data, where:<br />
1111 1000 0xF8 = End of command<br />
1111 1001 0xF9 = End of line marker<br />
1111 1010 0xFA-<br />
1111 1111 0xFF spare<br />
</pre> <br />
''todo: block delete?''<br />
<br />
<pre><br />
TYPE:<br />
0 : unsigned byte (1 byte)<br />
1 : signed byte (1)<br />
2 : unsigned short (2 byte) //??<br />
3 : signed short (2 byte)<br />
4 : signed int (4 byte)<br />
5 : BCD decimal<br />
6 : float (4 bytes)<br />
7 : string (N+1 bytes)<br />
<br />
BCD = <br />
0x0 .. 0x9 == 0..9<br />
0xA == '.'<br />
0xB == '-'<br />
0xF == end<br />
</pre><br />
<br />
==Comparison of sizes:==<br />
<br />
Command 1: G1 E10810.1 F1000<br />
<br />
Original size: 21 Bytes<br />
<br />
Updated for errorcheck: N6654 G1 E10810.1 F1000 *65<br />
<br />
Errorcheck size: 29 Bytes<br />
<br />
repetier-protocol: 15 Bytes<br />
<br />
3+2+5+3+2+2<br />
<br />
Packed Binary Gcode: 17 bytes<br />
<br />
<br />
''What is the purpose of the EOC_MARK ? Is there ever a situation where we couldn't replace it with a EOL_MARK instead?''<br />
<br />
A. A line could contain more than one command. [[User:Bobc|Bobc]] ([[User talk:Bobc|talk]])<br />
<br />
''Would it be more compact to encode all integers as something like a [[Wikipedia: variable-length quantity]] ?''<br />
<br />
A. Simple answer, no. [[User:Bobc|Bobc]] ([[User talk:Bobc|talk]])<br />
<br />
''An adaptive compression algorithm would be even more compact. Is there a [[Wikibooks: Data Compression]] implementation that fits in the very limited amount of SRAM available in the Arduino not already used by the RepRap firmware?''<br />
<br />
A. It would be fantastic to use something like zip, but there is nowhere near enough RAM. I spent some time looking for a general purpose decoding algorithm that has a tiny footprint and would fit in a few kB. All the ones I found typical require 100kB + to achieve decent compression. But we don't need to compress general text, so an application specific encoding is a better option.<br />
[[User:Bobc|Bobc]] ([[User talk:Bobc|talk]])<br />
<br />
[[Category:3D model manufacturing software]]</div>Bobchttps://reprap.org/mediawiki/index.php?title=Printrbot&diff=126105Printrbot2014-05-19T18:45:19Z<p>Bobc: </p>
<hr />
<div>{{Languages|Printrbot}}<br />
<br />
{{Development<br />
<!--Header--><br />
|name = Printrbot<br />
|status = working<br />
<!--Image--><br />
|image = Printrbot.jpg<br />
<!--General--><br />
|description = the simplest, cheapest, RepRap 3D printer in the world.<br />
|license = [[Wikipedia:Creative_Commons_license|CC-BY-NC-SA]]<br />
|author = abdrumm<br />
|reprap = ???<br />
|categories = {{tag|Printrbot}} {{tag|Foldable RepRap}} [[:Category:Cartesian-XZ-head|XZ-head]] [[Category:Cartesian-XZ-head]] <br />
|cadModel = [http://www.thingiverse.com/thing:16990 THE Printrbot: thing:16990]<br />
|url = http://printrbot.com/<br />
<br />
}}<br />
<br />
<br/><br />
<br />
'''Printrbot''' is the simplest, cheapest, RepRap 3D printer in the world. As of April 2014 there are four versions - Simple, Jr, Plus & Go.<br />
<br />
Happy Printing,<br />
Brook Drumm<br />
<br />
== Project Goal ==<br />
<br />
The overall goal is not to win the [[Gada Prize]] - although I would be proud :), rather, the goal is to offer a printer that kids can put together and operate. My dream is to provide every school with a Printrbot... and that every Printrbot will produce offspring that produces offspring (...etc....) until every home and school has a 3D printer.<br />
<br />
== Overview ==<br />
<br />
'''One 3D Printer Per Home''' is a huge goal. In reality, only some students will even WANT a 3D printer, so that lowers the bar significantly. My short-term goal is to provide Printrbot 3D printers to any school interested-- AT LOW COST, so that the students '''who want them''' can use the school Prinrbot to print the parts to make a Printrbot.... just add electronics, stepper motors, smooth and threaded rod. Through our "Print It Forward" program, we will ask each school to print, assemble and donate a Printrbot to 3 other schools. Although everyone is welcome to source their own parts, Printrbot.com will offer discounts to make this feasible. By relying on schools and Printrbot owners to print 3 other sets of parts to construct a Printrbot, we hope to spread the RepRap love far and wide!<br />
<br />
== Project Description==<br />
<br />
Printrbot is a reality. This is a real 3D printer that prints TODAY. I have designed this printer myself, only using other people's work for optional items. <br />
<br />
The non-original parts used are:<br />
*Your choice of extruder<br />
*2x belt pulleys<br />
*2x Z-couplers<br />
<br />
===Three Designs: Printrbot Original, -Junior and -Senior=== <br />
*The Printrbot is the original design that has a medium sized printbed (6x6x6in/150x150x150mm), and aims at the sweet-spot between practicality and price.<br />
**[http://www.thingiverse.com/thing:16990 Thingiverse: Printrbot], all printable parts<br />
*The Printrbot Junior is the ultra-small, ultra-cheap version that pushes the boundaries of size, cost and simplicity for a 3D printer, to lower the barriers to entry for 3D printing at home. <br />
*The Printrbot Senior (Gada Edition) will be the special version built specifically for the Gada Prize. While I am grateful that the Gada prize is pushing the technology forward, I believe that 3D printers that have lesser specifications (than the Gada Prize rules dictate) will still be greatly useful for families everywhere. <br />
<br />
Note: according to the official [http://humanityplus.org/wp-content/uploads/2011/02/HumanityRepRapGrandPersonalManufacturingPrize.pdf Gada Prize Rules] - I formally am using the "no derivatives for the Gada Prize” clause. I believe the approach I am using is unique and original to my design.<br />
<br />
'''UPDATE: 11-13-2012... the Printrbot jr.'''<br />
The Printrbot Kickstarter completely consumed my life for the last year. Transitioning to a viable business and juggling competing priorities has also been a challenge. I have been completely absent from updates and such. My absence from this wiki, the forums, irc, etc, does not reflect on my passion for RepRap. I have recently finished my Printrbot jr. design in laser cut wood. It is quite small, but grew a bit to make it sturdy, practical and include a folding hinge to collapse it down enough to fit in a backpack and carry on a plane -which I do every time I fly. I have even used my printer on the plane at 36000 feet! Since the Jr has been well received, I am excited about considering the design final and converting this design to an absolute minimal plastic version that is even smaller. Both designs, the laser cut AND the RepRap jr. will be completely open source. The idea is to make the jr reprap version the smallest and cheapest to build. Minimalism and simplicity will be key. While I won't be able to scale this design to 12" x 12", I have broken the $200 cost barrier. barely. The Ubis hotend and Printrboard combo we designed is still the most efficient setup out there to my knowledge at 2.5-3.5 amps (peak) at 12 volts amounts to 30-42 Watts. Admittedly, that leaves very little room for a heated build platform.<br />
<br />
'''Printrbot RepRap jr'''<br />
<ul><li>Printrboard electronics</li><br />
<li>Ubis hotend </li><br />
<li>100x100x100 build volume</li><br />
<li>beams instead of rods</li><br />
<li>608 bearings instead of linear bearings</li><br />
<li>rack and pinion instead of belts (perhaps wishful thinking)</li><br />
</ul><br />
<br />
More to come.<br />
-Brook<br />
<br />
== Laser-cut Printrbots ==<br />
The original Printrbot design was created with plastic RP components in mind, but since the project's inception, the creators have moved on to a newer, laser-cut design, presumably optimized for mass manufacture.<br />
Three models now exist, all based upon the laser cut design: the Printrbot LC, the Printrbot Plus, and the Printrbot Jr.<br />
<br />
The Printrbot LC is essentially a re-imagining of the original Printrbot changed to fit the new LC paradigm.<br />
<br />
The Printrbot Plus is a larger version of the Printrbot capable of creating objects up to 8" cubed.<br />
<br />
The Printrbot Jr is a new, experimental version designed to only extrude PLA to make a cost-effective entry level 3D printer. Its build area is 4" cubed.<br />
<br />
== Bill of Materials ==<br />
<br />
Currently, I have a mechanically complete Printrbot and am working on lowering the part count and making the construction even simpler. The bot is being printed on a Makerbot Cupcake, so the parts are small and any machine can print them.<br />
<br />
'''TODO: More detailed BOM with STL for printed parts.''' <br />
<br />
The part count is rather low:<br />
<br />
*18x [http://www.thingiverse.com/thing:16990 Printed Parts] (not including the extruder)<br />
*3x Roller Bearings<br />
*11x Linear Bearings<br />
*1x 2" bolt<br />
*60x Nuts & Bolts<br />
*12x Smooth/Threaded Rods<br />
*4 Nema17 motors (Z axis uses 2)<br />
*PCB Heated print bed (5.5" x 5.5")<br />
<br />
Updates Planed: <br />
*We are seriously looking at going with a bowden extruder.... stay tuned...<br />
*Sanguinololu Electronics (Initially) and a new version of the [[Teensylu]] is planned including 100% surface mount parts and integrated stepper drivers. This will be an assembled board. (Board files at http://github.com/lwalkera/printrboard per http://printrbot.com/home/2012/1/1/the-end-the-beginning.html )<br />
*Hot End: Introducing the NEW "Ubis Hotend" - a super-efficient nichrome wire powered hotend. It can heat at 10 degrees celcius every 5 seconds. This will come assembled in the kit.<br />
<br />
Extruder (Wade's Accessible):<br />
*4x Printed Parts<br />
*3x roller bearings<br />
*1x Hobbed Bolt<br />
*1x very short threaded rod<br />
*a few washers, bolts and nuts to mount it<br />
*1x Nema17 motor<br />
<br />
Total part count (without motors, electronics, hot end): 101 ..... and shrinking.<br />
<br />
== Specifications ==<br />
<br />
'''TODO'''<br />
<br />
* Printed Parts: ???<br />
* Non-Printed Parts: ???<br />
* Material Cost: ???<br />
* Cost: USD 400 - 950 (non assembled)<br />
* Printing Size: <br />
**Printrbot: 150x150x150 - 200x200x200mm (6"x6"x6" - 8"x8"x8")<br />
**Printrbot Jr: 100x100x100mm (4"x4"x4")<br />
* Precision: ??? (position), ??? (printing)<br />
<br />
== Further reading ==<br />
<br />
* [http://www.printrbottalk.com/ Printrbot Talk discussion forum]<br />
* [http://printrbot.dozuki.com/Guide/How-to-Assemble-The-Printrbot/1/1 How to Assemble The Printrbot]<br />
* [http://www.printrbot.com/ Printrbot Storefront]<br />
<br />
== Printed Parts ==<br />
'''WORK IN PROGRESS ADDING .STL THUMBNAILS AND FILE LINKS'''<br />
<gallery><br />
File:PBBASECARD.jpg|Printrbot Base '''(x2)'''|link=http://www.thingiverse.com/download:55666<br />
File:PBXMOTOR.jpg|Printrbot X Motor '''(x1)'''|link=http://www.thingiverse.com/download:55668<br />
<!-- File:PBBASECARD.jpg|Printrbot Base '''(x2)'''|link=http://www.thingiverse.com/download:55666 --><br />
</gallery><br />
<br />
[[Category:Printrbot| ]]</div>Bobchttps://reprap.org/mediawiki/index.php?title=Printrbot&diff=126104Printrbot2014-05-19T18:39:42Z<p>Bobc: </p>
<hr />
<div>{{Languages|Printrbot}}<br />
<br />
{{Development<br />
<!--Header--><br />
|name = Printrbot<br />
|status = working<br />
<!--Image--><br />
|image = Printrbot.jpg<br />
<!--General--><br />
|description = the simplest, cheapest, RepRap 3D printer in the world.<br />
|license = [[Wikipedia:Share-alike|CC-BY-NC-SA]]<br />
|author = abdrumm<br />
|reprap = ???<br />
|categories = {{tag|Printrbot}} {{tag|Foldable RepRap}} [[:Category:Cartesian-XZ-head|XZ-head]] [[Category:Cartesian-XZ-head]] <br />
|cadModel = [http://www.thingiverse.com/thing:16990 THE Printrbot: thing:16990]<br />
|url = http://printrbot.com/<br />
<br />
}}<br />
<br />
<br/><br />
<br />
'''Printrbot''' is the simplest, cheapest, RepRap 3D printer in the world. As of April 2014 there are four versions - Simple, Jr, Plus & Go.<br />
<br />
Happy Printing,<br />
Brook Drumm<br />
<br />
== Project Goal ==<br />
<br />
The overall goal is not to win the [[Gada Prize]] - although I would be proud :), rather, the goal is to offer a printer that kids can put together and operate. My dream is to provide every school with a Printrbot... and that every Printrbot will produce offspring that produces offspring (...etc....) until every home and school has a 3D printer.<br />
<br />
== Overview ==<br />
<br />
'''One 3D Printer Per Home''' is a huge goal. In reality, only some students will even WANT a 3D printer, so that lowers the bar significantly. My short-term goal is to provide Printrbot 3D printers to any school interested-- AT LOW COST, so that the students '''who want them''' can use the school Prinrbot to print the parts to make a Printrbot.... just add electronics, stepper motors, smooth and threaded rod. Through our "Print It Forward" program, we will ask each school to print, assemble and donate a Printrbot to 3 other schools. Although everyone is welcome to source their own parts, Printrbot.com will offer discounts to make this feasible. By relying on schools and Printrbot owners to print 3 other sets of parts to construct a Printrbot, we hope to spread the RepRap love far and wide!<br />
<br />
== Project Description==<br />
<br />
Printrbot is a reality. This is a real 3D printer that prints TODAY. I have designed this printer myself, only using other people's work for optional items. <br />
<br />
The non-original parts used are:<br />
*Your choice of extruder<br />
*2x belt pulleys<br />
*2x Z-couplers<br />
<br />
===Three Designs: Printrbot Original, -Junior and -Senior=== <br />
*The Printrbot is the original design that has a medium sized printbed (6x6x6in/150x150x150mm), and aims at the sweet-spot between practicality and price.<br />
**[http://www.thingiverse.com/thing:16990 Thingiverse: Printrbot], all printable parts<br />
*The Printrbot Junior is the ultra-small, ultra-cheap version that pushes the boundaries of size, cost and simplicity for a 3D printer, to lower the barriers to entry for 3D printing at home. <br />
*The Printrbot Senior (Gada Edition) will be the special version built specifically for the Gada Prize. While I am grateful that the Gada prize is pushing the technology forward, I believe that 3D printers that have lesser specifications (than the Gada Prize rules dictate) will still be greatly useful for families everywhere. <br />
<br />
Note: according to the official [http://humanityplus.org/wp-content/uploads/2011/02/HumanityRepRapGrandPersonalManufacturingPrize.pdf Gada Prize Rules] - I formally am using the "no derivatives for the Gada Prize” clause. I believe the approach I am using is unique and original to my design.<br />
<br />
'''UPDATE: 11-13-2012... the Printrbot jr.'''<br />
The Printrbot Kickstarter completely consumed my life for the last year. Transitioning to a viable business and juggling competing priorities has also been a challenge. I have been completely absent from updates and such. My absence from this wiki, the forums, irc, etc, does not reflect on my passion for RepRap. I have recently finished my Printrbot jr. design in laser cut wood. It is quite small, but grew a bit to make it sturdy, practical and include a folding hinge to collapse it down enough to fit in a backpack and carry on a plane -which I do every time I fly. I have even used my printer on the plane at 36000 feet! Since the Jr has been well received, I am excited about considering the design final and converting this design to an absolute minimal plastic version that is even smaller. Both designs, the laser cut AND the RepRap jr. will be completely open source. The idea is to make the jr reprap version the smallest and cheapest to build. Minimalism and simplicity will be key. While I won't be able to scale this design to 12" x 12", I have broken the $200 cost barrier. barely. The Ubis hotend and Printrboard combo we designed is still the most efficient setup out there to my knowledge at 2.5-3.5 amps (peak) at 12 volts amounts to 30-42 Watts. Admittedly, that leaves very little room for a heated build platform.<br />
<br />
'''Printrbot RepRap jr'''<br />
<ul><li>Printrboard electronics</li><br />
<li>Ubis hotend </li><br />
<li>100x100x100 build volume</li><br />
<li>beams instead of rods</li><br />
<li>608 bearings instead of linear bearings</li><br />
<li>rack and pinion instead of belts (perhaps wishful thinking)</li><br />
</ul><br />
<br />
More to come.<br />
-Brook<br />
<br />
== Laser-cut Printrbots ==<br />
The original Printrbot design was created with plastic RP components in mind, but since the project's inception, the creators have moved on to a newer, laser-cut design, presumably optimized for mass manufacture.<br />
Three models now exist, all based upon the laser cut design: the Printrbot LC, the Printrbot Plus, and the Printrbot Jr.<br />
<br />
The Printrbot LC is essentially a re-imagining of the original Printrbot changed to fit the new LC paradigm.<br />
<br />
The Printrbot Plus is a larger version of the Printrbot capable of creating objects up to 8" cubed.<br />
<br />
The Printrbot Jr is a new, experimental version designed to only extrude PLA to make a cost-effective entry level 3D printer. Its build area is 4" cubed.<br />
<br />
== Bill of Materials ==<br />
<br />
Currently, I have a mechanically complete Printrbot and am working on lowering the part count and making the construction even simpler. The bot is being printed on a Makerbot Cupcake, so the parts are small and any machine can print them.<br />
<br />
'''TODO: More detailed BOM with STL for printed parts.''' <br />
<br />
The part count is rather low:<br />
<br />
*18x [http://www.thingiverse.com/thing:16990 Printed Parts] (not including the extruder)<br />
*3x Roller Bearings<br />
*11x Linear Bearings<br />
*1x 2" bolt<br />
*60x Nuts & Bolts<br />
*12x Smooth/Threaded Rods<br />
*4 Nema17 motors (Z axis uses 2)<br />
*PCB Heated print bed (5.5" x 5.5")<br />
<br />
Updates Planed: <br />
*We are seriously looking at going with a bowden extruder.... stay tuned...<br />
*Sanguinololu Electronics (Initially) and a new version of the [[Teensylu]] is planned including 100% surface mount parts and integrated stepper drivers. This will be an assembled board. (Board files at http://github.com/lwalkera/printrboard per http://printrbot.com/home/2012/1/1/the-end-the-beginning.html )<br />
*Hot End: Introducing the NEW "Ubis Hotend" - a super-efficient nichrome wire powered hotend. It can heat at 10 degrees celcius every 5 seconds. This will come assembled in the kit.<br />
<br />
Extruder (Wade's Accessible):<br />
*4x Printed Parts<br />
*3x roller bearings<br />
*1x Hobbed Bolt<br />
*1x very short threaded rod<br />
*a few washers, bolts and nuts to mount it<br />
*1x Nema17 motor<br />
<br />
Total part count (without motors, electronics, hot end): 101 ..... and shrinking.<br />
<br />
== Specifications ==<br />
<br />
'''TODO'''<br />
<br />
* Printed Parts: ???<br />
* Non-Printed Parts: ???<br />
* Material Cost: ???<br />
* Cost: USD 400 - 950 (non assembled)<br />
* Printing Size: <br />
**Printrbot: 150x150x150 - 200x200x200mm (6"x6"x6" - 8"x8"x8")<br />
**Printrbot Jr: 100x100x100mm (4"x4"x4")<br />
* Precision: ??? (position), ??? (printing)<br />
<br />
== Further reading ==<br />
<br />
* [http://www.printrbottalk.com/ Printrbot Talk discussion forum]<br />
* [http://printrbot.dozuki.com/Guide/How-to-Assemble-The-Printrbot/1/1 How to Assemble The Printrbot]<br />
* [http://www.printrbot.com/ Printrbot Storefront]<br />
<br />
== Printed Parts ==<br />
'''WORK IN PROGRESS ADDING .STL THUMBNAILS AND FILE LINKS'''<br />
<gallery><br />
File:PBBASECARD.jpg|Printrbot Base '''(x2)'''|link=http://www.thingiverse.com/download:55666<br />
File:PBXMOTOR.jpg|Printrbot X Motor '''(x1)'''|link=http://www.thingiverse.com/download:55668<br />
<!-- File:PBBASECARD.jpg|Printrbot Base '''(x2)'''|link=http://www.thingiverse.com/download:55666 --><br />
</gallery><br />
<br />
[[Category:Printrbot| ]]</div>Bobchttps://reprap.org/mediawiki/index.php?title=BitsFromBytes&diff=123976BitsFromBytes2014-04-27T09:05:54Z<p>Bobc: </p>
<hr />
<div><br />
Creators of the [[RapMan]]<br />
<br />
3DSystems acquired BitsFromBytes in 2010, and have since discontinued the entire range of BfB printers, leaving many unhappy users. Although arguably, they were doing them a favour.<br />
<br />
* [http://www.bitsfrombytes.com homepage] - some links still work but many redirect to Cubify.<br />
<br />
[[Category:RapMan]]</div>Bobchttps://reprap.org/mediawiki/index.php?title=Category:RapMan&diff=123973Category:RapMan2014-04-27T08:56:47Z<p>Bobc: </p>
<hr />
<div>The RapMan is a 3D printer which was supplied by BitsFromBytes. It is roughly based on the Darwin design but the RP parts are replaced by acrylic alternative versions.<br />
<br />
For more information, see [http://www.BitsFromBytes.com/ www.BitsFromBytes.com/].<br />
<br />
BitsFromBytes was taken over by 3DSystems and the Rapman line has been discontinued.<br />
<br />
[[Category:Suppliers]]<br />
[[Category:Darwin]]<br />
[[Category:RepStrap]]</div>Bobchttps://reprap.org/mediawiki/index.php?title=G-code&diff=120042G-code2014-03-15T23:45:32Z<p>Bobc: /* M160: Number of mixed materials */</p>
<hr />
<div>{{Languages}}<br />
<br />
This page tries to describe the flavour of G-codes that the RepRap firmwares use and how they work. The main target is additive fabrication using [[FFF]]/FDM processes. Codes for print head movements follow the [http://www.nist.gov/manuscript-publication-search.cfm?pub_id=823374 NIST RS274NGC G-code standard], so RepRap firmwares are quite usable for CNC milling and similar applications, too.<br />
<br />
As many different firmwares exist and their developers tend to implement new features without discussing strategies or looking what others did before them, a lot of different sub-flavours for the 3D-Printer specific codes developed over the years.<br />
<br />
== Introduction ==<br />
<br />
A typical piece of GCode as sent to a RepRap machine might look like this:<br />
<br />
N3 T0*57<br />
N4 G92 E0*67<br />
N5 G28*22<br />
N6 G1 F1500.0*82<br />
N7 G1 X2.0 Y2.0 F3000.0*85<br />
N8 G1 X3.0 Y3.0*33<br />
<br />
The meaning of all those symbols and numbers (and more) is explained below.<br />
<br />
To find out which specific gcode/s are implemented in any given firmware, there are little tables attached to the command descriptions, like this one:<br />
<br />
{| class="wikitable"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| yes || automatic || yes || yes || experimental<br />
|}<br />
Here means:<br />
; yes<br />
: Fully supported.<br />
; experimental<br />
: There is some support. Often it's required to check out a source code branch other than the default or to flip certain configuration switches.<br />
; automatic<br />
: The firmware handles this feature automatically, so there's no need to send the command; you get the feature regardless. An example is power supply on/off (M80/M81) in Teacup firmware.<br />
; no<br />
: The firmware doesn't support this feature.<br />
<br />
For the technically minded, the end of line is marked by a <nl> and optionally a <cr>. So, Unix line endings work as well as Windows ones.<br />
<br />
== RepRap G Code Fields ==<br />
<br />
This section explains the letter-preceded fields. The numbers in the fields are represented by nnn. Numbers can be integers, or can contain a decimal point, depending on context. For example an X coordinate can be integer (X175) or fractional (X17.62), whereas trying to select extruder number 2.76 would make no sense.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Letter<br />
! Meaning<br />
|-<br />
| Gnnn<br />
| Standard GCode command, such as move to a point<br />
|-<br />
| Mnnn<br />
| RepRap-defined command, such as turn on a cooling fan<br />
|-<br />
| Tnnn<br />
| Select tool nnn. In RepRap, tools are extruders<br />
|-<br />
| Snnn<br />
| Command parameter, such as the voltage to send to a motor<br />
|-<br />
| Pnnn<br />
| Command parameter, such as a time in milliseconds<br />
|-<br />
| Xnnn<br />
| An X coordinate, usually to move to<br />
|-<br />
| Ynnn<br />
| A Y coordinate, usually to move to<br />
|-<br />
| Znnn<br />
| A Z coordinate, usually to move to<br />
|-<br />
| Innn<br />
| Parameter - not currently used<br />
|-<br />
| Jnnn<br />
| Parameter - not currently used<br />
|-<br />
| Fnnn<br />
| Feedrate in mm per minute. (Speed of print head movement)<br />
|-<br />
| Rnnn<br />
| Parameter - used for temperatures<br />
|-<br />
| Qnnn<br />
| Parameter - not currently used<br />
|-<br />
| Ennn<br />
| Length of extrudate in mm. This is exactly like X, Y and Z, but for the length of filament to extrude. <s>It is common for newer stepper based systems to interpret ...</s> Better: Skeinforge 40 and up interprets this as the absolute length of input filament to consume, rather than the length of the extruded output.<br />
|-<br />
| Nnnn<br />
| Line number. Used to request repeat transmission in the case of communications errors.<br />
|-<br />
| *nnn<br />
| Checksum. Used to check for communications errors.<br />
|-<br />
|}<br />
<br />
== Comments ==<br />
<br />
G Code comments:<br />
<br />
<pre><br />
N3 T0*57 ;This is a comment<br />
N4 G92 E0*67<br />
; So is this<br />
N5 G28*22<br />
</pre><br />
<br />
Will be ignored by RepRap, as will blank lines. But it's better to strip these out in the host computer before the lines are sent. This saves bandwidth.<br />
<br />
== Individual commands ==<br />
<br />
=== Checking ===<br />
<br />
==== N and * ====<br />
<br />
Example: N123 [...G Code in here...] *71<br />
<br />
These are the line number and the checksum. The RepRap firmware checks the checksum against a locally-computed value and, if they differ, requests a repeat transmission of the line of the given number.<br />
<br />
You can leave both of these out - RepRap will still work, but it won't do checking. You have to have both or neither though.<br />
<br />
The checksum "cs" for a GCode string "cmd" (including its line number) is computed by exor-ing the bytes in the string up to and not including the * character as follows:<br />
<br />
<pre><br />
int cs = 0;<br />
for(i = 0; cmd[i] != '*' && cmd[i] != NULL; i++)<br />
cs = cs ^ cmd[i];<br />
cs &= 0xff; // Defensive programming...<br />
</pre><br />
<br />
and the value is appended as a decimal integer to the command after the * character.<br />
<br />
The RepRap firmware expects line numbers to increase by 1 each line, and if that doesn't happen it is flagged as an error. But you can reset the count using M110 (see below).<br />
<br />
=== Buffered G Commands ===<br />
<br />
The RepRap firmware stores these commands in a ring buffer internally for execution. This means that there is no (appreciable) delay while a command is acknowledged and the next transmitted. In turn, this means that sequences of line segments can be plotted without a dwell between one and the next. As soon as one of these buffered commands is received it is acknowledged and stored locally. If the local buffer is full, then the acknowledgment is delayed until space for storage in the buffer is available. This is how flow control is achieved.<br />
<br />
==== G0: Rapid move ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| ??? || yes || yes || yes || yes<br />
|}<br />
<br />
Example: G0 X12<br />
<br />
In this case move rapidly to X = 12 mm. In fact, the RepRap firmware uses exactly the same code for rapid as it uses for controlled moves (see G1 below), as - for the RepRap machine - this is just as efficient as not doing so. (The distinction comes from some old machine tools that used to move faster if the axes were not driven in a straight line. For them G0 allowed any movement in space to get to the destination as fast as possible.)<br />
<br />
==== G1: Controlled move ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| yes || yes || yes || yes || yes<br />
|}<br />
<br />
Example: G1 X90.6 Y13.8 E22.4<br />
<br />
Go in a straight line from the current (X, Y) point to the point (90.6, 13.8), extruding material as the move happens from the current extruded length to a length of 22.4 mm.<br />
<br />
RepRap does subtle things with feedrates. Thus:<br />
<br />
<pre><br />
G1 F1500<br />
G1 X90.6 Y13.8 E22.4<br />
</pre> <br />
<br />
Will set a feedrate of 1500 mm/minute, then do the move described above at that feedrate. But<br />
<br />
<pre><br />
G1 F1500<br />
G1 X90.6 Y13.8 E22.4 F3000<br />
</pre><br />
<br />
Will set a feedrate of 1500 mm/minute, then do the move described above accelerating to a feedrate of 3000 mm/minute as it does so. The extrusion will accelerate along with the X, Y movement so everything stays synchronized.<br />
<br />
RepRap thus treats feedrate as simply another variable (like X, Y, Z, and E) to be linearly interpolated. This gives complete control over accelerations and decelerations in a way that ensures that everything moves together and the right volume of material is extruded at all points.<br />
<br />
''Note: not every firmware implements this, e.g. the current [[Marlin]] will use the new feedrate from the beginning of the move and not change it.''<br />
<br />
The first example shows how to get a constant-speed movement. The second how to accelerate or decelerate. Thus<br />
<br />
<pre><br />
G1 F1500<br />
G1 X90.6 Y13.8 E22.4 F3000<br />
G1 X80 Y20 E36 F1500<br />
</pre><br />
<br />
Will do the first movement accelerating as before, and the second decelerating from 3000 mm/minute back to 1500 mm/minute.<br />
<br />
To reverse the extruder by a given amount (for example to reduce its internal pressure while it does an in-air movement so that it doesn't dribble) simply use G1 to send an E value that is less than the currently extruded length.<br />
<br />
Some implementations and RepRaps allow the sensing of endstops during moves to be switched on and off. Adding an S field allows this: G1 X300 S1 will move X to 300 checking for an endstop hit and stopping if it happens. G1 X300 S0 will do the same move with no checking. The default is no checking.<br />
<br />
==== G28: Move to Origin ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| yes || yes || yes || yes || yes<br />
|}<br />
<br />
Example: G28<br />
<br />
This causes the RepRap machine to move back to its X, Y and Z zero endstops, a process known as "homing". It does so accelerating, so as to get there fast. But when it arrives it backs off by 1 mm in each direction slowly, then moves back slowly to the stop. This ensures more accurate positioning. <br />
<br />
If you add coordinates, then just the axes with coordinates specified will be zeroed. Thus <br />
<br />
G28 X0 Y72.3<br />
<br />
will zero the X and Y axes, but not Z. The actual coordinate values are ignored.<br />
<br />
==== G29-G32: Bed probing ====<br />
<br />
'''G29''' Detailed Z-Probe<br />
<br />
probes the bed at 3 points.<br />
<br />
'''G30''' Single Z Probe<br />
<br />
In its simplest form probes bed at current XY location. <br />
<br />
Some implementations allow more general behaviour: if a Pn field is specified the probed X, Y, and Z values are saved as point n on the bed for calculating the offset plane. Generally n is 0, 1, or 2. If X, or Y, or Z values are specified (e.g. G30 P1 X20 Y50 Z0.3) then those values are used instead of the machine's current coordinates. A silly Z value (less than -9999.0) causes the machine to probe at the current point to get Z, rather than using the given value. If an S field is specfied (e.g. G30 P1 Z0.3 S) the bed plane is computed for compensation and stored. The combination of these options allows for the machine to be moved to points using G1 commands, and then probe the bed, or for the user to position the nozzle interactively and use those coordinates. The user can also record those values and place them in a setup GCode file for automatic execution.<br />
<br />
'''G31''' Report Current Probe status<br />
<br />
When used on its own this reports whether the Z probe is triggered, or gives the Z probe value in some units if the probe generates height values. If combined with a Z and P field (example: G31 P312 Z0.7) this will set the Z height to 0.7mm when the Z-probe value reaches 312 when a G28 Z0 (zero Z axis) command is sent. The machine will then move a further -0.7mm in Z to place itself at Z = 0. This allows non-contact measuring probes to approach but not touch<br />
the bed, and for the gap left to be allowed for. If the probe is a touch probe and generates a simple 0/1 off/on signal, then G31 Z0.7 will tell the RepRap machine that it is at a height of 0.7mm when the probe is triggered.<br />
<br />
'''G32''' Probe Z and calculate Z plane<br />
<br />
probes the bed at 3 pre-defined points (see M557) and updates transformation matrix for bed leveling compensation.<br />
<br />
=== Unbuffered G commands ===<br />
<br />
The following commands are not buffered. When one is received it is stored, but it is not acknowledged to the host until the buffer is exhausted and then the command has been executed. Thus the host will pause at one of these commands until it has been done. Short pauses between these commands and any that might follow them do not affect the performance of the machine.<br />
<br />
[[Teacup Firmware]] buffers G20, G21, G90 and G91.<br />
<br />
==== G4: Dwell ====<br />
<br />
Example: G4 P200<br />
<br />
In this case sit still doing nothing for 200 milliseconds. During delays the state of the machine (for example the temperatures of its extruders) will still be preserved and controlled.<br />
<br />
==== G10: Head Offset ====<br />
<br />
Example: G10 P3 X17.8 Y-19.3 Z0.0 R140 S205<br />
<br />
This sets the offset for extrude head 3 (from the P3) to the X and Y values specified. You can put a non-zero Z value in as well, but this is usually a bad idea unless the heads are loaded and unloaded by some sort of head changer. When all the heads are in the machine at once they should all be set to the same Z height.<br />
<br />
Remember that any parameter that you don't specify will automatically be set to the last value for that parameter. That usually means that you want explicitly to set Z0.0. <br />
<br />
The R value is the standby temperature in <sup>o</sup>C that will be used for the tool, and the S value is its operating temperature. If you don't want the head to be at a different temperature when not in use, set both values the same. See the T code (select tool) below.<br />
<br />
The [http://www.nist.gov/customcf/get_pdf.cfm?pub_id=823374 NIST G-code standard] mentions an additional L parameter, which is ignored.<br />
<br />
This command is [[Talk:G-code#M104 .26 M109 Deprecation, G10 Introduction | subject to discussion]].<br />
<br />
==== G20: Set Units to Inches ====<br />
<br />
Example: G20<br />
<br />
Units from now on are in inches.<br />
<br />
==== G21: Set Units to Millimeters ====<br />
<br />
Example: G21<br />
<br />
Units from now on are in millimeters. (This is the RepRap default.)<br />
<br />
==== G90: Set to Absolute Positioning ====<br />
<br />
Example: G90<br />
<br />
All coordinates from now on are absolute relative to the origin of the machine. (This is the RepRap default.)<br />
<br />
==== G91: Set to Relative Positioning ====<br />
<br />
Example: G91<br />
<br />
All coordinates from now on are relative to the last position.<br />
<br />
==== G92: Set Position ====<br />
<br />
Example: G92 X10 E90<br />
<br />
Allows programming of absolute zero point, by reseting the current position to the values specified. This would set the machine's X coordinate to 10, and the extrude coordinate to 90. No physical motion will occur.<br />
<br />
A G92 without coordinates will reset all axes to zero.<br />
<br />
=== Unbuffered M and T commands ===<br />
<br />
==== M0: Stop ====<br />
<br />
Example: M0<br />
<br />
The RepRap machine finishes any moves left in its buffer, then shuts down. All motors and heaters are turned off. It can be started again by pressing the reset button on the master microcontroller. See also M1, M112.<br />
<br />
==== M1: Sleep ====<br />
<br />
Example: M1<br />
<br />
The RepRap machine finishes any moves left in its buffer, then shuts down. All motors and heaters are turned off. It can still be sent G and M codes, the first of which will wake it up again. See also M0, M112.<br />
<br />
==== M3: Spindle On, Clockwise (CNC specific)====<br />
<br />
Example: M3 S4000<br />
<br />
The spindle is turned on with a speed of 4000 RPM.<br />
<br />
==== M4: Spindle On, Counter-Clockwise (CNC specific) ====<br />
<br />
Example: M4 S4000<br />
<br />
The spindle is turned on with a speed of 4000 RPM.<br />
<br />
==== M5: Spindle Off (CNC specific) ====<br />
<br />
Example: M5<br />
<br />
The spindle is turned off.<br />
<br />
==== M7: Mist Coolant On (CNC specific) ====<br />
<br />
Example: M7<br />
<br />
Mist coolant is turned on (if available)<br />
<br />
==== M8: Flood Coolant On (CNC specific) ====<br />
<br />
Example: M8<br />
<br />
Flood coolant is turned on (if available)<br />
<br />
==== M9: Coolant Off (CNC specific) ====<br />
<br />
Example: M9<br />
<br />
All coolant systems are turned off.<br />
<br />
==== M10: Vacuum On (CNC specific) ====<br />
<br />
Example: M10<br />
<br />
Dust collection vacuum system turned on.<br />
<br />
==== M11: Vacuum Off (CNC specific) ====<br />
<br />
Example: M11<br />
<br />
Dust collection vacuum system turned off.<br />
<br />
==== M17: Enable/Power all stepper motors====<br />
<br />
Example: M17<br />
<br />
==== M18: Disable all stepper motors====<br />
<br />
Example: M18<br />
<br />
Disables stepper motors and allows axis to move 'freely.'<br />
<br />
==== M20: List SD card ====<br />
<br />
Example: M20<br />
<br />
All files in the root folder of the SD card are listed to the serial port. This results in a line like:<br />
<br />
ok Files: {SQUARE.G,SQCOM.G,}<br />
<br />
The trailing comma is optional. Note that file names are returned in upper case, but - when sent to the M23 command (below) they must be in lower case. This seems to be a function of the SD software. Go figure...<br />
<br />
==== M21: Initialize SD card ====<br />
<br />
Example: M21<br />
<br />
The SD card is initialized. If an SD card is loaded when the machine is switched on, this will happen by default. SD card must be initialized for the other SD functions to work.<br />
<br />
==== M22: Release SD card ====<br />
<br />
Example: M22<br />
<br />
SD card is released and can be physically removed.<br />
<br />
==== M23: Select SD file ====<br />
<br />
Example: M23 filename.gco<br />
<br />
The file specified as filename.gco (8.3 naming convention is supported) is selected ready for printing.<br />
<br />
==== M24: Start/resume SD print ====<br />
<br />
Example: M24<br />
<br />
The machine prints from the file selected with the M23 command.<br />
<br />
==== M25: Pause SD print ====<br />
<br />
Example: M25<br />
<br />
The machine pause printing at the current position within the file selected with the M23 command.<br />
<br />
==== M26: Set SD position ====<br />
<br />
Example: M26<br />
<br />
Set SD position in bytes (M26 S12345).<br />
<br />
==== M27: Report SD print status ====<br />
<br />
Example: M27<br />
<br />
Report SD print status.<br />
<br />
==== M28: Begin write to SD card ====<br />
<br />
Example: M28 filename.gco<br />
<br />
File specified by filename.gco is created (or overwritten if it exists) on the SD card and all subsequent commands sent to the machine are written to that file.<br />
<br />
==== M29: Stop writing to SD card ====<br />
<br />
Example: M29 filename.gco<br />
<br />
File opened by M28 command is closed, and all subsequent commands sent to the machine are executed as normal.<br />
<br />
==== M30: Delete a file on the SD card ====<br />
<br />
Example: M30 filename.gco<br />
<br />
filename.gco is deleted.<br />
<br />
==== M40: Eject ====<br />
<br />
If your RepRap machine can eject the parts it has built off the bed, this command executes the eject cycle. This usually involves cooling the bed and then performing a sequence of movements that remove the printed parts from it. The X, Y and Z position of the machine at the end of this cycle are undefined (though they can be found out using the M114 command, q.v.).<br />
<br />
See also M240 and M241 below.<br />
<br />
==== M41: Loop ====<br />
<br />
Example: M41<br />
<br />
If the RepRap machine was building a file from its own memory such as a local SD card (as opposed to a file being transmitted to it from a host computer) this goes back to the beginning of the file and runs it again. So, for example, if your RepRap is capable of ejecting parts from its build bed then you can set it printing in a loop and it will run and run. Use with caution - the only things that will stop it are:<br />
<br />
# When you press the reset button,<br />
# When the build material runs out (if your RepRap is set up to detect this), and<br />
# When there's an error (such as a heater failure).<br />
<br />
==== M42: Stop on material exhausted / Switch I/O pin ====<br />
<br />
===== M42 in ??? =====<br />
<br />
Example: M42<br />
<br />
If your RepRap can detect when its material runs out, this decides the behaviour when that happens. The X and Y axes are zeroed (but not Z), and then the machine shuts all motors and heaters off. You have to press reset to reactivate the machine. In other words, it parks itself and then executes an M0 command (q.v.).<br />
<br />
===== M42 in Marlin/Sprinter =====<br />
<br />
Example: M42 P7 S255<br />
<br />
M42 switches a general purpose I/O pin.<br />
<br />
===== M42 in Teacup =====<br />
<br />
Not needed. General purpose devices are handled like a heater, see [[#M104: Set Extruder Temperature | M104]].<br />
<br />
==== M43: Stand by on material exhausted ====<br />
<br />
Example: M43<br />
<br />
If your RepRap can detect when its material runs out, this decides the behaviour when that happens. The X and Y axes are zeroed (but not Z), and then the machine shuts all motors and heaters off except the heated bed, the temperature of which is maintained. The machine will still respond to G and M code commands in this state.<br />
<br />
==== M80: ATX Power On ====<br />
<br />
Example: M80<br />
<br />
Turns on the ATX power supply from standby mode to fully operational mode. No-op on electronics without standby mode.<br />
<br />
'''Note''': some firmwares, like [[Teacup Firmware | Teacup]], handle power on/off automatically, so this is redundant there. Also, see [http://forums.reprap.org/read.php?219,132664 RAMPS wiring for ATX on/off]<br />
<br />
==== M81: ATX Power Off ====<br />
<br />
Example: M81<br />
<br />
Turns off the ATX power supply. Counterpart to M80.<br />
<br />
==== M82: set extruder to absolute mode ====<br />
<br />
Example: M82<br />
<br />
makes the extruder interpret extrusion as absolute positions.<br />
<br />
This is the default in repetier.<br />
<br />
==== M83: set extruder to relative mode ====<br />
<br />
Example: M83<br />
<br />
makes the extruder interpret extrusion values as relative positions.<br />
<br />
==== M84: Stop idle hold ====<br />
<br />
Example: M84<br />
<br />
Stop the idle hold on all axis and extruder. In some cases the idle hold causes annoying noises, which can be stopped by disabling the hold. Be aware that by disabling idle hold during printing, you will get quality issues. This is recommended only in between or after printjobs.<br />
<br />
==== M92: Set axis_steps_per_unit ====<br />
<br />
Example: M92 X<newsteps> Sprinter and Marlin<br />
<br />
Allows programming of steps per unit of axis till the electronics are reset for the specified axis. Very useful for calibration.<br />
<br />
==== M98: Call Macro/Subprogram ====<br />
<br />
Example: M98 Pmymacro.g<br />
<br />
Runs the macro in the file mymacro.g. In conventional G Codes for CNC machines the P parameter normally refers to a line number in the program itself (P2000 would run the Macro starting at line O2000, say). For RepRap, which almost always has some sort of mass storage device inbuilt, it simply refers to the name of a GCode file that is executed by the G98 call. That GCode file does not need to end with an M99 (return) as the end-of-file automatically causes a return. It is usually a good idea to start a macro with an M120 (Push) instruction and to end it with an M121 (Pop) instruction, q.v. Macro calls cannot usually be nested or be recursive; i.e. you can't call a macro from a macro (though some implementations may allow this).<br />
<br />
==== M99: Return from Macro/Subprogram ====<br />
<br />
Example: M99<br />
<br />
Returns from an M98 call.<br />
<br />
<br />
==== M98: Get axis_hysteresis_mm ==== <br />
<br />
'''Deprecated - clashes with the G Code standard M98 above''' <br />
<br />
Example: M98 <br />
<br />
Report the current hysteresis values in mm for all of the axis.<br />
<br />
Proposed for Marlin<br />
<br />
==== M99: Set axis_hysteresis_mm ====<br />
<br />
'''Deprecated - clashes with the G Code standard M99 above'''<br />
<br />
Example: M99 X<mm> Y<mm> Z<mm> E<mm> <br />
<br />
Allows programming of axis hysteresis. Mechanical pulleys, gears and threads can have hysteresis when they change direction. That is, a certain number of steps occur before movement occurs. You can measure how many mm are lost to hysteresis and set their values with this command. Every time an axis changes direction, these extra mm will be added to compensate for the hysteresis.<br />
<br />
Proposed for Marlin<br />
<br />
==== M101 Turn extruder 1 on Forward / Undo Extruder Retraction ====<br />
<br />
===== M101 in Teacup firmware =====<br />
<br />
If a DC extruder is present, turn that on. Else, undo filament retraction, which means, make the extruder ready for extrusion. Complement to M103.<br />
<br />
===== M101 in other firmwares =====<br />
<br />
Deprecated. Regarding filament retraction, see M227, M228, M229.<br />
<br />
==== M102 Turn extruder 1 on Reverse ====<br />
<br />
Deprecated.<br />
<br />
==== M103 Turn all extruders off / Extruder Retraction ====<br />
<br />
===== M103 in Teacup firmware =====<br />
<br />
If a DC extruder is present, turn that off. Else, retract the filament in the hope to prevent nozzle drooling. Complement to M101.<br />
<br />
===== M103 in other firmwares =====<br />
<br />
Deprecated. Regarding extruder retraction, see M227, M228, M229.<br />
<br />
==== M104: Set Extruder Temperature ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| yes || yes || yes || yes || yes<br />
|}<br />
<br />
Example: M104 S190<br />
<br />
Set the temperature of the current extruder to 190<sup>o</sup>C and return control to the host immediately (''i.e.'' before that temperature has been reached by the extruder). See also M109.<br />
<br />
This is deprecated because temperatures should be set using the G10 and T commands (q.v.).<br />
<br />
Deprecation is [[Talk:G-code#M104 .26 M109 Deprecation, G10 Introduction | subject to discussion]]. --[[User:Traumflug|Traumflug]] 11:33, 19 July 2012 (UTC)<br />
<br />
===== M104 in Teacup Firmware =====<br />
<br />
In Teacup Firmware, M104 can be additionally used to handle all devices using a temperature sensor. It supports the additional P parameter, which is a zero-based index into the list of sensors in config.h. For devices without a temp sensor, see [[#M106: Fan On | M106]].<br />
<br />
Example: M104 P1 S100<br />
<br />
Set the temperature of the device attached to the second temperature sensor to 100&nbsp;°C.<br />
<br />
==== M105: Get Extruder Temperature ====<br />
<br />
Example: M105<br />
<br />
Request the temperature of the current extruder and the build base in degrees Celsius. The temperatures are returned to the host computer. For example, the line sent to the host in response to this command looks like:<br />
<tt>ok T:201 B:117</tt><br />
<br />
Expansion/generalization of M105 to be considered as noted in [[Pronterface I/O Monitor]]<br />
<br />
==== M106: Fan On ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || yes || yes || yes ||<br />
|}<br />
<br />
Example: M106 S127<br />
<br />
Turn on the cooling fan at half speed.<br />
<br />
Mandatory parameter 'S' declares the PWM value (0-255). M106 S0 turns the fan off. In some implementations the pwm is specified by a real fraction: M106 S0.7.<br />
<br />
===== M106 in Teacup Firmware =====<br />
<br />
Additionally to the above, Teacup Firmware uses M106 to control general devices. It supports the additional P parameter, which is an zero-based index into the list of heaters/devices in config.h.<br />
<br />
Example: M106 P2 S255<br />
<br />
Turn on device #3 at full speed/wattage.<br />
<br />
'''Note''': When turning on a temperature sensor equipped heater with M106 and M104 at the same time, temperature control will override the value given in M106 quickly.<br />
<br />
==== M107: Fan Off ====<br />
<br />
Deprecated. Use M106 S0 instead.<br />
<br />
==== M108: Set Extruder Speed ====<br />
<br />
Sets speed of extruder motor.<br />
(Deprecated in current firmware, see M113)<br />
<br />
==== M109: Set Extruder Temperature and Wait ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| ??? || not needed || see text || yes || ???<br />
|}<br />
<br />
===== M109 in Teacup =====<br />
<br />
Not needed. To mimic Marlin behaviour, use [[#M104: Set Extruder Temperature | M104]] followed by [[#M116: Wait | M116]].<br />
<br />
===== M109 in Marlin, Sprinter (ATmega port) =====<br />
<br />
Set extruder heater temperature in degrees celsius and wait for this temperature to be achieved.<br />
<br />
Example: M109 S185<br />
<br />
===== M109 in Sprinter (4pi port) =====<br />
<br />
Parameters: '''S''' (optional), set target temperature value. If not specified, waits for the temperature set by [[#M104: Set Extruder Temperature | M104]]. '''R''' (optional), sets target temperature range maximum value.<br />
<br />
Example: M109 S185 R240 //sets extruder temperature to 185 and waits for the temperature to be between 185 - 240.<br />
<br />
If you have multiple extruders, use '''T''' or '''P''' parameter to specify which extruder you want to set/wait.<br />
<br />
Another way to do this is to use [[#G10: Head Offset | G10]].<br />
<br />
==== M110: Set Current Line Number ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| ??? || not needed || ??? || ??? || ???<br />
|}<br />
<br />
Example: M110 N123<br />
<br />
Set the current line number to 123. Thus the expected next line after this command will be 124.<br />
<br style="clear: both" /><br />
<br />
==== M111: Set Debug Level ====<br />
<br />
Example: M111 S6<br />
<br />
Set the level of debugging information transmitted back to the host to level 6. The level is the OR of three bits:<br />
<br />
<Pre><br />
#define DEBUG_ECHO (1<<0)<br />
#define DEBUG_INFO (1<<1)<br />
#define DEBUG_ERRORS (1<<2)<br />
</pre><br />
<br />
Thus 6 means send information and errors, but don't echo commands. (This is the RepRap default.)<br />
<br />
<br />
Example: M253 <br />
<br />
{| class="wikitable"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || Debug || || || <br />
|}<br />
<br />
<br />
==== M112: Emergency Stop ====<br />
<br />
Example: M112<br />
<br />
Any moves in progress are immediately terminated, then RepRap shuts down. All motors and heaters are turned off. It can be started again by pressing the reset button on the master microcontroller. See also M0 and M1.<br />
<br />
==== M113: Set Extruder PWM ====<br />
<br />
Example: M113<br />
<br />
Set the PWM for the currently-selected extruder. On its own this command <br />
sets RepRap to use the on-board potentiometer on the extruder controller board to set the PWM for the currently-selected extruder's stepper power. With an S field:<br />
<br />
M113 S0.7<br />
<br />
it causes the PWM to be set to the S value (70% in this instance). M113 S0 turns the extruder off, until an M113 command other than M113 S0 is sent.<br />
<br />
==== M114: Get Current Position ====<br />
<br />
Example: M114<br />
<br />
This causes the RepRap machine to report its current X, Y, Z and E coordinates to the host.<br />
<br />
For example, the machine returns a string such as:<br />
<br />
<tt>ok C: X:0.00 Y:0.00 Z:0.00 E:0.00</tt><br />
<br />
In Marlin first 3 numbers is the position for the planner. The other positions are the positions from the stepper function. This helps for debugging a previous stepper function bug. <br />
<br />
<tt>X:0.00 Y:0.00 RZ:0.00 LZ:0.00 Count X:0.00 Y:0.00 RZ:41.02 LZ:41.02</tt><br />
<br />
==== M115: Get Firmware Version and Capabilities ====<br />
<br />
Example: M115<br />
<br />
Request the Firmware Version and Capabilities of the current microcontroller <br />
The details are returned to the host computer as key:value pairs separated by spaces and terminated with a linefeed.<br />
<br />
sample data from firmware:<br />
ok PROTOCOL_VERSION:0.1 FIRMWARE_NAME:FiveD FIRMWARE_URL:http%3A//reprap.org MACHINE_TYPE:Mendel EXTRUDER_COUNT:1<br />
<br />
This M115 code is inconsistently implemented, and should not be relied upon to exist, or output correctly in all cases. An initial implementation was committed to svn for the FiveD Reprap firmware on 11 Oct 2010. Work to more formally define protocol versions is currently (October 2010) being discussed. See [[M115_Keywords]] for one draft set of keywords and their meanings.<br />
<br />
==== M116: Wait ====<br />
<br />
Example: M116<br />
<br />
Wait for ''all'' temperatures and other slowly-changing variables to arrive at their set values. See also M109.<br />
<br />
==== M117: Get Zero Position ====<br />
<br />
Example: M117<br />
<br />
This causes the RepRap machine to report the X, Y, Z and E coordinates ''in steps not mm'' to the host that it found when it last hit the zero stops for those axes. That is to say, when you zero X, the <i>x</i> coordinate of the machine when it hits the X endstop is recorded. This value should be 0, of course. But if the machine has drifted (for example by dropping steps) then it won't be. This command allows you to measure and to diagnose such problems. (E is included for completeness. It doesn't normally have an endstop.)<br />
<br />
==== M117 in Marlin: Display Message ====<br />
<br />
Example: M117 Hello World<br />
<br />
This causes the given message to be shown in the status line on an attached LCD. The above command will display Hello World. <br />
<br />
==== M118: Negotiate Features ====<br />
<br />
Example: M118 P42<br />
<br />
This M-code is for future proofing. NO firmware or hostware supports this at the moment. It is used in conjunction with M115's FEATURES keyword.<br />
<br />
See [[Protocol_Feature_Negotiation]] for more info.<br />
<br />
==== M119: Get Endstop Status ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || yes || || yes || yes<br />
|}<br />
<br />
Example: M119<br />
<br />
Returns the current state of the configured X, Y, Z endstops. Takes into account any 'inverted endstop' settings, so one can confirm that the machine is interpreting the endstops correctly.<br />
<br />
==== M120: Push ====<br />
<br />
Push the state of the RepRap machine onto a stack. Exactly what variables get pushed depends on the implementation (as does the depth of the stack - a typical depth might be 5). A sensible minimum, however, might be <br />
<br />
# Current feedrate, and<br />
# Whether moves (and separately extrusion) are relative or absolute<br />
<br />
==== M121: Pop ====<br />
<br />
Recover the last state pushed onto the stack.<br />
<br />
==== M122: Diagnose ====<br />
<br />
Sending an M122 causes the RepRap to transmit diagnostic information, for eaxmple via a USB serial link.<br />
<br />
==== M126: Open Valve ====<br />
<br />
Example: M126 P500<br />
<br />
Open the extruder's valve (if it has one) and wait 500 milliseconds for it to do so.<br />
<br />
==== M127: Close Valve ====<br />
<br />
Example: M127 P400<br />
<br />
Close the extruder's valve (if it has one) and wait 400 milliseconds for it to do so.<br />
<br />
==== M128: Extruder Pressure PWM ====<br />
<br />
Example: M128 S255<br />
<br />
PWM value to control internal extruder pressure. S255 is full pressure.<br />
<br />
==== M129: Extruder pressure off ====<br />
<br />
Example: M129 P100<br />
<br />
In addition to setting Extruder pressure to 0, you can turn the pressure off entirely. P400 will wait 100ms to do so.<br />
<br />
==== M130: Set PID P value ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || yes || || || <br />
|}<br />
<br />
Example: M130 P 0 S 8.0 # Sets heater 0 P factor to 8.0<br />
<br style="clear: both" /><br />
<br />
==== M131: Set PID I value ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || yes || || || <br />
|}<br />
<br />
Example: M130 P 1 S 0.5 # Sets heater 1 I factor to 0.5<br />
<br style="clear: both" /><br />
<br />
==== M132: Set PID D value ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || yes || || || <br />
|}<br />
<br />
Example: M130 P 0 S 24 # Sets heater 0 D factor to 24.0<br />
<br />
<br style="clear: both" /><br />
<br />
==== M133: Set PID I limit value ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || yes || || || <br />
|}<br />
<br />
Example: M130 P 1 S 264 # Sets heater 0 I limit value to 264<br />
<br />
<br style="clear: both" /><br />
<br />
==== M134: Write PID values to EEPROM ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || yes || || || <br />
|}<br />
<br />
Example: M134 <br />
<br style="clear: both" /><br />
<br />
<br />
==== M135: Set PID sample interval ====<br />
<br />
Example: M135 S300<br />
<br />
Set the PID to measure temperatures and calculate the power to send to the heaters every 300ms.<br />
<br />
==== M136: Print PID settings to host ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || Debug || || || <br />
|}<br />
<br />
Example: M136 P1 # print heater 0 PID parameters to host<br />
<br style="clear: both" /><br />
<br />
==== M140: Bed Temperature (Fast) ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || yes || yes || yes || yes<br />
|}<br />
<br />
Example: M140 S55<br />
<br />
Set the temperature of the build bed to 55<sup>o</sup>C and return control to the host immediately (''i.e.'' before that temperature has been reached by the bed).<br />
<br />
==== M141: Chamber Temperature (Fast) ====<br />
<br />
Example: M141 S30<br />
<br />
Set the temperature of the chamber to 30<sup>o</sup>C and return control to the host immediately (''i.e.'' before that temperature has been reached by the chamber).<br />
<br />
==== M142: Holding Pressure ====<br />
<br />
Example: M142 S1<br />
<br />
Set the holding pressure of the bed to 1 bar.<br />
<br />
The holding pressure is in bar. For hardware which only has on/off holding, when the holding pressure is zero, turn off holding, when the holding pressure is greater than zero, turn on holding.<br />
<br />
==== M143: Maximum hot-end temperature ====<br />
<br />
Example: M143 S275<br />
<br />
Set the maximum temperature of the hot-end to 275C<br />
<br />
When temperature of the hot-end exceeds this value, take countermeasures, for instance an emergency stop. This is to prevent hot-end damage.<br />
<br />
==== M160: Number of mixed materials ====<br />
<br />
Example: M160 S4<br />
<br />
Set the number of materials, N, that the current extruder can handle to the number specified. The default is 1.<br />
<br />
When N >= 2, then the E field that controls extrusion requires N values separated by colons ":" after it like this: <br />
<br />
<pre><br />
M160 S4<br />
G1 X90.6 Y13.8 E2.24:2.24:2.24:15.89<br />
G1 X70.6 E0:0:0:42.4<br />
G1 E42.4:0:0:0<br />
</pre><br />
<br />
The second line moves straight to the point (90.6, 13.8) extruding a total of 22.4mm of filament. The mix ratio for the move is 0.1:0.1:0.1:0.7.<br />
<br />
The third line moves back 20mm in X extruding 42.4mm of filament. <br />
<br />
The fourth line has no physical effect.<br />
<br />
==== M190: Wait for bed temperature to reach target temp ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || obsolete, see M116 || yes || yes || <br />
|}<br />
<br />
Example: M190 S60<br />
<br />
This will wait until the bed temperature reaches 60 degrees, printing out the temperature of the hot end and the bed every second.<br />
<br style="clear: both" /><br />
<br />
==== M200 - Set filament diameter / Get Endstop Status ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || || || yes || <br />
|}<br />
<br />
M200 sets the filament diameter.<br />
<br />
Question: what does a firmware do with filament diameter? Has this an effect on how much an E command moves the extruder motor? --[[User:Traumflug|Traumflug]] 11:34, 14 October 2012 (UTC)<br />
<br />
==== M201 - Set max printing acceleration ====<br />
<br />
in units/s^2 for print moves (M201 X1000 Y1000)<br />
<br />
==== M202 - Set max travel acceleration ====<br />
<br />
in units/s^2 for travel moves (M202 X1000 Y1000) Unused in Marlin!!<br />
<br />
==== M203 - Set maximum feedrate ====<br />
<br />
that your machine can sustain (M203 X200 Y200 Z300 E10000) in mm/sec<br />
<br />
Note: this should be in units/minute, just like the F code.<br />
<br />
==== M204 - Set default acceleration ====<br />
<br />
S normal moves T filament only moves (M204 S3000 T7000) im mm/sec^2 also sets minimum segment time in ms (B20000) to prevent buffer underruns and M20 minimum feedrate<br />
<br />
==== M205 - advanced settings ====<br />
<br />
minimum travel speed S=while printing T=travel only, B=minimum segment time X= maximum xy jerk, Z=maximum Z jerk, E=maximum E jerk<br />
<br />
==== M206: set home offset ====<br />
<br />
Example: M206 X10.0 Y10.0 Z-0.4<br />
<br />
The values specified are added to the endstop position when the axes are referenced. The same can be achieved with a G92 right after homing (G28, G161).<br />
<br />
With Marlin firmware, this value can be saved to EEPROM using the M500 command.<br />
<br />
A similar command is G10, aligning these two is [[Talk:G-code#M104 .26 M109 Deprecation, G10 Introduction | subject to discussion]].<br />
<br />
==== M207: calibrate z axis by detecting z max length ====<br />
<br />
Example: M207<br />
<br />
After placing the tip of the nozzle in the position you expect to be considered Z=0, issue this command to calibrate the Z axis. It will perform a z axis homing routine and calculate the distance traveled in this process. The result is stored in EEPROM as z_max_length. For using this calibration method the machine must be using a Z MAX endstop.<br />
<br />
This procedure is usually more reliable than mechanical adjustments of a Z MIN endstop.<br />
<br />
==== M208: set axis max travel ====<br />
<br />
Example: M208 X250 Y210 Z180<br />
<br />
The values specified set the software limits for axis travel in the positive direction.<br />
<br />
With Marlin firmware, this value can be saved to EEPROM using the M500 command.<br />
<br />
<br />
==== M209: enable automatic retract ====<br />
<br />
Example: M209 S1<br />
<br />
This boolean value S 1=true or 0=false enables automatic retract detect if the slicer did not support G10/11: every normal extrude-only move will be classified as retract depending on the direction.<br />
<br />
==== M210: Set homing feedrates ====<br />
<br />
Example: M210 X1000 Y1500<br />
<br />
Set the feedrates used for homing to the values specified in mm per minute.<br />
<br />
==== M220:set speed factor override percentage ====<br />
<br />
Example: M220 S80<br />
<br />
S<factor in percent>- set speed factor override percentage<br />
<br />
==== M221: set extrude factor override percentage ====<br />
<br />
Example: M221 S70<br />
<br />
S<factor in percent>- set extrude factor override percentage<br />
<br />
==== M226: Gcode Initiated Pause ====<br />
<br />
Example: M226<br />
<br />
Initiates a pause in the same way as if the pause button is pressed. That is, program execution is stopped and the printer waits for user interaction. This matches the behaviour of M1 in the [http://www.nist.gov/manuscript-publication-search.cfm?pub_id=823374 NIST RS274NGC G-code standard] and M0 in Marlin firmware.<br />
<br />
==== M227: Enable Automatic Reverse and Prime ====<br />
<br />
Example: M227 P1600 S1600<br />
<br />
P and S are steps.<br />
<br />
"Reverse and Prime" means, the extruder filament is retracted some distance when not in use and pushed forward the same amount before going into use again. This shall help to prevent drooling of the extruder nozzle. Teacup firmware implements this with M101/M103.<br />
<br />
==== M228: Disable Automatic Reverse and Prime ====<br />
<br />
Example: M228<br />
<br />
See also M227.<br />
<br />
==== M229: Enable Automatic Reverse and Prime ====<br />
<br />
Example: M229 P1.0 S1.0<br />
<br />
P and S are extruder screw rotations. See also M227.<br />
<br />
==== M230: Disable / Enable Wait for Temperature Change ====<br />
<br />
Example: M230 S1<br />
<br />
S1 Disable wait for temperature change<br />
S0 Enable wait for temperature change<br />
<br />
<br />
==== M240: Start conveyor belt motor / Echo off ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || Debug: Echo off|| || || <br />
|}<br />
<br />
Example: M240<br />
<br />
The conveyor belt allows to start mass production of a part with a reprap. <br />
<br />
Echoing may be controlled in some firmwares with M111<br />
<br style="clear: both" /><br />
<br />
==== M241: Stop conveyor belt motor / echo on ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || Debug: Echo on|| || || <br />
|}<br />
<br />
Example: M241<br />
<br />
Echoing may be controlled in some firmwares with M111<br />
<br style="clear: both" /><br />
<br />
==== M245: Start cooler ====<br />
<br />
Example: M245<br />
<br />
used to cool parts/heated-bed down after printing for easy remove of the parts after print<br />
<br />
==== M246: Stop cooler ====<br />
<br />
Example: M246<br />
<br />
==== M280: Set servo position ====<br />
<br />
M280 - set servo position absolute. P: servo index, S: angle or microseconds (Marlin)<br />
<br />
==== M300: Play beep sound ====<br />
<br />
Usage: M300 S<frequency Hz> P<duration ms><br />
<br />
Example: M300 S300 P1000<br />
<br />
Play beep sound, use to notify important events like the end of printing. [http://www.3dprinting-r2c2.com/?q=content/seasons-greetings See working example on] [[R2C2_RepRap_Electronics|R2C2 electronics]].<br />
<br />
==== M301: Set PID parameters - Hot End ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || || || PID || <br />
|}<br />
Example: M301 P1 I2 D3 C5<br />
<br />
Sets Proportional, Integral and Derivative values for hot end, the value C refers to an extrusion rate.<br />
<br />
Alternate implementation<br />
<br />
Example: M301 W125<br />
<br />
==== M302: Allow cold extrudes ====<br />
This tells the printer to allow movement of the extruder motor, when the hotend is not at printing temperature<br />
<br />
<br />
Example: M302<br />
<br />
==== M303: Run PID tuning ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || || || PID || PID <br />
|}<br />
Hotend Usage: M303 S<temperature> C<cycles><br />
Bed Usage: M303 E-1 C<cycles> S<temperature> <br />
Example: M303 C8 S175<br />
<br />
Generate Proportional, Integral and Derivative values for the hotend or bed (E-1). Send the appropriate code and wait for the output to update the firmware.<br />
<br />
<br />
<br />
==== M304: Set PID parameters - Bed====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || || || PID || <br />
|}<br />
Example: M304 P1 I2 D3<br />
<br />
Sets Proportional, Integral and Derivative values for bed<br />
<br />
==== M400: Wait for current moves to finish ====<br />
<br />
Finishes all current moves and and thus clears the buffer. That's identical to <code>G4 P0</code>.<br />
<br />
Example: M400<br />
<br />
==== M420: Set RGB Colors as PWM ====<br />
<br />
Usage: M420 R<Red PWM (0-255)> E<Green PWM (0-255)> B<Blue PWM (0-255)><br />
<br />
Example: M420 R255 E255 B255<br />
<br />
Set the color of your RGB LEDs that are connected to PWM-enabled pins. Note, the Green color is controlled by the E value instead of the G value due to the G code being a primary code that cannot be overridden.<br />
<br />
<br />
==== M550: Set Name ====<br />
<br />
Example: M550 PGodzilla<br />
<br />
Sets the name of the RepRap to (in this case) Godzilla. The name can be any string of printable characters except ';', which still means start comment.<br />
<br />
==== M551: Set Password ====<br />
<br />
Example: M551 Pmy-very-secret-word<br />
<br />
On machines that need a password to activate them, set that password. The code 'P' is not part of the password. Note that as this is sent in clear it does not (nor is it intended to) offer a very high level of security. But on machines that are (say) on a network, it prevents idle messing about by the unauthorised. The password can contain any printable charcters except ';', which still means start comment.<br />
<br />
==== M552: Set IP address ====<br />
<br />
Example: M552 P192.168.1.14<br />
<br />
Sets the IP address of the RepRap machine to (in this case) 192.168.1.14. If no P field is specified, this echos the existing IP address.<br />
<br />
<br />
==== M553: Set Netmask ====<br />
<br />
Example: M553 P255.255.255.0<br />
<br />
Sets the IP address of the RepRap machine to (in this case) 255.255.255.0. If no P field is specified, this echos the existing Netmask.<br />
<br />
<br />
==== M554: Set Gateway ====<br />
<br />
Example: M554 P192.168.1.1<br />
<br />
Sets the Gateway of the RepRap machine to (in this case) 192.168.1.1. If no P field is specified, this echos the existing Gateway.<br />
<br />
==== M555: Set compatibility ====<br />
<br />
Example: M555 P1<br />
<br />
For firmware that can do it, sets the firmware to a mode where its input and (especially) output behaves exactly like other established firmware. The value of the P argument is:<br />
<br />
{| class="wikitable"<br />
|P value || Firmware <br />
|-<br />
|0 || Native (i.e. whatever the firmware actually is)<br />
|-<br />
| 1 || [[RepRap_Firmware]]<br />
|-<br />
| 2 || [[Marlin]]<br />
|-<br />
| 3 || [[Teacup]]<br />
|-<br />
| 4 || [[Sprinter]]<br />
|-<br />
| 5 || [[Repetier]]<br />
|}<br />
<br />
==== M556: Axis compensation ====<br />
<br />
Example: M556 S100 X0.7 Y-0.2 Z0.6<br />
<br />
Though with care and adjustment a RepRap can be set up with its axes at right-angles to each other within the accuracy of the machine, who wants to bother with care and adjustment when the problem<br />
can be solved by software? This tells software the tangents of the angles between the axes of the machine obtained by printing then measuring a test part. The S parameter (100 here) is the length of a triangle along each axis in mm. The X, Y and Z figures are the number of millimeters of the short side of the triangle that represents how out of true a pair of axes is. The X figure is the error between X and Y, the Y figure is the error between Y and Z, and the Z figure is the error between X and Z. Positive values indicate that the angle between the axis pair is obtuse, negative acute.<br />
<br />
==== M557: Set Z probe point ====<br />
<br />
Example: M557 P1 X30 Y40.5<br />
<br />
Set the points at which the bed will be probed to compensate for its plane being slightly out of horizontal. The P value is the index of the point (indices start at 0) and the X and Y values are the position to move extruder 0 to to probe the bed. An implementation should allow a minimum of three points (P0, P1 and P2). This just records the point coordinates; it does not actually do the probing. See G32.<br />
<br />
==== M558: Set Z probe type ====<br />
<br />
Example: M558 P0<br />
<br />
A Z probe may be a switch (the default) an IR proximity sensor, or some other device. This selects which to use. P0 gives a switch. P1 gives an IR probe. See also G31 and G32.<br />
<br />
==== M559: Upload configuration file ====<br />
<br />
Example: M559<br />
<br />
If the RepRap supports it, this uploads a file that is run on re-boot to configure the machine. This file usually is a special G Code file. After sending M559, the file should be sent, ending with an M29 (q.v.).<br />
<br />
==== M560: Upload web page file ====<br />
<br />
Example: M560<br />
<br />
For RepRaps that have web support and that can be driven by a web browser, this uploads the file that is the control page for the RepRap. After sending M560 the file (usually an HTML file) should be sent, terminated by the string <pre><!-- **EoF** --></pre>. Clearly that string cannot exist in the body of the file, but can be put on the end to facilitate this process. This should not be too serious a restriction...<br />
<br />
<br />
==== M561: Set Identity Transform ====<br />
<br />
Example: M561<br />
<br />
This cancels any bed-plane fitting as the result of probing (or anything else) and returns the machine to moving in the user's coordinate system.<br />
<br />
==== M562: Reset temperature fault ====<br />
<br />
Example: M562 P2<br />
<br />
Reset a temperature fault on heater/sensor 2. If the RepRap has switched off and locked a heater because it has detected a fault, this will reset the fault condition and allow you to use the heater again. Obviously to be used with caution. If the fault persists it will lock out again after you have issued this command. P0 is the bed; P1 the first extruder, and so on.<br />
<br />
==== M906: Set motor currents ====<br />
<br />
Example: M906 X300 Y500 Z200 E350<br />
<br />
Sets the currents to send to the stepper motors for each axis. The values are in milliamps.<br />
<br />
==== M998: Request resend of line ====<br />
<br />
Example: M998 P34<br />
<br />
Request a resend of line 34. In some implementations the input-handling code overwrites the incomming G Code with this when it detects, for example, a checksum error.<br />
Then it leaves it up to the GCode interpreter actually to request the resend.<br />
<br />
==== M999: Restart after being stopped by error ====<br />
<br />
Example: M999<br />
<br />
==== T: Select Tool ====<br />
<br />
Example: T1<br />
<br />
Select extruder number 1 to build with. <br />
<br />
The sequence followed is:<br />
<br />
# Set the current extruder to its standby temperature specified by G10 (see above),<br />
# Set the new extruder to its operating temperature specified by G10 and wait for '''all''' temperatures to stabilise,<br />
# Apply any X, Y, Z offset for the new extruder specified by G10,<br />
# Use the new extruder.<br />
<br />
Selecting a non-existent tool (100, say) just does Step 1. above. That is to say it leaves all tools in their standby state. You can, of course, use the G10 command beforehand to set that standby temperature to anything you like.<br />
<br />
Note that you may wish to move to a parking position ''before'' executing a T command in order to allow the new extruder to reach temperature while not in contact with the print. It is acceptable for the firmware to apply a small offset [by convention (-1mm x tool-number) in Y] to the current position when the above sequence is entered to allow temperature changes to take effect just away from the parking position. Any such offset must, of course, be undone when the procedure finishes.<br />
<br />
If the Z value changes in the offsets and the head moves up, then the Z move is made before the X and Y moves. If Z moves down, X and Y are done first.<br />
<br />
After a reset extruders will not start heating until they are selected. You can either put them all at their standby temperature by selecting them in turn, or leave them off so they only come on if/when you first use them. The M0, M1 and M112 commands turn them all off. You can, of course, turn them all off with the M1 command, then turn some back on again. Don't forget also to turn on the heated bed (if any) if you use that trick.<br />
<br />
Extruder numbering starts at 0.<br />
<br />
== Proposed SCARA calibration codes (Morgan) ==<br />
<br />
In order to ease calibration of Reprap Morgan, the following M-codes are used to set the machine up<br />
Implemented in qharley/Marlin armlevel branch.<br />
<br />
==== M360 : Move to Theta 0 degree position ====<br />
The arms move into a position where the Theta steering arm is parallel to the top platform edge. The user then calibrates the position by moving the arms with the jog buttons in software like pronterface until it is perfectly parallel. Using M114 will then display the calibration offset that can then be programmed into the unit using M206 (Home offset) X represents Theta.<br />
<br />
==== M361 : Move to Theta 90 degree position ====<br />
Theta move to 90 degrees with platform edge. User calibrates by using jog arms to place exactly 90 degrees. Steps per degree can then be read out by using M114, and programmed using M92. X represents Theta. Program Y (Psi) to the same value initially. Remember to repeat M360 after adjusting steps per degree.<br />
<br />
==== M362 : Move to Psi 0 degree position ====<br />
Arms move to Psi 0 degree. Check only after other Theta calibrations<br />
<br />
==== M363 : Move to Psi 90 degree position ====<br />
Arms move to Psi 90 degree. Check only after other Theta calibrations<br />
<br />
==== M364 : Move to Psi + Theta 90 degree position ====<br />
Move arms to form a 90 degree angle between the inner and outer Psi arms. Calibrate by moving until angle is exactly 90 degree. Read out with M114, and calibrate value into Home offset M206. Psi is represented by Y.<br />
<br />
==== M365 : SCARA scaling factor ====<br />
Adjust X Y and Z scaling by entering the factor. 100% scaling (default) is represented by 1<br />
<br />
==== M370 : Morgan manual bed level - clear map ====<br />
Clear the map and prepare for calibration<br />
Usage: <br />
M370<br />
<br />
M370 X<divisions> Y<divisions><br />
<br />
Without parameters is defaults to X5 Y5 (25 calibration points) <br />
When specifying parameters, uneven numbers are recommended.<br />
<br />
==== M371 : Move to next calibration position ====<br />
Move to the next position for calibration. User moves the bed towards the hotend until it just touches<br />
<br />
==== M372 : Record calibration value, and move to next position ====<br />
The position of the bed is recorded and the machine moves to the next position. Repeat until all positions programmed<br />
<br />
==== M373 : End bed level calibration mode ====<br />
<br />
==== M375 : Display matrix ====<br />
Display the bed level calibration matrix<br />
<br />
Store the calibration to EEPROM using M500<br />
<br />
== Proposed EEPROM configuration codes ==<br />
<br />
BRIEFLY: each RepRap has a number of physical parameters that should be persistent, but easily configurable, such as extrusion steps/mm, various max values, etc. Those parameters are currently hardcoded in the firmware, so that a user has to modify, recompile and re-flash the firmware for any adjustments. These configs can be stored in MCU's EEPROM and modified via some M-codes. Please see the detailed proposal at [[M-codes for EEPROM config]]. (''This is proposed by --[[User:AlexRa|AlexRa]] on 11-March-2011. There is currently no working implementation of the proposed commands'').<br />
<br />
[[Marlin]] uses these codes to manipulate EEPROM values.<br />
<br />
[[Sprinter]] has implemented the following commands to manipulate EEPROM [https://github.com/kliment/Sprinter/commit/4b1b0f1d96d2be2ed3941095f40a5c2d2bbb943d Commit message].<br />
<br />
[[Teacup]] uses codes M130-M136 to set, read, and save some parameters.<br />
<br />
=== M500: stores paramters in EEPROM ===<br />
<br />
=== M501: reads parameters from EEPROM ===<br />
If you need to reset them after you changed them temporarily<br />
<br />
=== M502: reverts to the default "factory settings". ===<br />
<br />
You still need to store them in EEPROM afterwards if you want to.<br />
<br />
=== M503: Print settings ===<br />
<br />
== Replies from the RepRap machine to the host computer ==<br />
<br />
All communication is in printable ASCII characters. Messages sent back<br />
to the host computer are terminated by a newline and look like this:<br />
<br />
'''xx [line number to resend] [T:93.2 B:22.9] [C: X:9.2 Y:125.4 Z:3.7 E:1902.5] [Some debugging or other information may be here]'''<br />
<br />
'''xx''' can be one of:<br />
<br />
'''ok'''<br />
<br />
'''rs'''<br />
<br />
'''<nowiki>!!</nowiki>'''<br />
<br />
'''ok''' means that no error has been detected.<br />
<br />
'''rs''' means resend, and is followed by the line number to resend.<br />
<br />
'''<nowiki>!!</nowiki>''' means that a hardware fault has been detected. The RepRap machine will<br />
shut down immediately after it has sent this message.<br />
<br />
The '''T:''' and '''B:''' values are the temperature of the currently-selected extruder <br />
and the bed respectively, and are only sent in response to M105. If such temperatures don't exist (for example for an extruder that works at room temperature and doesn't have a sensor) then a value below absolute zero (-273<sup>o</sup>C) is returned.<br />
<br />
'''C:''' means that coordinates follow. Those are the '''X: Y:''' etc values. These are only <br />
sent in response to M114 and M117.<br />
<br />
The RepRap machine may also send lines that look like this:<br />
<br />
'''// This is some debugging or other information on a line on its own. It may be sent at any time. '''<br />
<br />
Such lines will always be preceded by '''//'''.<br />
<br />
The most common response is simply:<br />
<br />
'''ok''' <br />
<br />
When the machine boots up it sends the string<br />
<br />
'''start'''<br />
<br />
once to the host before sending anything else. This should not be replaced or augmented<br />
by version numbers and the like. M115 (see above) requests those.<br />
<br />
All this means that every line sent by RepRap to the host computer except the start line has a two-character prefix (one of '''ok''', '''rs''', '''<nowiki>!!</nowiki>''' or '''//'''). The machine should never send a line without such a prefix.<br />
<br />
<br />
'''Exceptions''': Marlin 1.0.0 Gen6 Firmware does not follow the two character rule. 'rs' is actually 'Resend' and '!!' is 'Error'.<br />
Example Lines:<br />
* Error: Line Number is not current line + 1. Last Line: 7<br />
* Resend: 8<br />
* Writing to File: print.gco<br />
* Done saving file.<br />
* File opened:print.gco Size:22992<br />
* File selected<br />
<br />
<br />
When in the code base did this change take place and what other firmwares are affected?<br />
<br />
<br />
[[Category:Model manufacturing software]]<br />
<br />
== Proposal for sending multiple lines of G-code ==<br />
<br />
So far, this is a proposal, open for discussion.<br />
<br />
==== Problem to solve ====<br />
<br />
Each line of G-code sent from the host to the controller is answered with an '''ok''' before the next line can be sent without locking communcations up. This makes operations very slow, as the usual USB-TTL converters and probably also the host's operating system drivers come with substantial latency, often 10&nbsp;milliseconds. <br />
<br />
For more details on this proposal, and some suggested solutions, and comments please see [[GCODE_buffer_multiline_proposal]]<br />
<br />
== Alternatives to G-code ==<br />
: ''Main article: [[Firmware/Alternative#alternatives to G-code]]''<br />
* [[Wikipedia: STEP-NC]]: "STEP-NC was designed to replace ... G-codes ... adding tolerance data ... [with a] XML format."<br />
* [[Elegant multispline motion controller]] "will not use G-code. It will use a custom language based on cubic Bezier curves. This allows for much better description of arcs and will result in much higher quality prints with a much lower data throughput requirements."</div>Bobchttps://reprap.org/mediawiki/index.php?title=Talk:G-code&diff=120041Talk:G-code2014-03-15T23:44:08Z<p>Bobc: /* M160 Syntax */</p>
<hr />
<div>==M104 & M109 Deprecation, G10 Introduction==<br />
<br />
No issues with deprecating M109, as this is an equivalent to M104 & M116. But M104? [heated bed (M140) example deleted]<br />
<br />
I consider G10 head/tool offset a good idea, but temperatures should be set by it's own command. Also, one often sets a temperature only, keeping the geometrical offset.<br />
<br />
If the L value is ignored, why is it part of the specification?<br />
<br />
Last not least, Marlin people already defined [[G-code#M206:_set_home_offset | M206]] for the head offset. These two should be aligned.<br />
<br />
--[[User:Traumflug|Traumflug]] 11:28, 19 July 2012 (UTC)<br />
<br />
M140 seems unaffected, Traumflug, so you can set the bed temp without changes.<br />
That said, I don't like any of this one bit. I don't like that the fast temp setting is gone, and I don't like that mysterious temperatures come out of nowhere when switching tool.<br />
I'd much prefer G10 to deal with spatial offset only, and use M10{4|9} [T0] S200. It gives the gcode generator much more control over the process. Having an OPTIONAL temperature setting in G10 would be acceptable for me, but definitely not deprecating M104/M109<br />
<br />
--Kliment<br />
<br />
I don't quite see why temperature offsets are different from spatial offsets - it's just another dimension in which the machine operates. It seemed neater to me to set them all in one place. And temperatures don't come out of nowhere - they are values you have previously explicitly set...<br />
<br />
Jean-Marc pointed out that it would be useful to have an option to save and load this stuff from eeprom like Marlin with M500 - that way you could have slightly different offsets for different machines and still run them all off the same G Code file.<br />
<br />
I agree that M104 is useful as it allows you:<br />
<br />
#to set temp and return<br />
#to do stuff you know doesn't involve extruding<br />
#to set same temp and wait<br />
<br />
Which speeds things up a bit at the start of a print. I'm not quite sure what we should do about that.<br />
<br />
As there is a standard (G10) for setting offset that pre-dates the invention of 3D printing, I think that's preferable to M206.<br />
<br />
Finally - remember that the time interval between something being deprecated and something going away altogether can be arbitrarily long, and is entirely in the hands of people writing firmware :-)<br />
<br />
- Adrian<br />
<br />
<br />
I have no problem introducing a new command which is a superset of existing functionality, and even better if it is more standard compliant, but I can't see a good reason to remove the previous commands, as there is no conflict in functionality. Presumably if G10 returns an error, then the host must fall back to previous commands. <br />
<br />
I don't know which standard you are looking at, but in mine (the official NIST standard) G10 does not set tool offsets. It appears some software out there is using a different, non-standard meaning for G10. I don't think non-standard use by one or more applications creates "a standard". Our use of G10 also has quite different parameters. This proposal would appear to be replacing non-standard command(s) with a new non-standard command, which doesn't help standardization and breaks compatibility. <br />
<br />
--[[User:Bobc|Bobc]] 21:41, 30 July 2012 (UTC)<br />
<br />
<br />
Thanks for the comments so far. I see we agree on M109 being obsolete, so I've removed the discussion tag.<br />
<br />
Regarding the [http://www.nist.gov/customcf/get_pdf.cfm?pub_id=823374 NIST standard], G10 is described there as setting a coordinate system, so it's similar to setting a tool offset.<br />
<br />
Not a word there on what L does, though. So I reduced it's description.<br />
<br />
What's left is R and S, the standby and work temperatures. How about making them optional?<br />
* Without R and S, both default to zero, so we have the (former) behaviour without G10.<br />
* With R and/or S, temperatures are set at tool change time (T, M6 command).<br />
* M104 always sets the temperature of the current extruder. So it matches traditional behaviour in case R and S weren't used. In case R and/or S are used, M104 overrides the extruder's work temperature, but doesn't change the extruder's S setting.<br />
--[[User:Traumflug|Traumflug]] 22:22, 31 July 2012 (UTC)<br />
<br />
<br />
I don't see the same agreement on M109 that you do, unless you are ignoring specific objections.<br />
<br />
I did a little digging, it appears the L parameter selects a "parameter number". So in NIST, L2 means "set coordinate system". FANUC systems use versions of G10 as "set tool offsets", sometimes L1, L10 or L12, sometimes omitted. Other L numbers may set other parameters, depending on machine. LinuxCNC appears to support several values of L. If we are using the parameters to mean something different (e.g R parameter is not used to define cutter radius), we should probably pick something like L3.<br />
<br />
Ref [http://www.linuxcnc.org/docs/devel/html/gcode/gcode.html#_g10_l1_set_tool_table_a_id_sec_g10_l1_a LinuxCNC G Codes]<br />
<br />
--[[User:Bobc|Bobc]] 08:02, 4 August 2012 (UTC)<br />
<br />
<br />
Did I miss something? I see no vote for M109, just a combined one for M104/M109. How to replace M109 by M104 is described.<br />
<br />
So, the L parameter is sort of a sub-command on a number of other, non RepRap G-code interpreters. Thanks a lot for the digging. Does that make the current description of the RepRap G-code flavour wrong? I think it's sufficient to describe what a RepRap firmware does, elaborating on what others do should go to something like a "G-code in General" wiki page.<br />
<br />
--[[User:Traumflug|Traumflug]] 10:45, 4 August 2012 (UTC)<br />
<br />
Has anyone implemented G10 in either a slicer or a firmware in the way described on the wiki? I am depending on M109s and M104s in prontserve to send the target temperature events but I can add G10 as well if this is actually used somewhere. Marlin seems to use it as a retract command (see https://github.com/ErikZalm/Marlin/blob/Marlin_v1/Marlin/Marlin_main.cpp#L771 ) and I guess I can just go off that.<br />
<br />
TL;DR This is very unclear to me. This needs documentation.<br />
<br />
--[[User:TheOtherRob|TheOtherRob]] 03:37, 27 June 2013 (UTC) (d1plo1d on github)<br />
<br />
==Checking==<br />
<br />
"These are the line number and the checksum. The RepRap firmware checks the checksum against a locally-computed value and, if they differ, requests a repeat transmission of the line of the given number. "<br />
<br />
Surely the firmware must request resending of the ''expected'' number, not the given number in the line. If the checksum is wrong, then the firmware should not rely on the line being correct, including the N value. The same goes for valid checksum but line number out of sequence, the algorithm as stated will keep requesting the same line!<br />
<br />
--[[User:Bobc|Bobc]] 21:41, 30 July 2012 (UTC)<br />
<br />
==Other stuff==<br />
<br />
Ah excellent, I've been waiting for this! I've been working from the gcode and mcode pages in the old wiki which have a few holes.<br />
<br />
The line number and checksum stuff is new to me- I'll implement that into my firmware in the coming days. So are some of these M-codes for that matter.<br />
<br />
Can we add some sort of reference for what the host expects in response from the firmware? So far, I'm sending back OK when the command is queued or executed and T: nnn every second when the heater is on, which as far as I can tell is all that's needed.<br />
<br />
ps: why are G20/G21/G90/G91/G92 specified to block? ("''The following commands are not buffered. When one is received it is stored, but it is not acknowledged to the host until the buffer is exhausted and then the command has been executed.''") they simply alter the conversion factors for the next command received in my firmware, and so can respond OK immediately.<br />
<br />
Only G4 (dwell) and M101 (start extruder when up to temperature, apparently superceded by the new M109) block in my firmware at the moment, and I'm seriously considering making even these queue-able so they block the queue instead of the command download stream.<br />
<br />
-- [[User:Triffid_hunter|Triffid Hunter]]<br />
<br />
<br />
I agree. It's great for this to be documented.<br />
<br />
I had one suggestion on the checksum -- it should perhaps use a stronger CRC checksum, and should also encorporate the length as well? Is the N and * part of an external standard, or a RepRap special sauce?<br />
<br />
If they are RepRap specific, I'd suggest changing the N code to include line length as something like "N101.50" for line 101, consisting of 50 characters.<br />
<br />
I use the following CRC algorithm, which I believe I stole from the CCITT standard:<br />
<br />
<pre><br />
static inline uint16_t GetCRC( uint16_t crc, char ser_data )<br />
{<br />
crc = (unsigned char)(crc >> 8) | (crc << 8);<br />
crc ^= ser_data;<br />
crc ^= (unsigned char)(crc & 0xff) >> 4;<br />
crc ^= (crc << 8) << 4;<br />
crc ^= ((crc & 0xff) << 4) << 1;<br />
return crc;<br />
}<br />
</pre><br />
<br />
The logic to compute checksum would then become:<br />
<br />
<pre><br />
uint16_t cs = 0;<br />
for(int i = 0; i < cmd.length(); i++)<br />
cs = GetCRC( cs, cmd.charAt(i) );<br />
<br />
computedCrc = cs;<br />
</pre><br />
<br />
So, the full logic for accepting or testing a line, encoded with full N and CRC checksum would be something like:<br />
<br />
<pre><br />
// was line number and checksum provided?<br />
bool value = true;<br />
if( lineNumber != 0 )<br />
{<br />
valid = lineNumber == expectedLineNumber<br />
&& cmd.length() == providedLength<br />
&& computedCrc == providedCrc;<br />
}<br />
<br />
// accept or reject the line based on valid flag<br />
<br />
</pre><br />
<br />
This does add a few bytes of overhead (3-4 for length, 2-3 for 16 bit crc), but may be worth it allows you to run a higher baud rate with reasonably low error rates -- the odds of a false positive are near enough to zero to make any statistician happy.<br />
<br />
-- [[User:BeagleFury|BeagleFury]]<br />
<br />
Just wanted to chime in - Thanks Adrian! This answers many questions for me!<br />
-- [[User:Wade|Wade]]<br />
<br />
== what part of the line does cmd.length() refer to? ==<br />
<br />
Just trying to implement the checksum logic, and realised that it makes no sense for the checksum to include itself or things get very recursive. What point is considered end-of-line? is it the asterisk? the space before the asterisk? the last non-whitespace before the asterisk?<br />
<br />
My firmware doesn't buffer the line, rather processes it character by character so this has to become another special case.<br />
<br />
-- [[User:Triffid_hunter|Triffid Hunter]]<br />
<br />
The checksum includes all characters in the string up to and including the character before the asterisk (i.e. up to but not including the asterisk). -- [[User:neilrqm|neilrqm]]<br />
<br />
== Future-proof M-codes? ==<br />
<br />
Adding new M-codes for extra sensors/heaters seems a little non-future-proof to me. My firmware uses P parameter to know which sensor/heater is being referred to eg M104 S100 sets heater 0 to 100c, but M104 P2 S100 sets heater 2 to 100c. Same for all the temperature sensor readback stuff. Future proofing protocols is always a good idea :)<br />
<br />
== G91: Set to Relative Positioning ==<br />
<br />
Example: G91<br />
All coordinates from now on are relative to the last position.<br />
<br />
Question: does this include the feed rate?<br />
<br />
-- [[User:Pietr]]<br />
<br />
== M203: Record Z adjustment ==<br />
<br />
which firmware does this?<br />
<br />
Sprinter Main does not have M203 implimented<br />
Sprinter Experimental has M203 as "M203 Temperature monitor for Repetier"<br />
Repetier has M203 as Temperaturmonitor.<br />
Marlin has M203 - Set maximum feedrate that your machine can sustain (M203 X200 Y200 Z300 E10000) in mm/sec<br />
Teacup has no M203<br />
<br />
Does any current or experimental firmware have the z adjustment implimented?<br />
<br />
eMAKER Sprinter used this. but is now deprecated in favour of Marlin.<br />
<br />
-- [[User:jmgiacalone|jmgiacalone]]<br />
<br />
== M92: Set axis_steps_per_unit ==<br />
<br />
M92 Sets the number of steps per unit, this is GREAT to fine tuning the extruder head, where even different colors of the same filament act differently, even when the measured diameter is measured precisely. It's simple enough to calibrate this using a simple cube alternating layers between 100% infill and 95% infill and adjusting the E steps per mm to not show gaps on the 100% layers and to just barely show gaps on the 95% layers.<br />
<br />
M92 is much better for compensating for different filament than putting it in the slicer program, because you might want to run the same program with different colors.. even within the same job, perhaps one would want to pause the program during a non critical infill, remove the filament, put in a different color, and then continue.. if you had previously calibrated all your filaments and got accurate steps per mm of those filaments, you can simply issue a M92 for the filament you just installed, then when you continue the program, the extruder will be working correctly.<br />
<br />
The problem I find is that I don't know what number to start putting in there.. it is listed in config.h, however that can be overridden if the eeprom is activated. I notice that M99: Set axis_hysteresis_mm has a corresponding M98: Get axis_hysteresis_mm why not have an M91: Get axis_steps_per_unit. Then there would be no mucking about in code trying to figure out what the extruder is currently set at, and it would make it MUCH easier for people who bought kit machines who really don't understand the code to be able to calibrate the extruder head.<br />
=== EEPROM gcodes ===<br />
<br />
It would be great if there were such a gcode function since still at the time of writing the retailer at least aught to point the client in the right direction for resources on the subject. Which unfortunately very few seems to actually do and the client remains restrained as a consumer instead of as advertised an step towards a emancipated maker through educational resources on settings/calibration, but also inspirational homage dito, to use the tool efficiently as well as with heart. Thankfully there are initiatives such as FSF's "[http://www.fsf.org/resources/hw/endorsement/respects-your-freedom Respects Your Freedom hardware product certification]", which one can easily endorse especially in times were companies [[Replicator_2_Controversy|reap]] but, more importantly do not [[Neutering a RepRap|sow]].<br />
<br />
Anyhow, there are some [[G-code#Proposed_EEPROM_configuration_codes|Proposed EEPROM configuration codes]] which marlin, sprinter, teacup et al firmwares uses. But needless to say, all of these depend on that one enabled the feature in the configuration pages and beyond that a friendly GUI, which [[repetier host]] is the only alternative (so far) when it comes to "easy to use point and click"-settings.<br />
<br />
: For Teacup firmware EECONFIG is enabled by default, so there is no need for enabling anything. And you guessed it, quite some retailers have no idea of what they're selling. This is a consequence of RepRap putting so much emphasis on being open source ( = zero pay for developers) and cheering commercial shops ( = all money goes to the shops). So, I see no point in complaining about "retailers". It's what RepRap asks for. --[[User:Traumflug|Traumflug]] 12:07, 6 December 2012 (UTC)<br />
<br />
== Time for G-code V2 ==<br />
<br />
Is it time to rewrite this G-code specification, maybe call it version 2, or a more creative naming variant? The current specification is a kludge going back many years and authors. The ACK specification is inconsistent. There is no formal language specification, so new language features get added and "do their best to follow existing standards" - standards which aren't actually defined. Different firmwares provide variants on the specification here, but again there's no standard for them to follow, or way to define their variant so control software programmers can adjust easily and confidently.<br />
<br />
# Let's discuss a roadmap and milestones for such an effort.<br />
# Let's create a specification in a formalized notation so non-english speakers don't need a translator to read it.<br />
# Let's formalize our 3D printer G-code variant by writing it in Backus–Naur Form. Indeed this may scare some cooks out of the kitchen...I doubt it...but if they are, maybe that's good.<br />
# Let's get a standard and consistent ACK<br />
# Let's discuss and find ways to improve the ACK to make things easier for control software<br />
# Let's not leave slots for "forwards compatibility". Instead, let's recommend (or specify) how to extend the specification we create.<br />
# Let's create a consistent ACK specification. The current one is inconsistent. Take, for example, the wait commands. Rather than send an OK as response to the command, the spec. allows firmwares to send other data - such as the current temp readings (w/targets) - and it can easily take up to 600 seconds for control software to receive "OK" while it was processing kilobytes of response data.<br />
# Let's address how commands are buffered. For example, it might make sense to specify that upon receiving a buffered command, an ACK is sent in response that indicates the command was buffered - or more importantly which command was buffered.<br />
# Let's create a standard way for firmwares to identify themselves, and their capabilities.<br />
<br />
Here's a G-Code example per this spec. from Marlin that exposes fundamental issues:<br />
<pre><br />
Send: M104 S1900<br />
Recv: ok T:28.1 /1900.0 B:59.8 /60.0 @:127 B@:0<br />
Recv: ok T:29.2 /1900.0 B:59.9 /60.0 @:127 B@:0<br />
Recv: ok T:31.3 /1900.0 B:59.9 /60.0 @:127 B@:0<br />
Recv: ok T:32.0 /1900.0 B:60.0 /60.0 @:127 B@:0<br />
...<br />
...<br />
Error:0<br />
: Extruder switched off. MAXTEMP triggered !<br />
Error: Printer stopped deu to errors. Fix the error and use M999 to restart!. (Temperature is reset. Set it before restarting)<br />
</pre><br />
<br />
A similar scenario is encountered when setting the bed temp. According to the spec we expect a similar result for a target < MINTEMP - possibly permuting this (poor) specification outcome to at least 4 use-cases.<br />
<br />
The command M104 S1900 asks the printer to destroy a typical reprap hotend. It would be trivial to specify how to respond with an error msg. for an out-of-range temp. request immediately, not when hitting MAXTEMP. Same for MINTEMP if that's the case. However, the current spec. does not provide a way to ACK with a standard error msg. In fact, it ''does not provide a standard ACK format'', it just illustrates what certain firmwares do in their ACKs.<br />
<br />
(Anonymous user?)<br />
<br />
: I am still waiting for a G-Code V1!<br />
: The problem is not lack of a standard, but that people just don't want to follow specs. There is a good NIST G-code spec, but no one followed that. New G-code features are hacked in arbitrarily, and this is the case from Day 1, where the "spec" was whatever the first firmware written happened to do. By it's nature, a wiki based spec is a free for all. <br />
:There are some elements of what you suggest already, but getting an encompassing spec written is unlikely to happen, unless someone volunteers to do it. You might get further if you make some specific suggestions regarding ACKs say, and add that as a "Proposed .." section. Really, the only thing you can do is to design something better and hope people will use it.<br />
:Also please sign so we know who we are talking to :)<br />
:--[[User:Bobc|Bobc]] ([[User talk:Bobc|talk]]) 08:05, 30 December 2013 (PST)<br />
<br />
== M160 Syntax ==<br />
<br />
The Syntax proposed was<br />
<br />
<pre><br />
M160 S4<br />
G1 X90.6 Y13.8 E22.4 0.1 0.1 0.1 0.7<br />
G1 X70.6 E42.4 0.0 0.0 0.0 1.0<br />
G1 E42.4 1.0 0.0 0.0 0.0<br />
</pre><br />
However whitespace delimiters do not work well(at all) in most gcode implementations, I have updated these to ":" delimiters.<br />
<br />
In addition I think the complexity is best left in the slicer so the G1 command should indicate distance to move for each extruder drive rather than a total distance and a mixing %<br />
This allows for multiple different drive types with varying esteps/mm to be used easily - the slicer decides the volume of each material to<br />
extrude based on the diameter input by the user.<br />
<br />
for the example give the syntax now looks like this:<br />
<pre><br />
M160 S4<br />
G1 X90.6 Y13.8 E2.24:2.24:2.24:15.89<br />
G1 X70.6 E0.0:0.0:0.0:42.4<br />
G1 E42.4:0.0:0.0:0.0<br />
</pre><br />
<br />
:I think that is better, however it subtly changes how the mix ratio is applied, the mix ratio would be constant for the duration of the move. The last line now has no effect.<br />
:It would seem more logical to use comma (,) to separate items in a list. Now that distances are used instead of ratios, the M160 seems to be redundant. The printer just extrudes whatever is in the E list.<br />
:--[[User:Bobc|Bobc]] ([[User talk:Bobc|talk]]) 16:35, 15 March 2014 (PDT)</div>Bobchttps://reprap.org/mediawiki/index.php?title=Talk:G-code&diff=120040Talk:G-code2014-03-15T23:35:02Z<p>Bobc: /* M160 Syntax */</p>
<hr />
<div>==M104 & M109 Deprecation, G10 Introduction==<br />
<br />
No issues with deprecating M109, as this is an equivalent to M104 & M116. But M104? [heated bed (M140) example deleted]<br />
<br />
I consider G10 head/tool offset a good idea, but temperatures should be set by it's own command. Also, one often sets a temperature only, keeping the geometrical offset.<br />
<br />
If the L value is ignored, why is it part of the specification?<br />
<br />
Last not least, Marlin people already defined [[G-code#M206:_set_home_offset | M206]] for the head offset. These two should be aligned.<br />
<br />
--[[User:Traumflug|Traumflug]] 11:28, 19 July 2012 (UTC)<br />
<br />
M140 seems unaffected, Traumflug, so you can set the bed temp without changes.<br />
That said, I don't like any of this one bit. I don't like that the fast temp setting is gone, and I don't like that mysterious temperatures come out of nowhere when switching tool.<br />
I'd much prefer G10 to deal with spatial offset only, and use M10{4|9} [T0] S200. It gives the gcode generator much more control over the process. Having an OPTIONAL temperature setting in G10 would be acceptable for me, but definitely not deprecating M104/M109<br />
<br />
--Kliment<br />
<br />
I don't quite see why temperature offsets are different from spatial offsets - it's just another dimension in which the machine operates. It seemed neater to me to set them all in one place. And temperatures don't come out of nowhere - they are values you have previously explicitly set...<br />
<br />
Jean-Marc pointed out that it would be useful to have an option to save and load this stuff from eeprom like Marlin with M500 - that way you could have slightly different offsets for different machines and still run them all off the same G Code file.<br />
<br />
I agree that M104 is useful as it allows you:<br />
<br />
#to set temp and return<br />
#to do stuff you know doesn't involve extruding<br />
#to set same temp and wait<br />
<br />
Which speeds things up a bit at the start of a print. I'm not quite sure what we should do about that.<br />
<br />
As there is a standard (G10) for setting offset that pre-dates the invention of 3D printing, I think that's preferable to M206.<br />
<br />
Finally - remember that the time interval between something being deprecated and something going away altogether can be arbitrarily long, and is entirely in the hands of people writing firmware :-)<br />
<br />
- Adrian<br />
<br />
<br />
I have no problem introducing a new command which is a superset of existing functionality, and even better if it is more standard compliant, but I can't see a good reason to remove the previous commands, as there is no conflict in functionality. Presumably if G10 returns an error, then the host must fall back to previous commands. <br />
<br />
I don't know which standard you are looking at, but in mine (the official NIST standard) G10 does not set tool offsets. It appears some software out there is using a different, non-standard meaning for G10. I don't think non-standard use by one or more applications creates "a standard". Our use of G10 also has quite different parameters. This proposal would appear to be replacing non-standard command(s) with a new non-standard command, which doesn't help standardization and breaks compatibility. <br />
<br />
--[[User:Bobc|Bobc]] 21:41, 30 July 2012 (UTC)<br />
<br />
<br />
Thanks for the comments so far. I see we agree on M109 being obsolete, so I've removed the discussion tag.<br />
<br />
Regarding the [http://www.nist.gov/customcf/get_pdf.cfm?pub_id=823374 NIST standard], G10 is described there as setting a coordinate system, so it's similar to setting a tool offset.<br />
<br />
Not a word there on what L does, though. So I reduced it's description.<br />
<br />
What's left is R and S, the standby and work temperatures. How about making them optional?<br />
* Without R and S, both default to zero, so we have the (former) behaviour without G10.<br />
* With R and/or S, temperatures are set at tool change time (T, M6 command).<br />
* M104 always sets the temperature of the current extruder. So it matches traditional behaviour in case R and S weren't used. In case R and/or S are used, M104 overrides the extruder's work temperature, but doesn't change the extruder's S setting.<br />
--[[User:Traumflug|Traumflug]] 22:22, 31 July 2012 (UTC)<br />
<br />
<br />
I don't see the same agreement on M109 that you do, unless you are ignoring specific objections.<br />
<br />
I did a little digging, it appears the L parameter selects a "parameter number". So in NIST, L2 means "set coordinate system". FANUC systems use versions of G10 as "set tool offsets", sometimes L1, L10 or L12, sometimes omitted. Other L numbers may set other parameters, depending on machine. LinuxCNC appears to support several values of L. If we are using the parameters to mean something different (e.g R parameter is not used to define cutter radius), we should probably pick something like L3.<br />
<br />
Ref [http://www.linuxcnc.org/docs/devel/html/gcode/gcode.html#_g10_l1_set_tool_table_a_id_sec_g10_l1_a LinuxCNC G Codes]<br />
<br />
--[[User:Bobc|Bobc]] 08:02, 4 August 2012 (UTC)<br />
<br />
<br />
Did I miss something? I see no vote for M109, just a combined one for M104/M109. How to replace M109 by M104 is described.<br />
<br />
So, the L parameter is sort of a sub-command on a number of other, non RepRap G-code interpreters. Thanks a lot for the digging. Does that make the current description of the RepRap G-code flavour wrong? I think it's sufficient to describe what a RepRap firmware does, elaborating on what others do should go to something like a "G-code in General" wiki page.<br />
<br />
--[[User:Traumflug|Traumflug]] 10:45, 4 August 2012 (UTC)<br />
<br />
Has anyone implemented G10 in either a slicer or a firmware in the way described on the wiki? I am depending on M109s and M104s in prontserve to send the target temperature events but I can add G10 as well if this is actually used somewhere. Marlin seems to use it as a retract command (see https://github.com/ErikZalm/Marlin/blob/Marlin_v1/Marlin/Marlin_main.cpp#L771 ) and I guess I can just go off that.<br />
<br />
TL;DR This is very unclear to me. This needs documentation.<br />
<br />
--[[User:TheOtherRob|TheOtherRob]] 03:37, 27 June 2013 (UTC) (d1plo1d on github)<br />
<br />
==Checking==<br />
<br />
"These are the line number and the checksum. The RepRap firmware checks the checksum against a locally-computed value and, if they differ, requests a repeat transmission of the line of the given number. "<br />
<br />
Surely the firmware must request resending of the ''expected'' number, not the given number in the line. If the checksum is wrong, then the firmware should not rely on the line being correct, including the N value. The same goes for valid checksum but line number out of sequence, the algorithm as stated will keep requesting the same line!<br />
<br />
--[[User:Bobc|Bobc]] 21:41, 30 July 2012 (UTC)<br />
<br />
==Other stuff==<br />
<br />
Ah excellent, I've been waiting for this! I've been working from the gcode and mcode pages in the old wiki which have a few holes.<br />
<br />
The line number and checksum stuff is new to me- I'll implement that into my firmware in the coming days. So are some of these M-codes for that matter.<br />
<br />
Can we add some sort of reference for what the host expects in response from the firmware? So far, I'm sending back OK when the command is queued or executed and T: nnn every second when the heater is on, which as far as I can tell is all that's needed.<br />
<br />
ps: why are G20/G21/G90/G91/G92 specified to block? ("''The following commands are not buffered. When one is received it is stored, but it is not acknowledged to the host until the buffer is exhausted and then the command has been executed.''") they simply alter the conversion factors for the next command received in my firmware, and so can respond OK immediately.<br />
<br />
Only G4 (dwell) and M101 (start extruder when up to temperature, apparently superceded by the new M109) block in my firmware at the moment, and I'm seriously considering making even these queue-able so they block the queue instead of the command download stream.<br />
<br />
-- [[User:Triffid_hunter|Triffid Hunter]]<br />
<br />
<br />
I agree. It's great for this to be documented.<br />
<br />
I had one suggestion on the checksum -- it should perhaps use a stronger CRC checksum, and should also encorporate the length as well? Is the N and * part of an external standard, or a RepRap special sauce?<br />
<br />
If they are RepRap specific, I'd suggest changing the N code to include line length as something like "N101.50" for line 101, consisting of 50 characters.<br />
<br />
I use the following CRC algorithm, which I believe I stole from the CCITT standard:<br />
<br />
<pre><br />
static inline uint16_t GetCRC( uint16_t crc, char ser_data )<br />
{<br />
crc = (unsigned char)(crc >> 8) | (crc << 8);<br />
crc ^= ser_data;<br />
crc ^= (unsigned char)(crc & 0xff) >> 4;<br />
crc ^= (crc << 8) << 4;<br />
crc ^= ((crc & 0xff) << 4) << 1;<br />
return crc;<br />
}<br />
</pre><br />
<br />
The logic to compute checksum would then become:<br />
<br />
<pre><br />
uint16_t cs = 0;<br />
for(int i = 0; i < cmd.length(); i++)<br />
cs = GetCRC( cs, cmd.charAt(i) );<br />
<br />
computedCrc = cs;<br />
</pre><br />
<br />
So, the full logic for accepting or testing a line, encoded with full N and CRC checksum would be something like:<br />
<br />
<pre><br />
// was line number and checksum provided?<br />
bool value = true;<br />
if( lineNumber != 0 )<br />
{<br />
valid = lineNumber == expectedLineNumber<br />
&& cmd.length() == providedLength<br />
&& computedCrc == providedCrc;<br />
}<br />
<br />
// accept or reject the line based on valid flag<br />
<br />
</pre><br />
<br />
This does add a few bytes of overhead (3-4 for length, 2-3 for 16 bit crc), but may be worth it allows you to run a higher baud rate with reasonably low error rates -- the odds of a false positive are near enough to zero to make any statistician happy.<br />
<br />
-- [[User:BeagleFury|BeagleFury]]<br />
<br />
Just wanted to chime in - Thanks Adrian! This answers many questions for me!<br />
-- [[User:Wade|Wade]]<br />
<br />
== what part of the line does cmd.length() refer to? ==<br />
<br />
Just trying to implement the checksum logic, and realised that it makes no sense for the checksum to include itself or things get very recursive. What point is considered end-of-line? is it the asterisk? the space before the asterisk? the last non-whitespace before the asterisk?<br />
<br />
My firmware doesn't buffer the line, rather processes it character by character so this has to become another special case.<br />
<br />
-- [[User:Triffid_hunter|Triffid Hunter]]<br />
<br />
The checksum includes all characters in the string up to and including the character before the asterisk (i.e. up to but not including the asterisk). -- [[User:neilrqm|neilrqm]]<br />
<br />
== Future-proof M-codes? ==<br />
<br />
Adding new M-codes for extra sensors/heaters seems a little non-future-proof to me. My firmware uses P parameter to know which sensor/heater is being referred to eg M104 S100 sets heater 0 to 100c, but M104 P2 S100 sets heater 2 to 100c. Same for all the temperature sensor readback stuff. Future proofing protocols is always a good idea :)<br />
<br />
== G91: Set to Relative Positioning ==<br />
<br />
Example: G91<br />
All coordinates from now on are relative to the last position.<br />
<br />
Question: does this include the feed rate?<br />
<br />
-- [[User:Pietr]]<br />
<br />
== M203: Record Z adjustment ==<br />
<br />
which firmware does this?<br />
<br />
Sprinter Main does not have M203 implimented<br />
Sprinter Experimental has M203 as "M203 Temperature monitor for Repetier"<br />
Repetier has M203 as Temperaturmonitor.<br />
Marlin has M203 - Set maximum feedrate that your machine can sustain (M203 X200 Y200 Z300 E10000) in mm/sec<br />
Teacup has no M203<br />
<br />
Does any current or experimental firmware have the z adjustment implimented?<br />
<br />
eMAKER Sprinter used this. but is now deprecated in favour of Marlin.<br />
<br />
-- [[User:jmgiacalone|jmgiacalone]]<br />
<br />
== M92: Set axis_steps_per_unit ==<br />
<br />
M92 Sets the number of steps per unit, this is GREAT to fine tuning the extruder head, where even different colors of the same filament act differently, even when the measured diameter is measured precisely. It's simple enough to calibrate this using a simple cube alternating layers between 100% infill and 95% infill and adjusting the E steps per mm to not show gaps on the 100% layers and to just barely show gaps on the 95% layers.<br />
<br />
M92 is much better for compensating for different filament than putting it in the slicer program, because you might want to run the same program with different colors.. even within the same job, perhaps one would want to pause the program during a non critical infill, remove the filament, put in a different color, and then continue.. if you had previously calibrated all your filaments and got accurate steps per mm of those filaments, you can simply issue a M92 for the filament you just installed, then when you continue the program, the extruder will be working correctly.<br />
<br />
The problem I find is that I don't know what number to start putting in there.. it is listed in config.h, however that can be overridden if the eeprom is activated. I notice that M99: Set axis_hysteresis_mm has a corresponding M98: Get axis_hysteresis_mm why not have an M91: Get axis_steps_per_unit. Then there would be no mucking about in code trying to figure out what the extruder is currently set at, and it would make it MUCH easier for people who bought kit machines who really don't understand the code to be able to calibrate the extruder head.<br />
=== EEPROM gcodes ===<br />
<br />
It would be great if there were such a gcode function since still at the time of writing the retailer at least aught to point the client in the right direction for resources on the subject. Which unfortunately very few seems to actually do and the client remains restrained as a consumer instead of as advertised an step towards a emancipated maker through educational resources on settings/calibration, but also inspirational homage dito, to use the tool efficiently as well as with heart. Thankfully there are initiatives such as FSF's "[http://www.fsf.org/resources/hw/endorsement/respects-your-freedom Respects Your Freedom hardware product certification]", which one can easily endorse especially in times were companies [[Replicator_2_Controversy|reap]] but, more importantly do not [[Neutering a RepRap|sow]].<br />
<br />
Anyhow, there are some [[G-code#Proposed_EEPROM_configuration_codes|Proposed EEPROM configuration codes]] which marlin, sprinter, teacup et al firmwares uses. But needless to say, all of these depend on that one enabled the feature in the configuration pages and beyond that a friendly GUI, which [[repetier host]] is the only alternative (so far) when it comes to "easy to use point and click"-settings.<br />
<br />
: For Teacup firmware EECONFIG is enabled by default, so there is no need for enabling anything. And you guessed it, quite some retailers have no idea of what they're selling. This is a consequence of RepRap putting so much emphasis on being open source ( = zero pay for developers) and cheering commercial shops ( = all money goes to the shops). So, I see no point in complaining about "retailers". It's what RepRap asks for. --[[User:Traumflug|Traumflug]] 12:07, 6 December 2012 (UTC)<br />
<br />
== Time for G-code V2 ==<br />
<br />
Is it time to rewrite this G-code specification, maybe call it version 2, or a more creative naming variant? The current specification is a kludge going back many years and authors. The ACK specification is inconsistent. There is no formal language specification, so new language features get added and "do their best to follow existing standards" - standards which aren't actually defined. Different firmwares provide variants on the specification here, but again there's no standard for them to follow, or way to define their variant so control software programmers can adjust easily and confidently.<br />
<br />
# Let's discuss a roadmap and milestones for such an effort.<br />
# Let's create a specification in a formalized notation so non-english speakers don't need a translator to read it.<br />
# Let's formalize our 3D printer G-code variant by writing it in Backus–Naur Form. Indeed this may scare some cooks out of the kitchen...I doubt it...but if they are, maybe that's good.<br />
# Let's get a standard and consistent ACK<br />
# Let's discuss and find ways to improve the ACK to make things easier for control software<br />
# Let's not leave slots for "forwards compatibility". Instead, let's recommend (or specify) how to extend the specification we create.<br />
# Let's create a consistent ACK specification. The current one is inconsistent. Take, for example, the wait commands. Rather than send an OK as response to the command, the spec. allows firmwares to send other data - such as the current temp readings (w/targets) - and it can easily take up to 600 seconds for control software to receive "OK" while it was processing kilobytes of response data.<br />
# Let's address how commands are buffered. For example, it might make sense to specify that upon receiving a buffered command, an ACK is sent in response that indicates the command was buffered - or more importantly which command was buffered.<br />
# Let's create a standard way for firmwares to identify themselves, and their capabilities.<br />
<br />
Here's a G-Code example per this spec. from Marlin that exposes fundamental issues:<br />
<pre><br />
Send: M104 S1900<br />
Recv: ok T:28.1 /1900.0 B:59.8 /60.0 @:127 B@:0<br />
Recv: ok T:29.2 /1900.0 B:59.9 /60.0 @:127 B@:0<br />
Recv: ok T:31.3 /1900.0 B:59.9 /60.0 @:127 B@:0<br />
Recv: ok T:32.0 /1900.0 B:60.0 /60.0 @:127 B@:0<br />
...<br />
...<br />
Error:0<br />
: Extruder switched off. MAXTEMP triggered !<br />
Error: Printer stopped deu to errors. Fix the error and use M999 to restart!. (Temperature is reset. Set it before restarting)<br />
</pre><br />
<br />
A similar scenario is encountered when setting the bed temp. According to the spec we expect a similar result for a target < MINTEMP - possibly permuting this (poor) specification outcome to at least 4 use-cases.<br />
<br />
The command M104 S1900 asks the printer to destroy a typical reprap hotend. It would be trivial to specify how to respond with an error msg. for an out-of-range temp. request immediately, not when hitting MAXTEMP. Same for MINTEMP if that's the case. However, the current spec. does not provide a way to ACK with a standard error msg. In fact, it ''does not provide a standard ACK format'', it just illustrates what certain firmwares do in their ACKs.<br />
<br />
(Anonymous user?)<br />
<br />
: I am still waiting for a G-Code V1!<br />
: The problem is not lack of a standard, but that people just don't want to follow specs. There is a good NIST G-code spec, but no one followed that. New G-code features are hacked in arbitrarily, and this is the case from Day 1, where the "spec" was whatever the first firmware written happened to do. By it's nature, a wiki based spec is a free for all. <br />
:There are some elements of what you suggest already, but getting an encompassing spec written is unlikely to happen, unless someone volunteers to do it. You might get further if you make some specific suggestions regarding ACKs say, and add that as a "Proposed .." section. Really, the only thing you can do is to design something better and hope people will use it.<br />
:Also please sign so we know who we are talking to :)<br />
:--[[User:Bobc|Bobc]] ([[User talk:Bobc|talk]]) 08:05, 30 December 2013 (PST)<br />
<br />
== M160 Syntax ==<br />
<br />
The Syntax proposed was<br />
<br />
<pre><br />
M160 S4<br />
G1 X90.6 Y13.8 E22.4 0.1 0.1 0.1 0.7<br />
G1 X70.6 E42.4 0.0 0.0 0.0 1.0<br />
G1 E42.4 1.0 0.0 0.0 0.0<br />
</pre><br />
However whitespace delimiters do not work well(at all) in most gcode implementations, I have updated these to ":" delimiters.<br />
<br />
In addition I think the complexity is best left in the slicer so the G1 command should indicate distance to move for each extruder drive rather than a total distance and a mixing %<br />
This allows for multiple different drive types with varying esteps/mm to be used easily - the slicer decides the volume of each material to<br />
extrude based on the diameter input by the user.<br />
<br />
for the example give the syntax now looks like this:<br />
<pre><br />
M160 S4<br />
G1 X90.6 Y13.8 E2.24:2.24:2.24:15.89<br />
G1 X70.6 E0.0:0.0:0.0:42.4<br />
G1 E42.4:0.0:0.0:0.0<br />
</pre><br />
<br />
:I think that is better. It would seem more logical to use comma (,) to separate items in a list. Now that distances are used instead of ratios, the M160 seems to be redundant. The printer just extrudes whatever is in the E list.<br />
:--[[User:Bobc|Bobc]] ([[User talk:Bobc|talk]]) 16:35, 15 March 2014 (PDT)</div>Bobchttps://reprap.org/mediawiki/index.php?title=Extruder_Expansion_Board&diff=114605Extruder Expansion Board2014-01-07T00:44:29Z<p>Bobc: /* Extruder Expansion Boards */</p>
<hr />
<div>{{Development<br />
<!--Header--><br />
|name = EXT6<br />
|status = Experimental<br />
<!--Image--><br />
|image = RAMPS-FD-EXT6.png<br />
<!--General--><br />
|description = Extruder Expansion Board<br />
|license = GPL<br />
|author = bobc<br />
|reprap = <br />
|categories = [[:Category:Electronics|Electronics]]<br />
|cadModel = KiCAD<br />
|url = [https://github.com/bobc/bobc_hardware/tree/master/RAMPS-FD-EXT github]<br />
}}<br />
=Extruder Expansion Boards=<br />
<br />
<gallery><br />
Image:EXT4.png<br />
Image:RAMPS-FD-EXT6.png<br />
</gallery><br />
<br />
An expansion board to allow additional extruders to be operated.<br />
<br />
There are now two variants : <br />
<br />
* EXT4 supports up to 4 extruders with a direct GPIO interface, does not require firmware change apart from config<br />
* EXT6 supports up to 6 extruders with I2C/SPI interfaces, to make better use of limited IO but requires firmware support<br />
<br />
= EXT4 =<br />
<br />
[[File:EXT4.png|500px]]<br />
<br />
== Prototype ==<br />
Features:<br />
<br />
* slots for 4 stepper driver modules<br />
* 4 thermistor inputs<br />
* 4 MOSFET outputs<br />
* compatible with 3.3V or 5V electronics<br />
* independent stepper drivers, heater control and thermistor inputs<br />
<br />
= EXT6 =<br />
<br />
[[File:RAMPS-FD-EXT6.png|500px]]<br />
<br />
== Bill of Materials ==<br />
To be documented..<br />
<br />
== Prototype ==<br />
Features:<br />
<br />
* slots for 6 stepper driver modules<br />
* 6 thermistor inputs<br />
* 6 MOSFET outputs with PWM control<br />
* fast low latency SPI compatible interface<br />
* interface requires minimum number of pins<br />
* compatible with 3.3V or 5V electronics</div>Bobchttps://reprap.org/mediawiki/index.php?title=Extruder_Expansion_Board&diff=114604Extruder Expansion Board2014-01-07T00:44:13Z<p>Bobc: </p>
<hr />
<div>{{Development<br />
<!--Header--><br />
|name = EXT6<br />
|status = Experimental<br />
<!--Image--><br />
|image = RAMPS-FD-EXT6.png<br />
<!--General--><br />
|description = Extruder Expansion Board<br />
|license = GPL<br />
|author = bobc<br />
|reprap = <br />
|categories = [[:Category:Electronics|Electronics]]<br />
|cadModel = KiCAD<br />
|url = [https://github.com/bobc/bobc_hardware/tree/master/RAMPS-FD-EXT github]<br />
}}<br />
=Extruder Expansion Boards=<br />
<br />
<gallery><br />
Image:EXT4.png<br />
Image:RAMPS-FD-EXT6.png<br />
</gallery><br />
<br />
An expansion board to allow additional extruders to be operated.<br />
<br />
There are now two variants : <br />
<br />
EXT4 supports up to 4 extruders with a direct GPIO interface, does not require firmware change apart from config<br />
EXT6 supports up to 6 extruders with I2C/SPI interfaces, to make better use of limited IO but requires firmware support<br />
<br />
= EXT4 =<br />
<br />
[[File:EXT4.png|500px]]<br />
<br />
== Prototype ==<br />
Features:<br />
<br />
* slots for 4 stepper driver modules<br />
* 4 thermistor inputs<br />
* 4 MOSFET outputs<br />
* compatible with 3.3V or 5V electronics<br />
* independent stepper drivers, heater control and thermistor inputs<br />
<br />
= EXT6 =<br />
<br />
[[File:RAMPS-FD-EXT6.png|500px]]<br />
<br />
== Bill of Materials ==<br />
To be documented..<br />
<br />
== Prototype ==<br />
Features:<br />
<br />
* slots for 6 stepper driver modules<br />
* 6 thermistor inputs<br />
* 6 MOSFET outputs with PWM control<br />
* fast low latency SPI compatible interface<br />
* interface requires minimum number of pins<br />
* compatible with 3.3V or 5V electronics</div>Bobchttps://reprap.org/mediawiki/index.php?title=Extruder_Expansion_Board&diff=114603Extruder Expansion Board2014-01-07T00:38:27Z<p>Bobc: /* Extruder Expansion Boards */</p>
<hr />
<div>{{Development<br />
<!--Header--><br />
|name = EXT6<br />
|status = Experimental<br />
<!--Image--><br />
|image = RAMPS-FD-EXT6.png<br />
<!--General--><br />
|description = Extruder Expansion Board<br />
|license = GPL<br />
|author = bobc<br />
|reprap = <br />
|categories = [[:Category:Electronics|Electronics]]<br />
|cadModel = KiCAD<br />
|url = [https://github.com/bobc/bobc_hardware/tree/master/RAMPS-FD-EXT github]<br />
}}<br />
=Extruder Expansion Boards=<br />
<br />
<gallery><br />
Image:EXT4.png<br />
Image:RAMPS-FD-EXT6.png<br />
</gallery><br />
<br />
An expansion board to allow additional extruders to be operated.<br />
<br />
There are now two variants : <br />
<br />
EXT4 supports up to 4 extruders with a direct GPIO interface, does not require firmware change apart from config<br />
EXT6 supports up to 6 extruders with I2C/SPI interfaces, to make better use of limited IO but requires firmware support<br />
<br />
= EXT4 =<br />
<br />
[[File:EXT4.png]]<br />
<br />
== Prototype ==<br />
Features:<br />
<br />
* slots for 4 stepper driver modules<br />
* 4 thermistor inputs<br />
* 4 MOSFET outputs<br />
* compatible with 3.3V or 5V electronics<br />
* independent stepper drivers, heater control and thermistor inputs<br />
<br />
= EXT6 =<br />
<br />
[[File:RAMPS-FD-EXT6.png]]<br />
<br />
== Bill of Materials ==<br />
To be documented..<br />
<br />
== Prototype ==<br />
Features:<br />
<br />
* slots for 6 stepper driver modules<br />
* 6 thermistor inputs<br />
* 6 MOSFET outputs with PWM control<br />
* fast low latency SPI compatible interface<br />
* interface requires minimum number of pins<br />
* compatible with 3.3V or 5V electronics</div>Bobchttps://reprap.org/mediawiki/index.php?title=Extruder_Expansion_Board&diff=114602Extruder Expansion Board2014-01-07T00:37:56Z<p>Bobc: /* Extruder Expansion Boards */</p>
<hr />
<div>{{Development<br />
<!--Header--><br />
|name = EXT6<br />
|status = Experimental<br />
<!--Image--><br />
|image = RAMPS-FD-EXT6.png<br />
<!--General--><br />
|description = Extruder Expansion Board<br />
|license = GPL<br />
|author = bobc<br />
|reprap = <br />
|categories = [[:Category:Electronics|Electronics]]<br />
|cadModel = KiCAD<br />
|url = [https://github.com/bobc/bobc_hardware/tree/master/RAMPS-FD-EXT github]<br />
}}<br />
=Extruder Expansion Boards=<br />
<br />
<gallery><br />
Image:EXT4.png<br />
Image:RAMPS-FD-EXT.png<br />
</gallery><br />
<br />
An expansion board to allow additional extruders to be operated.<br />
<br />
There are now two variants : <br />
<br />
EXT4 supports up to 4 extruders with a direct GPIO interface, does not require firmware change apart from config<br />
EXT6 supports up to 6 extruders with I2C/SPI interfaces, to make better use of limited IO but requires firmware support<br />
<br />
= EXT4 =<br />
<br />
[[File:EXT4.png]]<br />
<br />
== Prototype ==<br />
Features:<br />
<br />
* slots for 4 stepper driver modules<br />
* 4 thermistor inputs<br />
* 4 MOSFET outputs<br />
* compatible with 3.3V or 5V electronics<br />
* independent stepper drivers, heater control and thermistor inputs<br />
<br />
= EXT6 =<br />
<br />
[[File:RAMPS-FD-EXT6.png]]<br />
<br />
== Bill of Materials ==<br />
To be documented..<br />
<br />
== Prototype ==<br />
Features:<br />
<br />
* slots for 6 stepper driver modules<br />
* 6 thermistor inputs<br />
* 6 MOSFET outputs with PWM control<br />
* fast low latency SPI compatible interface<br />
* interface requires minimum number of pins<br />
* compatible with 3.3V or 5V electronics</div>Bobchttps://reprap.org/mediawiki/index.php?title=File:EXT4.png&diff=114601File:EXT4.png2014-01-07T00:36:46Z<p>Bobc: 4 channel extruder expansion board</p>
<hr />
<div>4 channel extruder expansion board</div>Bobchttps://reprap.org/mediawiki/index.php?title=Extruder_Expansion_Board&diff=114600Extruder Expansion Board2014-01-07T00:35:52Z<p>Bobc: </p>
<hr />
<div>{{Development<br />
<!--Header--><br />
|name = EXT6<br />
|status = Experimental<br />
<!--Image--><br />
|image = RAMPS-FD-EXT6.png<br />
<!--General--><br />
|description = Extruder Expansion Board<br />
|license = GPL<br />
|author = bobc<br />
|reprap = <br />
|categories = [[:Category:Electronics|Electronics]]<br />
|cadModel = KiCAD<br />
|url = [https://github.com/bobc/bobc_hardware/tree/master/RAMPS-FD-EXT github]<br />
}}<br />
=Extruder Expansion Boards=<br />
<br />
An expansion board to allow additional extruders to be operated.<br />
<br />
There are now two variants : <br />
<br />
EXT4 supports up to 4 extruders with a direct GPIO interface, does not require firmware change apart from config<br />
EXT6 supports up to 6 extruders with I2C/SPI interfaces, to make better use of limited IO but requires firmware support<br />
<br />
= EXT4 =<br />
<br />
[[File:EXT4.png]]<br />
<br />
== Prototype ==<br />
Features:<br />
<br />
* slots for 4 stepper driver modules<br />
* 4 thermistor inputs<br />
* 4 MOSFET outputs<br />
* compatible with 3.3V or 5V electronics<br />
* independent stepper drivers, heater control and thermistor inputs<br />
<br />
= EXT6 =<br />
<br />
[[File:RAMPS-FD-EXT6.png]]<br />
<br />
== Bill of Materials ==<br />
To be documented..<br />
<br />
== Prototype ==<br />
Features:<br />
<br />
* slots for 6 stepper driver modules<br />
* 6 thermistor inputs<br />
* 6 MOSFET outputs with PWM control<br />
* fast low latency SPI compatible interface<br />
* interface requires minimum number of pins<br />
* compatible with 3.3V or 5V electronics</div>Bobchttps://reprap.org/mediawiki/index.php?title=Talk:G-code&diff=114016Talk:G-code2013-12-30T16:07:09Z<p>Bobc: /* Time for G-code V2 */</p>
<hr />
<div>==M104 & M109 Deprecation, G10 Introduction==<br />
<br />
No issues with deprecating M109, as this is an equivalent to M104 & M116. But M104? [heated bed (M140) example deleted]<br />
<br />
I consider G10 head/tool offset a good idea, but temperatures should be set by it's own command. Also, one often sets a temperature only, keeping the geometrical offset.<br />
<br />
If the L value is ignored, why is it part of the specification?<br />
<br />
Last not least, Marlin people already defined [[G-code#M206:_set_home_offset | M206]] for the head offset. These two should be aligned.<br />
<br />
--[[User:Traumflug|Traumflug]] 11:28, 19 July 2012 (UTC)<br />
<br />
M140 seems unaffected, Traumflug, so you can set the bed temp without changes.<br />
That said, I don't like any of this one bit. I don't like that the fast temp setting is gone, and I don't like that mysterious temperatures come out of nowhere when switching tool.<br />
I'd much prefer G10 to deal with spatial offset only, and use M10{4|9} [T0] S200. It gives the gcode generator much more control over the process. Having an OPTIONAL temperature setting in G10 would be acceptable for me, but definitely not deprecating M104/M109<br />
<br />
--Kliment<br />
<br />
I don't quite see why temperature offsets are different from spatial offsets - it's just another dimension in which the machine operates. It seemed neater to me to set them all in one place. And temperatures don't come out of nowhere - they are values you have previously explicitly set...<br />
<br />
Jean-Marc pointed out that it would be useful to have an option to save and load this stuff from eeprom like Marlin with M500 - that way you could have slightly different offsets for different machines and still run them all off the same G Code file.<br />
<br />
I agree that M104 is useful as it allows you:<br />
<br />
#to set temp and return<br />
#to do stuff you know doesn't involve extruding<br />
#to set same temp and wait<br />
<br />
Which speeds things up a bit at the start of a print. I'm not quite sure what we should do about that.<br />
<br />
As there is a standard (G10) for setting offset that pre-dates the invention of 3D printing, I think that's preferable to M206.<br />
<br />
Finally - remember that the time interval between something being deprecated and something going away altogether can be arbitrarily long, and is entirely in the hands of people writing firmware :-)<br />
<br />
- Adrian<br />
<br />
<br />
I have no problem introducing a new command which is a superset of existing functionality, and even better if it is more standard compliant, but I can't see a good reason to remove the previous commands, as there is no conflict in functionality. Presumably if G10 returns an error, then the host must fall back to previous commands. <br />
<br />
I don't know which standard you are looking at, but in mine (the official NIST standard) G10 does not set tool offsets. It appears some software out there is using a different, non-standard meaning for G10. I don't think non-standard use by one or more applications creates "a standard". Our use of G10 also has quite different parameters. This proposal would appear to be replacing non-standard command(s) with a new non-standard command, which doesn't help standardization and breaks compatibility. <br />
<br />
--[[User:Bobc|Bobc]] 21:41, 30 July 2012 (UTC)<br />
<br />
<br />
Thanks for the comments so far. I see we agree on M109 being obsolete, so I've removed the discussion tag.<br />
<br />
Regarding the [http://www.nist.gov/customcf/get_pdf.cfm?pub_id=823374 NIST standard], G10 is described there as setting a coordinate system, so it's similar to setting a tool offset.<br />
<br />
Not a word there on what L does, though. So I reduced it's description.<br />
<br />
What's left is R and S, the standby and work temperatures. How about making them optional?<br />
* Without R and S, both default to zero, so we have the (former) behaviour without G10.<br />
* With R and/or S, temperatures are set at tool change time (T, M6 command).<br />
* M104 always sets the temperature of the current extruder. So it matches traditional behaviour in case R and S weren't used. In case R and/or S are used, M104 overrides the extruder's work temperature, but doesn't change the extruder's S setting.<br />
--[[User:Traumflug|Traumflug]] 22:22, 31 July 2012 (UTC)<br />
<br />
<br />
I don't see the same agreement on M109 that you do, unless you are ignoring specific objections.<br />
<br />
I did a little digging, it appears the L parameter selects a "parameter number". So in NIST, L2 means "set coordinate system". FANUC systems use versions of G10 as "set tool offsets", sometimes L1, L10 or L12, sometimes omitted. Other L numbers may set other parameters, depending on machine. LinuxCNC appears to support several values of L. If we are using the parameters to mean something different (e.g R parameter is not used to define cutter radius), we should probably pick something like L3.<br />
<br />
Ref [http://www.linuxcnc.org/docs/devel/html/gcode/gcode.html#_g10_l1_set_tool_table_a_id_sec_g10_l1_a LinuxCNC G Codes]<br />
<br />
--[[User:Bobc|Bobc]] 08:02, 4 August 2012 (UTC)<br />
<br />
<br />
Did I miss something? I see no vote for M109, just a combined one for M104/M109. How to replace M109 by M104 is described.<br />
<br />
So, the L parameter is sort of a sub-command on a number of other, non RepRap G-code interpreters. Thanks a lot for the digging. Does that make the current description of the RepRap G-code flavour wrong? I think it's sufficient to describe what a RepRap firmware does, elaborating on what others do should go to something like a "G-code in General" wiki page.<br />
<br />
--[[User:Traumflug|Traumflug]] 10:45, 4 August 2012 (UTC)<br />
<br />
Has anyone implemented G10 in either a slicer or a firmware in the way described on the wiki? I am depending on M109s and M104s in prontserve to send the target temperature events but I can add G10 as well if this is actually used somewhere. Marlin seems to use it as a retract command (see https://github.com/ErikZalm/Marlin/blob/Marlin_v1/Marlin/Marlin_main.cpp#L771 ) and I guess I can just go off that.<br />
<br />
TL;DR This is very unclear to me. This needs documentation.<br />
<br />
--[[User:TheOtherRob|TheOtherRob]] 03:37, 27 June 2013 (UTC) (d1plo1d on github)<br />
<br />
==Checking==<br />
<br />
"These are the line number and the checksum. The RepRap firmware checks the checksum against a locally-computed value and, if they differ, requests a repeat transmission of the line of the given number. "<br />
<br />
Surely the firmware must request resending of the ''expected'' number, not the given number in the line. If the checksum is wrong, then the firmware should not rely on the line being correct, including the N value. The same goes for valid checksum but line number out of sequence, the algorithm as stated will keep requesting the same line!<br />
<br />
--[[User:Bobc|Bobc]] 21:41, 30 July 2012 (UTC)<br />
<br />
==Other stuff==<br />
<br />
Ah excellent, I've been waiting for this! I've been working from the gcode and mcode pages in the old wiki which have a few holes.<br />
<br />
The line number and checksum stuff is new to me- I'll implement that into my firmware in the coming days. So are some of these M-codes for that matter.<br />
<br />
Can we add some sort of reference for what the host expects in response from the firmware? So far, I'm sending back OK when the command is queued or executed and T: nnn every second when the heater is on, which as far as I can tell is all that's needed.<br />
<br />
ps: why are G20/G21/G90/G91/G92 specified to block? ("''The following commands are not buffered. When one is received it is stored, but it is not acknowledged to the host until the buffer is exhausted and then the command has been executed.''") they simply alter the conversion factors for the next command received in my firmware, and so can respond OK immediately.<br />
<br />
Only G4 (dwell) and M101 (start extruder when up to temperature, apparently superceded by the new M109) block in my firmware at the moment, and I'm seriously considering making even these queue-able so they block the queue instead of the command download stream.<br />
<br />
-- [[User:Triffid_hunter|Triffid Hunter]]<br />
<br />
<br />
I agree. It's great for this to be documented.<br />
<br />
I had one suggestion on the checksum -- it should perhaps use a stronger CRC checksum, and should also encorporate the length as well? Is the N and * part of an external standard, or a RepRap special sauce?<br />
<br />
If they are RepRap specific, I'd suggest changing the N code to include line length as something like "N101.50" for line 101, consisting of 50 characters.<br />
<br />
I use the following CRC algorithm, which I believe I stole from the CCITT standard:<br />
<br />
<pre><br />
static inline uint16_t GetCRC( uint16_t crc, char ser_data )<br />
{<br />
crc = (unsigned char)(crc >> 8) | (crc << 8);<br />
crc ^= ser_data;<br />
crc ^= (unsigned char)(crc & 0xff) >> 4;<br />
crc ^= (crc << 8) << 4;<br />
crc ^= ((crc & 0xff) << 4) << 1;<br />
return crc;<br />
}<br />
</pre><br />
<br />
The logic to compute checksum would then become:<br />
<br />
<pre><br />
uint16_t cs = 0;<br />
for(int i = 0; i < cmd.length(); i++)<br />
cs = GetCRC( cs, cmd.charAt(i) );<br />
<br />
computedCrc = cs;<br />
</pre><br />
<br />
So, the full logic for accepting or testing a line, encoded with full N and CRC checksum would be something like:<br />
<br />
<pre><br />
// was line number and checksum provided?<br />
bool value = true;<br />
if( lineNumber != 0 )<br />
{<br />
valid = lineNumber == expectedLineNumber<br />
&& cmd.length() == providedLength<br />
&& computedCrc == providedCrc;<br />
}<br />
<br />
// accept or reject the line based on valid flag<br />
<br />
</pre><br />
<br />
This does add a few bytes of overhead (3-4 for length, 2-3 for 16 bit crc), but may be worth it allows you to run a higher baud rate with reasonably low error rates -- the odds of a false positive are near enough to zero to make any statistician happy.<br />
<br />
-- [[User:BeagleFury|BeagleFury]]<br />
<br />
Just wanted to chime in - Thanks Adrian! This answers many questions for me!<br />
-- [[User:Wade|Wade]]<br />
<br />
== what part of the line does cmd.length() refer to? ==<br />
<br />
Just trying to implement the checksum logic, and realised that it makes no sense for the checksum to include itself or things get very recursive. What point is considered end-of-line? is it the asterisk? the space before the asterisk? the last non-whitespace before the asterisk?<br />
<br />
My firmware doesn't buffer the line, rather processes it character by character so this has to become another special case.<br />
<br />
-- [[User:Triffid_hunter|Triffid Hunter]]<br />
<br />
The checksum includes all characters in the string up to and including the character before the asterisk (i.e. up to but not including the asterisk). -- [[User:neilrqm|neilrqm]]<br />
<br />
== Future-proof M-codes? ==<br />
<br />
Adding new M-codes for extra sensors/heaters seems a little non-future-proof to me. My firmware uses P parameter to know which sensor/heater is being referred to eg M104 S100 sets heater 0 to 100c, but M104 P2 S100 sets heater 2 to 100c. Same for all the temperature sensor readback stuff. Future proofing protocols is always a good idea :)<br />
<br />
== G91: Set to Relative Positioning ==<br />
<br />
Example: G91<br />
All coordinates from now on are relative to the last position.<br />
<br />
Question: does this include the feed rate?<br />
<br />
-- [[User:Pietr]]<br />
<br />
== M203: Record Z adjustment ==<br />
<br />
which firmware does this?<br />
<br />
Sprinter Main does not have M203 implimented<br />
Sprinter Experimental has M203 as "M203 Temperature monitor for Repetier"<br />
Repetier has M203 as Temperaturmonitor.<br />
Marlin has M203 - Set maximum feedrate that your machine can sustain (M203 X200 Y200 Z300 E10000) in mm/sec<br />
Teacup has no M203<br />
<br />
Does any current or experimental firmware have the z adjustment implimented?<br />
<br />
eMAKER Sprinter used this. but is now deprecated in favour of Marlin.<br />
<br />
-- [[User:jmgiacalone|jmgiacalone]]<br />
<br />
== M92: Set axis_steps_per_unit ==<br />
<br />
M92 Sets the number of steps per unit, this is GREAT to fine tuning the extruder head, where even different colors of the same filament act differently, even when the measured diameter is measured precisely. It's simple enough to calibrate this using a simple cube alternating layers between 100% infill and 95% infill and adjusting the E steps per mm to not show gaps on the 100% layers and to just barely show gaps on the 95% layers.<br />
<br />
M92 is much better for compensating for different filament than putting it in the slicer program, because you might want to run the same program with different colors.. even within the same job, perhaps one would want to pause the program during a non critical infill, remove the filament, put in a different color, and then continue.. if you had previously calibrated all your filaments and got accurate steps per mm of those filaments, you can simply issue a M92 for the filament you just installed, then when you continue the program, the extruder will be working correctly.<br />
<br />
The problem I find is that I don't know what number to start putting in there.. it is listed in config.h, however that can be overridden if the eeprom is activated. I notice that M99: Set axis_hysteresis_mm has a corresponding M98: Get axis_hysteresis_mm why not have an M91: Get axis_steps_per_unit. Then there would be no mucking about in code trying to figure out what the extruder is currently set at, and it would make it MUCH easier for people who bought kit machines who really don't understand the code to be able to calibrate the extruder head.<br />
=== EEPROM gcodes ===<br />
<br />
It would be great if there were such a gcode function since still at the time of writing the retailer at least aught to point the client in the right direction for resources on the subject. Which unfortunately very few seems to actually do and the client remains restrained as a consumer instead of as advertised an step towards a emancipated maker through educational resources on settings/calibration, but also inspirational homage dito, to use the tool efficiently as well as with heart. Thankfully there are initiatives such as FSF's "[http://www.fsf.org/resources/hw/endorsement/respects-your-freedom Respects Your Freedom hardware product certification]", which one can easily endorse especially in times were companies [[Replicator_2_Controversy|reap]] but, more importantly do not [[Neutering a RepRap|sow]].<br />
<br />
Anyhow, there are some [[G-code#Proposed_EEPROM_configuration_codes|Proposed EEPROM configuration codes]] which marlin, sprinter, teacup et al firmwares uses. But needless to say, all of these depend on that one enabled the feature in the configuration pages and beyond that a friendly GUI, which [[repetier host]] is the only alternative (so far) when it comes to "easy to use point and click"-settings.<br />
<br />
: For Teacup firmware EECONFIG is enabled by default, so there is no need for enabling anything. And you guessed it, quite some retailers have no idea of what they're selling. This is a consequence of RepRap putting so much emphasis on being open source ( = zero pay for developers) and cheering commercial shops ( = all money goes to the shops). So, I see no point in complaining about "retailers". It's what RepRap asks for. --[[User:Traumflug|Traumflug]] 12:07, 6 December 2012 (UTC)<br />
<br />
== Time for G-code V2 ==<br />
<br />
Is it time to rewrite this G-code specification, maybe call it version 2, or a more creative naming variant? The current specification is a kludge going back many years and authors. The ACK specification is inconsistent. There is no formal language specification, so new language features get added and "do their best to follow existing standards" - standards which aren't actually defined. Different firmwares provide variants on the specification here, but again there's no standard for them to follow, or way to define their variant so control software programmers can adjust easily and confidently.<br />
<br />
# Let's discuss a roadmap and milestones for such an effort.<br />
# Let's create a specification in a formalized notation so non-english speakers don't need a translator to read it.<br />
# Let's formalize our 3D printer G-code variant by writing it in Backus–Naur Form. Indeed this may scare some cooks out of the kitchen...I doubt it...but if they are, maybe that's good.<br />
# Let's get a standard and consistent ACK<br />
# Let's discuss and find ways to improve the ACK to make things easier for control software<br />
# Let's not leave slots for "forwards compatibility". Instead, let's recommend (or specify) how to extend the specification we create.<br />
# Let's create a consistent ACK specification. The current one is inconsistent. Take, for example, the wait commands. Rather than send an OK as response to the command, the spec. allows firmwares to send other data - such as the current temp readings (w/targets) - and it can easily take up to 600 seconds for control software to receive "OK" while it was processing kilobytes of response data.<br />
# Let's address how commands are buffered. For example, it might make sense to specify that upon receiving a buffered command, an ACK is sent in response that indicates the command was buffered - or more importantly which command was buffered.<br />
# Let's create a standard way for firmwares to identify themselves, and their capabilities.<br />
<br />
Here's a G-Code example per this spec. from Marlin that exposes fundamental issues:<br />
<pre><br />
Send: M104 S1900<br />
Recv: ok T:28.1 /1900.0 B:59.8 /60.0 @:127 B@:0<br />
Recv: ok T:29.2 /1900.0 B:59.9 /60.0 @:127 B@:0<br />
Recv: ok T:31.3 /1900.0 B:59.9 /60.0 @:127 B@:0<br />
Recv: ok T:32.0 /1900.0 B:60.0 /60.0 @:127 B@:0<br />
...<br />
...<br />
Error:0<br />
: Extruder switched off. MAXTEMP triggered !<br />
Error: Printer stopped deu to errors. Fix the error and use M999 to restart!. (Temperature is reset. Set it before restarting)<br />
</pre><br />
<br />
A similar scenario is encountered when setting the bed temp. According to the spec we expect a similar result for a target < MINTEMP - possibly permuting this (poor) specification outcome to at least 4 use-cases.<br />
<br />
The command M104 S1900 asks the printer to destroy a typical reprap hotend. It would be trivial to specify how to respond with an error msg. for an out-of-range temp. request immediately, not when hitting MAXTEMP. Same for MINTEMP if that's the case. However, the current spec. does not provide a way to ACK with a standard error msg. In fact, it ''does not provide a standard ACK format'', it just illustrates what certain firmwares do in their ACKs.<br />
<br />
(Anonymous user?)<br />
<br />
: I am still waiting for a G-Code V1!<br />
: The problem is not lack of a standard, but that people just don't want to follow specs. There is a good NIST G-code spec, but no one followed that. New G-code features are hacked in arbitrarily, and this is the case from Day 1, where the "spec" was whatever the first firmware written happened to do. By it's nature, a wiki based spec is a free for all. <br />
:There are some elements of what you suggest already, but getting an encompassing spec written is unlikely to happen, unless someone volunteers to do it. You might get further if you make some specific suggestions regarding ACKs say, and add that as a "Proposed .." section. Really, the only thing you can do is to design something better and hope people will use it.<br />
:Also please sign so we know who we are talking to :)<br />
:--[[User:Bobc|Bobc]] ([[User talk:Bobc|talk]]) 08:05, 30 December 2013 (PST)</div>Bobchttps://reprap.org/mediawiki/index.php?title=Talk:G-code&diff=114015Talk:G-code2013-12-30T16:05:14Z<p>Bobc: /* Time for G-code V2 */</p>
<hr />
<div>==M104 & M109 Deprecation, G10 Introduction==<br />
<br />
No issues with deprecating M109, as this is an equivalent to M104 & M116. But M104? [heated bed (M140) example deleted]<br />
<br />
I consider G10 head/tool offset a good idea, but temperatures should be set by it's own command. Also, one often sets a temperature only, keeping the geometrical offset.<br />
<br />
If the L value is ignored, why is it part of the specification?<br />
<br />
Last not least, Marlin people already defined [[G-code#M206:_set_home_offset | M206]] for the head offset. These two should be aligned.<br />
<br />
--[[User:Traumflug|Traumflug]] 11:28, 19 July 2012 (UTC)<br />
<br />
M140 seems unaffected, Traumflug, so you can set the bed temp without changes.<br />
That said, I don't like any of this one bit. I don't like that the fast temp setting is gone, and I don't like that mysterious temperatures come out of nowhere when switching tool.<br />
I'd much prefer G10 to deal with spatial offset only, and use M10{4|9} [T0] S200. It gives the gcode generator much more control over the process. Having an OPTIONAL temperature setting in G10 would be acceptable for me, but definitely not deprecating M104/M109<br />
<br />
--Kliment<br />
<br />
I don't quite see why temperature offsets are different from spatial offsets - it's just another dimension in which the machine operates. It seemed neater to me to set them all in one place. And temperatures don't come out of nowhere - they are values you have previously explicitly set...<br />
<br />
Jean-Marc pointed out that it would be useful to have an option to save and load this stuff from eeprom like Marlin with M500 - that way you could have slightly different offsets for different machines and still run them all off the same G Code file.<br />
<br />
I agree that M104 is useful as it allows you:<br />
<br />
#to set temp and return<br />
#to do stuff you know doesn't involve extruding<br />
#to set same temp and wait<br />
<br />
Which speeds things up a bit at the start of a print. I'm not quite sure what we should do about that.<br />
<br />
As there is a standard (G10) for setting offset that pre-dates the invention of 3D printing, I think that's preferable to M206.<br />
<br />
Finally - remember that the time interval between something being deprecated and something going away altogether can be arbitrarily long, and is entirely in the hands of people writing firmware :-)<br />
<br />
- Adrian<br />
<br />
<br />
I have no problem introducing a new command which is a superset of existing functionality, and even better if it is more standard compliant, but I can't see a good reason to remove the previous commands, as there is no conflict in functionality. Presumably if G10 returns an error, then the host must fall back to previous commands. <br />
<br />
I don't know which standard you are looking at, but in mine (the official NIST standard) G10 does not set tool offsets. It appears some software out there is using a different, non-standard meaning for G10. I don't think non-standard use by one or more applications creates "a standard". Our use of G10 also has quite different parameters. This proposal would appear to be replacing non-standard command(s) with a new non-standard command, which doesn't help standardization and breaks compatibility. <br />
<br />
--[[User:Bobc|Bobc]] 21:41, 30 July 2012 (UTC)<br />
<br />
<br />
Thanks for the comments so far. I see we agree on M109 being obsolete, so I've removed the discussion tag.<br />
<br />
Regarding the [http://www.nist.gov/customcf/get_pdf.cfm?pub_id=823374 NIST standard], G10 is described there as setting a coordinate system, so it's similar to setting a tool offset.<br />
<br />
Not a word there on what L does, though. So I reduced it's description.<br />
<br />
What's left is R and S, the standby and work temperatures. How about making them optional?<br />
* Without R and S, both default to zero, so we have the (former) behaviour without G10.<br />
* With R and/or S, temperatures are set at tool change time (T, M6 command).<br />
* M104 always sets the temperature of the current extruder. So it matches traditional behaviour in case R and S weren't used. In case R and/or S are used, M104 overrides the extruder's work temperature, but doesn't change the extruder's S setting.<br />
--[[User:Traumflug|Traumflug]] 22:22, 31 July 2012 (UTC)<br />
<br />
<br />
I don't see the same agreement on M109 that you do, unless you are ignoring specific objections.<br />
<br />
I did a little digging, it appears the L parameter selects a "parameter number". So in NIST, L2 means "set coordinate system". FANUC systems use versions of G10 as "set tool offsets", sometimes L1, L10 or L12, sometimes omitted. Other L numbers may set other parameters, depending on machine. LinuxCNC appears to support several values of L. If we are using the parameters to mean something different (e.g R parameter is not used to define cutter radius), we should probably pick something like L3.<br />
<br />
Ref [http://www.linuxcnc.org/docs/devel/html/gcode/gcode.html#_g10_l1_set_tool_table_a_id_sec_g10_l1_a LinuxCNC G Codes]<br />
<br />
--[[User:Bobc|Bobc]] 08:02, 4 August 2012 (UTC)<br />
<br />
<br />
Did I miss something? I see no vote for M109, just a combined one for M104/M109. How to replace M109 by M104 is described.<br />
<br />
So, the L parameter is sort of a sub-command on a number of other, non RepRap G-code interpreters. Thanks a lot for the digging. Does that make the current description of the RepRap G-code flavour wrong? I think it's sufficient to describe what a RepRap firmware does, elaborating on what others do should go to something like a "G-code in General" wiki page.<br />
<br />
--[[User:Traumflug|Traumflug]] 10:45, 4 August 2012 (UTC)<br />
<br />
Has anyone implemented G10 in either a slicer or a firmware in the way described on the wiki? I am depending on M109s and M104s in prontserve to send the target temperature events but I can add G10 as well if this is actually used somewhere. Marlin seems to use it as a retract command (see https://github.com/ErikZalm/Marlin/blob/Marlin_v1/Marlin/Marlin_main.cpp#L771 ) and I guess I can just go off that.<br />
<br />
TL;DR This is very unclear to me. This needs documentation.<br />
<br />
--[[User:TheOtherRob|TheOtherRob]] 03:37, 27 June 2013 (UTC) (d1plo1d on github)<br />
<br />
==Checking==<br />
<br />
"These are the line number and the checksum. The RepRap firmware checks the checksum against a locally-computed value and, if they differ, requests a repeat transmission of the line of the given number. "<br />
<br />
Surely the firmware must request resending of the ''expected'' number, not the given number in the line. If the checksum is wrong, then the firmware should not rely on the line being correct, including the N value. The same goes for valid checksum but line number out of sequence, the algorithm as stated will keep requesting the same line!<br />
<br />
--[[User:Bobc|Bobc]] 21:41, 30 July 2012 (UTC)<br />
<br />
==Other stuff==<br />
<br />
Ah excellent, I've been waiting for this! I've been working from the gcode and mcode pages in the old wiki which have a few holes.<br />
<br />
The line number and checksum stuff is new to me- I'll implement that into my firmware in the coming days. So are some of these M-codes for that matter.<br />
<br />
Can we add some sort of reference for what the host expects in response from the firmware? So far, I'm sending back OK when the command is queued or executed and T: nnn every second when the heater is on, which as far as I can tell is all that's needed.<br />
<br />
ps: why are G20/G21/G90/G91/G92 specified to block? ("''The following commands are not buffered. When one is received it is stored, but it is not acknowledged to the host until the buffer is exhausted and then the command has been executed.''") they simply alter the conversion factors for the next command received in my firmware, and so can respond OK immediately.<br />
<br />
Only G4 (dwell) and M101 (start extruder when up to temperature, apparently superceded by the new M109) block in my firmware at the moment, and I'm seriously considering making even these queue-able so they block the queue instead of the command download stream.<br />
<br />
-- [[User:Triffid_hunter|Triffid Hunter]]<br />
<br />
<br />
I agree. It's great for this to be documented.<br />
<br />
I had one suggestion on the checksum -- it should perhaps use a stronger CRC checksum, and should also encorporate the length as well? Is the N and * part of an external standard, or a RepRap special sauce?<br />
<br />
If they are RepRap specific, I'd suggest changing the N code to include line length as something like "N101.50" for line 101, consisting of 50 characters.<br />
<br />
I use the following CRC algorithm, which I believe I stole from the CCITT standard:<br />
<br />
<pre><br />
static inline uint16_t GetCRC( uint16_t crc, char ser_data )<br />
{<br />
crc = (unsigned char)(crc >> 8) | (crc << 8);<br />
crc ^= ser_data;<br />
crc ^= (unsigned char)(crc & 0xff) >> 4;<br />
crc ^= (crc << 8) << 4;<br />
crc ^= ((crc & 0xff) << 4) << 1;<br />
return crc;<br />
}<br />
</pre><br />
<br />
The logic to compute checksum would then become:<br />
<br />
<pre><br />
uint16_t cs = 0;<br />
for(int i = 0; i < cmd.length(); i++)<br />
cs = GetCRC( cs, cmd.charAt(i) );<br />
<br />
computedCrc = cs;<br />
</pre><br />
<br />
So, the full logic for accepting or testing a line, encoded with full N and CRC checksum would be something like:<br />
<br />
<pre><br />
// was line number and checksum provided?<br />
bool value = true;<br />
if( lineNumber != 0 )<br />
{<br />
valid = lineNumber == expectedLineNumber<br />
&& cmd.length() == providedLength<br />
&& computedCrc == providedCrc;<br />
}<br />
<br />
// accept or reject the line based on valid flag<br />
<br />
</pre><br />
<br />
This does add a few bytes of overhead (3-4 for length, 2-3 for 16 bit crc), but may be worth it allows you to run a higher baud rate with reasonably low error rates -- the odds of a false positive are near enough to zero to make any statistician happy.<br />
<br />
-- [[User:BeagleFury|BeagleFury]]<br />
<br />
Just wanted to chime in - Thanks Adrian! This answers many questions for me!<br />
-- [[User:Wade|Wade]]<br />
<br />
== what part of the line does cmd.length() refer to? ==<br />
<br />
Just trying to implement the checksum logic, and realised that it makes no sense for the checksum to include itself or things get very recursive. What point is considered end-of-line? is it the asterisk? the space before the asterisk? the last non-whitespace before the asterisk?<br />
<br />
My firmware doesn't buffer the line, rather processes it character by character so this has to become another special case.<br />
<br />
-- [[User:Triffid_hunter|Triffid Hunter]]<br />
<br />
The checksum includes all characters in the string up to and including the character before the asterisk (i.e. up to but not including the asterisk). -- [[User:neilrqm|neilrqm]]<br />
<br />
== Future-proof M-codes? ==<br />
<br />
Adding new M-codes for extra sensors/heaters seems a little non-future-proof to me. My firmware uses P parameter to know which sensor/heater is being referred to eg M104 S100 sets heater 0 to 100c, but M104 P2 S100 sets heater 2 to 100c. Same for all the temperature sensor readback stuff. Future proofing protocols is always a good idea :)<br />
<br />
== G91: Set to Relative Positioning ==<br />
<br />
Example: G91<br />
All coordinates from now on are relative to the last position.<br />
<br />
Question: does this include the feed rate?<br />
<br />
-- [[User:Pietr]]<br />
<br />
== M203: Record Z adjustment ==<br />
<br />
which firmware does this?<br />
<br />
Sprinter Main does not have M203 implimented<br />
Sprinter Experimental has M203 as "M203 Temperature monitor for Repetier"<br />
Repetier has M203 as Temperaturmonitor.<br />
Marlin has M203 - Set maximum feedrate that your machine can sustain (M203 X200 Y200 Z300 E10000) in mm/sec<br />
Teacup has no M203<br />
<br />
Does any current or experimental firmware have the z adjustment implimented?<br />
<br />
eMAKER Sprinter used this. but is now deprecated in favour of Marlin.<br />
<br />
-- [[User:jmgiacalone|jmgiacalone]]<br />
<br />
== M92: Set axis_steps_per_unit ==<br />
<br />
M92 Sets the number of steps per unit, this is GREAT to fine tuning the extruder head, where even different colors of the same filament act differently, even when the measured diameter is measured precisely. It's simple enough to calibrate this using a simple cube alternating layers between 100% infill and 95% infill and adjusting the E steps per mm to not show gaps on the 100% layers and to just barely show gaps on the 95% layers.<br />
<br />
M92 is much better for compensating for different filament than putting it in the slicer program, because you might want to run the same program with different colors.. even within the same job, perhaps one would want to pause the program during a non critical infill, remove the filament, put in a different color, and then continue.. if you had previously calibrated all your filaments and got accurate steps per mm of those filaments, you can simply issue a M92 for the filament you just installed, then when you continue the program, the extruder will be working correctly.<br />
<br />
The problem I find is that I don't know what number to start putting in there.. it is listed in config.h, however that can be overridden if the eeprom is activated. I notice that M99: Set axis_hysteresis_mm has a corresponding M98: Get axis_hysteresis_mm why not have an M91: Get axis_steps_per_unit. Then there would be no mucking about in code trying to figure out what the extruder is currently set at, and it would make it MUCH easier for people who bought kit machines who really don't understand the code to be able to calibrate the extruder head.<br />
=== EEPROM gcodes ===<br />
<br />
It would be great if there were such a gcode function since still at the time of writing the retailer at least aught to point the client in the right direction for resources on the subject. Which unfortunately very few seems to actually do and the client remains restrained as a consumer instead of as advertised an step towards a emancipated maker through educational resources on settings/calibration, but also inspirational homage dito, to use the tool efficiently as well as with heart. Thankfully there are initiatives such as FSF's "[http://www.fsf.org/resources/hw/endorsement/respects-your-freedom Respects Your Freedom hardware product certification]", which one can easily endorse especially in times were companies [[Replicator_2_Controversy|reap]] but, more importantly do not [[Neutering a RepRap|sow]].<br />
<br />
Anyhow, there are some [[G-code#Proposed_EEPROM_configuration_codes|Proposed EEPROM configuration codes]] which marlin, sprinter, teacup et al firmwares uses. But needless to say, all of these depend on that one enabled the feature in the configuration pages and beyond that a friendly GUI, which [[repetier host]] is the only alternative (so far) when it comes to "easy to use point and click"-settings.<br />
<br />
: For Teacup firmware EECONFIG is enabled by default, so there is no need for enabling anything. And you guessed it, quite some retailers have no idea of what they're selling. This is a consequence of RepRap putting so much emphasis on being open source ( = zero pay for developers) and cheering commercial shops ( = all money goes to the shops). So, I see no point in complaining about "retailers". It's what RepRap asks for. --[[User:Traumflug|Traumflug]] 12:07, 6 December 2012 (UTC)<br />
<br />
== Time for G-code V2 ==<br />
<br />
Is it time to rewrite this G-code specification, maybe call it version 2, or a more creative naming variant? The current specification is a kludge going back many years and authors. The ACK specification is inconsistent. There is no formal language specification, so new language features get added and "do their best to follow existing standards" - standards which aren't actually defined. Different firmwares provide variants on the specification here, but again there's no standard for them to follow, or way to define their variant so control software programmers can adjust easily and confidently.<br />
<br />
# Let's discuss a roadmap and milestones for such an effort.<br />
# Let's create a specification in a formalized notation so non-english speakers don't need a translator to read it.<br />
# Let's formalize our 3D printer G-code variant by writing it in Backus–Naur Form. Indeed this may scare some cooks out of the kitchen...I doubt it...but if they are, maybe that's good.<br />
# Let's get a standard and consistent ACK<br />
# Let's discuss and find ways to improve the ACK to make things easier for control software<br />
# Let's not leave slots for "forwards compatibility". Instead, let's recommend (or specify) how to extend the specification we create.<br />
# Let's create a consistent ACK specification. The current one is inconsistent. Take, for example, the wait commands. Rather than send an OK as response to the command, the spec. allows firmwares to send other data - such as the current temp readings (w/targets) - and it can easily take up to 600 seconds for control software to receive "OK" while it was processing kilobytes of response data.<br />
# Let's address how commands are buffered. For example, it might make sense to specify that upon receiving a buffered command, an ACK is sent in response that indicates the command was buffered - or more importantly which command was buffered.<br />
# Let's create a standard way for firmwares to identify themselves, and their capabilities.<br />
<br />
Here's a G-Code example per this spec. from Marlin that exposes fundamental issues:<br />
<pre><br />
Send: M104 S1900<br />
Recv: ok T:28.1 /1900.0 B:59.8 /60.0 @:127 B@:0<br />
Recv: ok T:29.2 /1900.0 B:59.9 /60.0 @:127 B@:0<br />
Recv: ok T:31.3 /1900.0 B:59.9 /60.0 @:127 B@:0<br />
Recv: ok T:32.0 /1900.0 B:60.0 /60.0 @:127 B@:0<br />
...<br />
...<br />
Error:0<br />
: Extruder switched off. MAXTEMP triggered !<br />
Error: Printer stopped deu to errors. Fix the error and use M999 to restart!. (Temperature is reset. Set it before restarting)<br />
</pre><br />
<br />
A similar scenario is encountered when setting the bed temp. According to the spec we expect a similar result for a target < MINTEMP - possibly permuting this (poor) specification outcome to at least 4 use-cases.<br />
<br />
The command M104 S1900 asks the printer to destroy a typical reprap hotend. It would be trivial to specify how to respond with an error msg. for an out-of-range temp. request immediately, not when hitting MAXTEMP. Same for MINTEMP if that's the case. However, the current spec. does not provide a way to ACK with a standard error msg. In fact, it ''does not provide a standard ACK format'', it just illustrates what certain firmwares do in their ACKs.<br />
<br />
(Anonymous user?)<br />
<br />
: I am still waiting for a G-Code V1!<br />
: The problem is not lack of a standard, but that people just don't want to follow specs. There is a good NIST G-code spec, but no one followed that. New G-code features are hacked in arbitrarily, and this is the case from Day 1, where the "spec" was whatever the first firmware written happened to do. By it's nature, a wiki based spec is a free for all. <br />
:There are some elements of what you suggest already, but getting an encompassing spec written is unlikely to happen, unless someone volunteers to do it. You might get further if you make some specific suggestions regarding ACKs say, and add that as a "Proposed .." section. Really, the only thing you can do is to design something better and hope people will use it.<br />
:Also please sign so we know who we are talking to :)<br />
:[[User:Bobc|Bobc]] ([[User talk:Bobc|talk]]) 08:05, 30 December 2013 (PST)</div>Bobchttps://reprap.org/mediawiki/index.php?title=G-code&diff=114014G-code2013-12-30T15:35:55Z<p>Bobc: Already referenced 7 lines above</p>
<hr />
<div>{{Languages}}<br />
<br />
This page tries to describe the flavour of G-codes that the RepRap firmwares use and how they work. The main target is additive fabrication using [[FFF]]/FDM processes. Codes for print head movements follow the [http://www.nist.gov/manuscript-publication-search.cfm?pub_id=823374 NIST RS274NGC G-code standard], so RepRap firmwares are quite usable for CNC milling and similar applications, too.<br />
<br />
As many different firmwares exist and their developers tend to implement new features without discussing strategies or looking what others did before them, a lot of different sub-flavours for the 3D-Printer specific codes developed over the years.<br />
<br />
== Introduction ==<br />
<br />
A typical piece of GCode as sent to a RepRap machine might look like this:<br />
<br />
N3 T0*57<br />
N4 G92 E0*67<br />
N5 G28*22<br />
N6 G1 F1500.0*82<br />
N7 G1 X2.0 Y2.0 F3000.0*85<br />
N8 G1 X3.0 Y3.0*33<br />
<br />
The meaning of all those symbols and numbers (and more) is explained below.<br />
<br />
To find out which specific gcode/s are implemented in any given firmware, there are little tables attached to the command descriptions, like this one:<br />
<br />
{| class="wikitable"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| yes || automatic || yes || yes || experimental<br />
|}<br />
Here means:<br />
; yes<br />
: Fully supported.<br />
; experimental<br />
: There is some support. Often it's required to check out a source code branch other than the default or to flip certain configuration switches.<br />
; automatic<br />
: The firmware handles this feature automatically, so there's no need to send the command; you get the feature regardless. An example is power supply on/off (M80/M81) in Teacup firmware.<br />
; no<br />
: The firmware doesn't support this feature.<br />
<br />
For the technically minded, the end of line is marked by a <nl> and optionally a <cr>. So, Unix line endings work as well as Windows ones.<br />
<br />
== RepRap G Code Fields ==<br />
<br />
This section explains the letter-preceded fields. The numbers in the fields are represented by nnn. Numbers can be integers, or can contain a decimal point, depending on context. For example an X coordinate can be integer (X175) or fractional (X17.62), whereas trying to select extruder number 2.76 would make no sense.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Letter<br />
! Meaning<br />
|-<br />
| Gnnn<br />
| Standard GCode command, such as move to a point<br />
|-<br />
| Mnnn<br />
| RepRap-defined command, such as turn on a cooling fan<br />
|-<br />
| Tnnn<br />
| Select tool nnn. In RepRap, tools are extruders<br />
|-<br />
| Snnn<br />
| Command parameter, such as the voltage to send to a motor<br />
|-<br />
| Pnnn<br />
| Command parameter, such as a time in milliseconds<br />
|-<br />
| Xnnn<br />
| An X coordinate, usually to move to<br />
|-<br />
| Ynnn<br />
| A Y coordinate, usually to move to<br />
|-<br />
| Znnn<br />
| A Z coordinate, usually to move to<br />
|-<br />
| Innn<br />
| Parameter - not currently used<br />
|-<br />
| Jnnn<br />
| Parameter - not currently used<br />
|-<br />
| Fnnn<br />
| Feedrate in mm per minute. (Speed of print head movement)<br />
|-<br />
| Rnnn<br />
| Parameter - used for temperatures<br />
|-<br />
| Qnnn<br />
| Parameter - not currently used<br />
|-<br />
| Ennn<br />
| Length of extrudate in mm. This is exactly like X, Y and Z, but for the length of filament to extrude. <s>It is common for newer stepper based systems to interpret ...</s> Better: Skeinforge 40 and up interprets this as the absolute length of input filament to consume, rather than the length of the extruded output.<br />
|-<br />
| Nnnn<br />
| Line number. Used to request repeat transmission in the case of communications errors.<br />
|-<br />
| *nnn<br />
| Checksum. Used to check for communications errors.<br />
|-<br />
|}<br />
<br />
== Comments ==<br />
<br />
G Code comments:<br />
<br />
<pre><br />
N3 T0*57 ;This is a comment<br />
N4 G92 E0*67<br />
; So is this<br />
N5 G28*22<br />
</pre><br />
<br />
Will be ignored by RepRap, as will blank lines. But it's better to strip these out in the host computer before the lines are sent. This saves bandwidth.<br />
<br />
== Individual commands ==<br />
<br />
=== Checking ===<br />
<br />
==== N and * ====<br />
<br />
Example: N123 [...G Code in here...] *71<br />
<br />
These are the line number and the checksum. The RepRap firmware checks the checksum against a locally-computed value and, if they differ, requests a repeat transmission of the line of the given number.<br />
<br />
You can leave both of these out - RepRap will still work, but it won't do checking. You have to have both or neither though.<br />
<br />
The checksum "cs" for a GCode string "cmd" (including its line number) is computed by exor-ing the bytes in the string up to and not including the * character as follows:<br />
<br />
<pre><br />
int cs = 0;<br />
for(i = 0; cmd[i] != '*' && cmd[i] != NULL; i++)<br />
cs = cs ^ cmd[i];<br />
cs &= 0xff; // Defensive programming...<br />
</pre><br />
<br />
and the value is appended as a decimal integer to the command after the * character.<br />
<br />
The RepRap firmware expects line numbers to increase by 1 each line, and if that doesn't happen it is flagged as an error. But you can reset the count using M110 (see below).<br />
<br />
=== Buffered G Commands ===<br />
<br />
The RepRap firmware stores these commands in a ring buffer internally for execution. This means that there is no (appreciable) delay while a command is acknowledged and the next transmitted. In turn, this means that sequences of line segments can be plotted without a dwell between one and the next. As soon as one of these buffered commands is received it is acknowledged and stored locally. If the local buffer is full, then the acknowledgment is delayed until space for storage in the buffer is available. This is how flow control is achieved.<br />
<br />
==== G0: Rapid move ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| ??? || yes || yes || yes || yes<br />
|}<br />
<br />
Example: G0 X12<br />
<br />
In this case move rapidly to X = 12 mm. In fact, the RepRap firmware uses exactly the same code for rapid as it uses for controlled moves (see G1 below), as - for the RepRap machine - this is just as efficient as not doing so. (The distinction comes from some old machine tools that used to move faster if the axes were not driven in a straight line. For them G0 allowed any movement in space to get to the destination as fast as possible.)<br />
<br />
==== G1: Controlled move ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| yes || yes || yes || yes || yes<br />
|}<br />
<br />
Example: G1 X90.6 Y13.8 E22.4<br />
<br />
Go in a straight line from the current (X, Y) point to the point (90.6, 13.8), extruding material as the move happens from the current extruded length to a length of 22.4 mm.<br />
<br />
RepRap does subtle things with feedrates. Thus:<br />
<br />
<pre><br />
G1 F1500<br />
G1 X90.6 Y13.8 E22.4<br />
</pre> <br />
<br />
Will set a feedrate of 1500 mm/minute, then do the move described above at that feedrate. But<br />
<br />
<pre><br />
G1 F1500<br />
G1 X90.6 Y13.8 E22.4 F3000<br />
</pre><br />
<br />
Will set a feedrate of 1500 mm/minute, then do the move described above accelerating to a feedrate of 3000 mm/minute as it does so. The extrusion will accelerate along with the X, Y movement so everything stays synchronized.<br />
<br />
RepRap thus treats feedrate as simply another variable (like X, Y, Z, and E) to be linearly interpolated. This gives complete control over accelerations and decelerations in a way that ensures that everything moves together and the right volume of material is extruded at all points.<br />
<br />
''Note: not every firmware implements this, e.g. the current [[Marlin]] will use the new feedrate from the beginning of the move and not change it.''<br />
<br />
The first example shows how to get a constant-speed movement. The second how to accelerate or decelerate. Thus<br />
<br />
<pre><br />
G1 F1500<br />
G1 X90.6 Y13.8 E22.4 F3000<br />
G1 X80 Y20 E36 F1500<br />
</pre><br />
<br />
Will do the first movement accelerating as before, and the second decelerating from 3000 mm/minute back to 1500 mm/minute.<br />
<br />
To reverse the extruder by a given amount (for example to reduce its internal pressure while it does an in-air movement so that it doesn't dribble) simply use G1 to send an E value that is less than the currently extruded length.<br />
<br />
Some implementations and RepRaps allow the sensing of endstops during moves to be switched on and off. Adding an S field allows this: G1 X300 S1 will move X to 300 checking for an endstop hit and stopping if it happens. G1 X300 S0 will do the same move with no checking. The default is no checking.<br />
<br />
==== G28: Move to Origin ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| yes || yes || yes || yes || yes<br />
|}<br />
<br />
Example: G28<br />
<br />
This causes the RepRap machine to move back to its X, Y and Z zero endstops, a process known as "homing". It does so accelerating, so as to get there fast. But when it arrives it backs off by 1 mm in each direction slowly, then moves back slowly to the stop. This ensures more accurate positioning. <br />
<br />
If you add coordinates, then just the axes with coordinates specified will be zeroed. Thus <br />
<br />
G28 X0 Y72.3<br />
<br />
will zero the X and Y axes, but not Z. The actual coordinate values are ignored.<br />
<br />
==== G29-G32: Bed probing ====<br />
<br />
'''G29''' Detailed Z-Probe<br />
<br />
probes the bed at 3 points.<br />
<br />
'''G30''' Single Z Probe<br />
<br />
In its simplest form probes bed at current XY location. <br />
<br />
Some implementations allow more general behaviour: if a Pn field is specified the probed X, Y, and Z values are saved as point n on the bed for calculating the offset plane. Generally n is 0, 1, or 2. If X, or Y, or Z values are specified (e.g. G30 P1 X20 Y50 Z0.3) then those values are used instead of the machine's current coordinates. A silly Z value (less than -9999.0) causes the machine to probe at the current point to get Z, rather than using the given value. If an S field is specfied (e.g. G30 P1 Z0.3 S) the bed plane is computed for compensation and stored. The combination of these options allows for the machine to be moved to points using G1 commands, and then probe the bed, or for the user to position the nozzle interactively and use those coordinates. The user can also record those values and place them in a setup GCode file for automatic execution.<br />
<br />
'''G31''' Report Current Probe status<br />
<br />
When used on its own this reports whether the Z probe is triggered, or gives the Z probe value in some units if the probe generates height values. If combined with a Z and P field (example: G31 P312 Z0.7) this will set the Z height to 0.7mm when the Z-probe value reaches 312 when a G28 Z0 (zero Z axis) command is sent. The machine will then move a further -0.7mm in Z to place itself at Z = 0. This allows non-contact measuring probes to approach but not touch<br />
the bed, and for the gap left to be allowed for. If the probe is a touch probe and generates a simple 0/1 off/on signal, then G31 Z0.7 will tell the RepRap machine that it is at a height of 0.7mm when the probe is triggered.<br />
<br />
'''G32''' Probe Z and calculate Z plane<br />
<br />
probes the bed at 3 pre-defined points (see M557) and updates transformation matrix for bed leveling compensation.<br />
<br />
=== Unbuffered G commands ===<br />
<br />
The following commands are not buffered. When one is received it is stored, but it is not acknowledged to the host until the buffer is exhausted and then the command has been executed. Thus the host will pause at one of these commands until it has been done. Short pauses between these commands and any that might follow them do not affect the performance of the machine.<br />
<br />
[[Teacup Firmware]] buffers G20, G21, G90 and G91.<br />
<br />
==== G4: Dwell ====<br />
<br />
Example: G4 P200<br />
<br />
In this case sit still doing nothing for 200 milliseconds. During delays the state of the machine (for example the temperatures of its extruders) will still be preserved and controlled.<br />
<br />
==== G10: Head Offset ====<br />
<br />
Example: G10 P3 X17.8 Y-19.3 Z0.0 R140 S205<br />
<br />
This sets the offset for extrude head 3 (from the P3) to the X and Y values specified. You can put a non-zero Z value in as well, but this is usually a bad idea unless the heads are loaded and unloaded by some sort of head changer. When all the heads are in the machine at once they should all be set to the same Z height.<br />
<br />
Remember that any parameter that you don't specify will automatically be set to the last value for that parameter. That usually means that you want explicitly to set Z0.0. <br />
<br />
The R value is the standby temperature in <sup>o</sup>C that will be used for the tool, and the S value is its operating temperature. If you don't want the head to be at a different temperature when not in use, set both values the same. See the T code (select tool) below.<br />
<br />
The [http://www.nist.gov/customcf/get_pdf.cfm?pub_id=823374 NIST G-code standard] mentions an additional L parameter, which is ignored.<br />
<br />
This command is [[Talk:G-code#M104 .26 M109 Deprecation, G10 Introduction | subject to discussion]].<br />
<br />
==== G20: Set Units to Inches ====<br />
<br />
Example: G20<br />
<br />
Units from now on are in inches.<br />
<br />
==== G21: Set Units to Millimeters ====<br />
<br />
Example: G21<br />
<br />
Units from now on are in millimeters. (This is the RepRap default.)<br />
<br />
==== G90: Set to Absolute Positioning ====<br />
<br />
Example: G90<br />
<br />
All coordinates from now on are absolute relative to the origin of the machine. (This is the RepRap default.)<br />
<br />
==== G91: Set to Relative Positioning ====<br />
<br />
Example: G91<br />
<br />
All coordinates from now on are relative to the last position.<br />
<br />
==== G92: Set Position ====<br />
<br />
Example: G92 X10 E90<br />
<br />
Allows programming of absolute zero point, by reseting the current position to the values specified. This would set the machine's X coordinate to 10, and the extrude coordinate to 90. No physical motion will occur.<br />
<br />
A G92 without coordinates will reset all axes to zero.<br />
<br />
=== Unbuffered M and T commands ===<br />
<br />
==== M0: Stop ====<br />
<br />
Example: M0<br />
<br />
The RepRap machine finishes any moves left in its buffer, then shuts down. All motors and heaters are turned off. It can be started again by pressing the reset button on the master microcontroller. See also M1, M112.<br />
<br />
==== M1: Sleep ====<br />
<br />
Example: M1<br />
<br />
The RepRap machine finishes any moves left in its buffer, then shuts down. All motors and heaters are turned off. It can still be sent G and M codes, the first of which will wake it up again. See also M0, M112.<br />
<br />
==== M3: Spindle On, Clockwise (CNC specific)====<br />
<br />
Example: M3 S4000<br />
<br />
The spindle is turned on with a speed of 4000 RPM.<br />
<br />
==== M4: Spindle On, Counter-Clockwise (CNC specific) ====<br />
<br />
Example: M4 S4000<br />
<br />
The spindle is turned on with a speed of 4000 RPM.<br />
<br />
==== M5: Spindle Off (CNC specific) ====<br />
<br />
Example: M5<br />
<br />
The spindle is turned off.<br />
<br />
==== M7: Mist Coolant On (CNC specific) ====<br />
<br />
Example: M7<br />
<br />
Mist coolant is turned on (if available)<br />
<br />
==== M8: Flood Coolant On (CNC specific) ====<br />
<br />
Example: M8<br />
<br />
Flood coolant is turned on (if available)<br />
<br />
==== M9: Coolant Off (CNC specific) ====<br />
<br />
Example: M9<br />
<br />
All coolant systems are turned off.<br />
<br />
==== M10: Vacuum On (CNC specific) ====<br />
<br />
Example: M10<br />
<br />
Dust collection vacuum system turned on.<br />
<br />
==== M11: Vacuum Off (CNC specific) ====<br />
<br />
Example: M11<br />
<br />
Dust collection vacuum system turned off.<br />
<br />
==== M17: Enable/Power all stepper motors====<br />
<br />
Example: M17<br />
<br />
==== M18: Disable all stepper motors====<br />
<br />
Example: M18<br />
<br />
Disables stepper motors and allows axis to move 'freely.'<br />
<br />
==== M20: List SD card ====<br />
<br />
Example: M20<br />
<br />
All files in the root folder of the SD card are listed to the serial port. This results in a line like:<br />
<br />
ok Files: {SQUARE.G,SQCOM.G,}<br />
<br />
The trailing comma is optional. Note that file names are returned in upper case, but - when sent to the M23 command (below) they must be in lower case. This seems to be a function of the SD software. Go figure...<br />
<br />
==== M21: Initialize SD card ====<br />
<br />
Example: M21<br />
<br />
The SD card is initialized. If an SD card is loaded when the machine is switched on, this will happen by default. SD card must be initialized for the other SD functions to work.<br />
<br />
==== M22: Release SD card ====<br />
<br />
Example: M22<br />
<br />
SD card is released and can be physically removed.<br />
<br />
==== M23: Select SD file ====<br />
<br />
Example: M23 filename.gco<br />
<br />
The file specified as filename.gco (8.3 naming convention is supported) is selected ready for printing.<br />
<br />
==== M24: Start/resume SD print ====<br />
<br />
Example: M24<br />
<br />
The machine prints from the file selected with the M23 command.<br />
<br />
==== M25: Pause SD print ====<br />
<br />
Example: M25<br />
<br />
The machine pause printing at the current position within the file selected with the M23 command.<br />
<br />
==== M26: Set SD position ====<br />
<br />
Example: M26<br />
<br />
Set SD position in bytes (M26 S12345).<br />
<br />
==== M27: Report SD print status ====<br />
<br />
Example: M27<br />
<br />
Report SD print status.<br />
<br />
==== M28: Begin write to SD card ====<br />
<br />
Example: M28 filename.gco<br />
<br />
File specified by filename.gco is created (or overwritten if it exists) on the SD card and all subsequent commands sent to the machine are written to that file.<br />
<br />
==== M29: Stop writing to SD card ====<br />
<br />
Example: M29 filename.gco<br />
<br />
File opened by M28 command is closed, and all subsequent commands sent to the machine are executed as normal.<br />
<br />
==== M30: Delete a file on the SD card ====<br />
<br />
Example: M30 filename.gco<br />
<br />
filename.gco is deleted.<br />
<br />
==== M40: Eject ====<br />
<br />
If your RepRap machine can eject the parts it has built off the bed, this command executes the eject cycle. This usually involves cooling the bed and then performing a sequence of movements that remove the printed parts from it. The X, Y and Z position of the machine at the end of this cycle are undefined (though they can be found out using the M114 command, q.v.).<br />
<br />
See also M240 and M241 below.<br />
<br />
==== M41: Loop ====<br />
<br />
Example: M41<br />
<br />
If the RepRap machine was building a file from its own memory such as a local SD card (as opposed to a file being transmitted to it from a host computer) this goes back to the beginning of the file and runs it again. So, for example, if your RepRap is capable of ejecting parts from its build bed then you can set it printing in a loop and it will run and run. Use with caution - the only things that will stop it are:<br />
<br />
# When you press the reset button,<br />
# When the build material runs out (if your RepRap is set up to detect this), and<br />
# When there's an error (such as a heater failure).<br />
<br />
==== M42: Stop on material exhausted / Switch I/O pin ====<br />
<br />
===== M42 in ??? =====<br />
<br />
Example: M42<br />
<br />
If your RepRap can detect when its material runs out, this decides the behaviour when that happens. The X and Y axes are zeroed (but not Z), and then the machine shuts all motors and heaters off. You have to press reset to reactivate the machine. In other words, it parks itself and then executes an M0 command (q.v.).<br />
<br />
===== M42 in Marlin/Sprinter =====<br />
<br />
Example: M42 P7 S255<br />
<br />
M42 switches a general purpose I/O pin.<br />
<br />
===== M42 in Teacup =====<br />
<br />
Not needed. General purpose devices are handled like a heater, see [[#M104: Set Extruder Temperature | M104]].<br />
<br />
==== M43: Stand by on material exhausted ====<br />
<br />
Example: M43<br />
<br />
If your RepRap can detect when its material runs out, this decides the behaviour when that happens. The X and Y axes are zeroed (but not Z), and then the machine shuts all motors and heaters off except the heated bed, the temperature of which is maintained. The machine will still respond to G and M code commands in this state.<br />
<br />
==== M80: ATX Power On ====<br />
<br />
Example: M80<br />
<br />
Turns on the ATX power supply from standby mode to fully operational mode. No-op on electronics without standby mode.<br />
<br />
'''Note''': some firmwares, like [[Teacup Firmware | Teacup]], handle power on/off automatically, so this is redundant there. Also, see [http://forums.reprap.org/read.php?219,132664 RAMPS wiring for ATX on/off]<br />
<br />
==== M81: ATX Power Off ====<br />
<br />
Example: M81<br />
<br />
Turns off the ATX power supply. Counterpart to M80.<br />
<br />
==== M82: set extruder to absolute mode ====<br />
<br />
Example: M82<br />
<br />
makes the extruder interpret extrusion as absolute positions.<br />
<br />
This is the default in repetier.<br />
<br />
==== M83: set extruder to relative mode ====<br />
<br />
Example: M83<br />
<br />
makes the extruder interpret extrusion values as relative positions.<br />
<br />
==== M84: Stop idle hold ====<br />
<br />
Example: M84<br />
<br />
Stop the idle hold on all axis and extruder. In some cases the idle hold causes annoying noises, which can be stopped by disabling the hold. Be aware that by disabling idle hold during printing, you will get quality issues. This is recommended only in between or after printjobs.<br />
<br />
==== M92: Set axis_steps_per_unit ====<br />
<br />
Example: M92 X<newsteps> Sprinter and Marlin<br />
<br />
Allows programming of steps per unit of axis till the electronics are reset for the specified axis. Very useful for calibration.<br />
<br />
==== M98: Call Macro/Subprogram ====<br />
<br />
Example: M98 Pmymacro.g<br />
<br />
Runs the macro in the file mymacro.g. In conventional G Codes for CNC machines the P parameter normally refers to a line number in the program itself (P2000 would run the Macro starting at line O2000, say). For RepRap, which almost always has some sort of mass storage device inbuilt, it simply refers to the name of a GCode file that is executed by the G98 call. That GCode file does not need to end with an M99 (return) as the end-of-file automatically causes a return. It is usually a good idea to start a macro with an M120 (Push) instruction and to end it with an M121 (Pop) instruction, q.v. Macro calls cannot usually be nested or be recursive; i.e. you can't call a macro from a macro (though some implementations may allow this).<br />
<br />
==== M99: Return from Macro/Subprogram ====<br />
<br />
Example: M99<br />
<br />
Returns from an M98 call.<br />
<br />
<br />
==== M98: Get axis_hysteresis_mm ==== <br />
<br />
'''Deprecated - clashes with the G Code standard M98 above''' <br />
<br />
Example: M98 <br />
<br />
Report the current hysteresis values in mm for all of the axis.<br />
<br />
Proposed for Marlin<br />
<br />
==== M99: Set axis_hysteresis_mm ====<br />
<br />
'''Deprecated - clashes with the G Code standard M99 above'''<br />
<br />
Example: M99 X<mm> Y<mm> Z<mm> E<mm> <br />
<br />
Allows programming of axis hysteresis. Mechanical pulleys, gears and threads can have hysteresis when they change direction. That is, a certain number of steps occur before movement occurs. You can measure how many mm are lost to hysteresis and set their values with this command. Every time an axis changes direction, these extra mm will be added to compensate for the hysteresis.<br />
<br />
Proposed for Marlin<br />
<br />
==== M101 Turn extruder 1 on Forward / Undo Extruder Retraction ====<br />
<br />
===== M101 in Teacup firmware =====<br />
<br />
If a DC extruder is present, turn that on. Else, undo filament retraction, which means, make the extruder ready for extrusion. Complement to M103.<br />
<br />
===== M101 in other firmwares =====<br />
<br />
Deprecated. Regarding filament retraction, see M227, M228, M229.<br />
<br />
==== M102 Turn extruder 1 on Reverse ====<br />
<br />
Deprecated.<br />
<br />
==== M103 Turn all extruders off / Extruder Retraction ====<br />
<br />
===== M103 in Teacup firmware =====<br />
<br />
If a DC extruder is present, turn that off. Else, retract the filament in the hope to prevent nozzle drooling. Complement to M101.<br />
<br />
===== M103 in other firmwares =====<br />
<br />
Deprecated. Regarding extruder retraction, see M227, M228, M229.<br />
<br />
==== M104: Set Extruder Temperature ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| yes || yes || yes || yes || yes<br />
|}<br />
<br />
Example: M104 S190<br />
<br />
Set the temperature of the current extruder to 190<sup>o</sup>C and return control to the host immediately (''i.e.'' before that temperature has been reached by the extruder). See also M109.<br />
<br />
This is deprecated because temperatures should be set using the G10 and T commands (q.v.).<br />
<br />
Deprecation is [[Talk:G-code#M104 .26 M109 Deprecation, G10 Introduction | subject to discussion]]. --[[User:Traumflug|Traumflug]] 11:33, 19 July 2012 (UTC)<br />
<br />
===== M104 in Teacup Firmware =====<br />
<br />
In Teacup Firmware, M104 can be additionally used to handle all devices using a temperature sensor. It supports the additional P parameter, which is a zero-based index into the list of sensors in config.h. For devices without a temp sensor, see [[#M106: Fan On | M106]].<br />
<br />
Example: M104 P1 S100<br />
<br />
Set the temperature of the device attached to the second temperature sensor to 100&nbsp;°C.<br />
<br />
==== M105: Get Extruder Temperature ====<br />
<br />
Example: M105<br />
<br />
Request the temperature of the current extruder and the build base in degrees Celsius. The temperatures are returned to the host computer. For example, the line sent to the host in response to this command looks like:<br />
<tt>ok T:201 B:117</tt><br />
<br />
Expansion/generalization of M105 to be considered as noted in [[Pronterface I/O Monitor]]<br />
<br />
==== M106: Fan On ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || yes || yes || yes ||<br />
|}<br />
<br />
Example: M106 S127<br />
<br />
Turn on the cooling fan at half speed.<br />
<br />
Mandatory parameter 'S' declares the PWM value (0-255). M106 S0 turns the fan off. In some implementations the pwm is specified by a real fraction: M106 S0.7.<br />
<br />
===== M106 in Teacup Firmware =====<br />
<br />
Additionally to the above, Teacup Firmware uses M106 to control general devices. It supports the additional P parameter, which is an zero-based index into the list of heaters/devices in config.h.<br />
<br />
Example: M106 P2 S255<br />
<br />
Turn on device #3 at full speed/wattage.<br />
<br />
'''Note''': When turning on a temperature sensor equipped heater with M106 and M104 at the same time, temperature control will override the value given in M106 quickly.<br />
<br />
==== M107: Fan Off ====<br />
<br />
Deprecated. Use M106 S0 instead.<br />
<br />
==== M108: Set Extruder Speed ====<br />
<br />
Sets speed of extruder motor.<br />
(Deprecated in current firmware, see M113)<br />
<br />
==== M109: Set Extruder Temperature and Wait ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| ??? || not needed || see text || yes || ???<br />
|}<br />
<br />
===== M109 in Teacup =====<br />
<br />
Not needed. To mimic Marlin behaviour, use [[#M104: Set Extruder Temperature | M104]] followed by [[#M116: Wait | M116]].<br />
<br />
===== M109 in Marlin, Sprinter (ATmega port) =====<br />
<br />
Set extruder heater temperature in degrees celsius and wait for this temperature to be achieved.<br />
<br />
Example: M109 S185<br />
<br />
===== M109 in Sprinter (4pi port) =====<br />
<br />
Parameters: '''S''' (optional), set target temperature value. If not specified, waits for the temperature set by [[#M104: Set Extruder Temperature | M104]]. '''R''' (optional), sets target temperature range maximum value.<br />
<br />
Example: M109 S185 R240 //sets extruder temperature to 185 and waits for the temperature to be between 185 - 240.<br />
<br />
If you have multiple extruders, use '''T''' or '''P''' parameter to specify which extruder you want to set/wait.<br />
<br />
Another way to do this is to use [[#G10: Head Offset | G10]].<br />
<br />
==== M110: Set Current Line Number ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| ??? || not needed || ??? || ??? || ???<br />
|}<br />
<br />
Example: M110 N123<br />
<br />
Set the current line number to 123. Thus the expected next line after this command will be 124.<br />
<br style="clear: both" /><br />
<br />
==== M111: Set Debug Level ====<br />
<br />
Example: M111 S6<br />
<br />
Set the level of debugging information transmitted back to the host to level 6. The level is the OR of three bits:<br />
<br />
<Pre><br />
#define DEBUG_ECHO (1<<0)<br />
#define DEBUG_INFO (1<<1)<br />
#define DEBUG_ERRORS (1<<2)<br />
</pre><br />
<br />
Thus 6 means send information and errors, but don't echo commands. (This is the RepRap default.)<br />
<br />
<br />
Example: M253 <br />
<br />
{| class="wikitable"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || Debug || || || <br />
|}<br />
<br />
<br />
==== M112: Emergency Stop ====<br />
<br />
Example: M112<br />
<br />
Any moves in progress are immediately terminated, then RepRap shuts down. All motors and heaters are turned off. It can be started again by pressing the reset button on the master microcontroller. See also M0 and M1.<br />
<br />
==== M113: Set Extruder PWM ====<br />
<br />
Example: M113<br />
<br />
Set the PWM for the currently-selected extruder. On its own this command <br />
sets RepRap to use the on-board potentiometer on the extruder controller board to set the PWM for the currently-selected extruder's stepper power. With an S field:<br />
<br />
M113 S0.7<br />
<br />
it causes the PWM to be set to the S value (70% in this instance). M113 S0 turns the extruder off, until an M113 command other than M113 S0 is sent.<br />
<br />
==== M114: Get Current Position ====<br />
<br />
Example: M114<br />
<br />
This causes the RepRap machine to report its current X, Y, Z and E coordinates to the host.<br />
<br />
For example, the machine returns a string such as:<br />
<br />
<tt>ok C: X:0.00 Y:0.00 Z:0.00 E:0.00</tt><br />
<br />
In Marlin first 3 numbers is the position for the planner. The other positions are the positions from the stepper function. This helps for debugging a previous stepper function bug. <br />
<br />
<tt>X:0.00 Y:0.00 RZ:0.00 LZ:0.00 Count X:0.00 Y:0.00 RZ:41.02 LZ:41.02</tt><br />
<br />
==== M115: Get Firmware Version and Capabilities ====<br />
<br />
Example: M115<br />
<br />
Request the Firmware Version and Capabilities of the current microcontroller <br />
The details are returned to the host computer as key:value pairs separated by spaces and terminated with a linefeed.<br />
<br />
sample data from firmware:<br />
ok PROTOCOL_VERSION:0.1 FIRMWARE_NAME:FiveD FIRMWARE_URL:http%3A//reprap.org MACHINE_TYPE:Mendel EXTRUDER_COUNT:1<br />
<br />
This M115 code is inconsistently implemented, and should not be relied upon to exist, or output correctly in all cases. An initial implementation was committed to svn for the FiveD Reprap firmware on 11 Oct 2010. Work to more formally define protocol versions is currently (October 2010) being discussed. See [[M115_Keywords]] for one draft set of keywords and their meanings.<br />
<br />
==== M116: Wait ====<br />
<br />
Example: M116<br />
<br />
Wait for ''all'' temperatures and other slowly-changing variables to arrive at their set values. See also M109.<br />
<br />
==== M117: Get Zero Position ====<br />
<br />
Example: M117<br />
<br />
This causes the RepRap machine to report the X, Y, Z and E coordinates ''in steps not mm'' to the host that it found when it last hit the zero stops for those axes. That is to say, when you zero X, the <i>x</i> coordinate of the machine when it hits the X endstop is recorded. This value should be 0, of course. But if the machine has drifted (for example by dropping steps) then it won't be. This command allows you to measure and to diagnose such problems. (E is included for completeness. It doesn't normally have an endstop.)<br />
<br />
==== M117 in Marlin: Display Message ====<br />
<br />
Example: M117 Hello World<br />
<br />
This causes the given message to be shown in the status line on an attached LCD. The above command will display Hello World. <br />
<br />
==== M118: Negotiate Features ====<br />
<br />
Example: M118 P42<br />
<br />
This M-code is for future proofing. NO firmware or hostware supports this at the moment. It is used in conjunction with M115's FEATURES keyword.<br />
<br />
See [[Protocol_Feature_Negotiation]] for more info.<br />
<br />
==== M119: Get Endstop Status ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || yes || || yes || yes<br />
|}<br />
<br />
Example: M119<br />
<br />
Returns the current state of the configured X, Y, Z endstops. Takes into account any 'inverted endstop' settings, so one can confirm that the machine is interpreting the endstops correctly.<br />
<br />
==== M120: Push ====<br />
<br />
Push the state of the RepRap machine onto a stack. Exactly what variables get pushed depends on the implementation (as does the depth of the stack - a typical depth might be 5). A sensible minimum, however, might be <br />
<br />
# Current feedrate, and<br />
# Whether moves (and separately extrusion) are relative or absolute<br />
<br />
==== M121: Pop ====<br />
<br />
Recover the last state pushed onto the stack.<br />
<br />
==== M122: Diagnose ====<br />
<br />
Sending an M122 causes the RepRap to transmit diagnostic information, for eaxmple via a USB serial link.<br />
<br />
==== M126: Open Valve ====<br />
<br />
Example: M126 P500<br />
<br />
Open the extruder's valve (if it has one) and wait 500 milliseconds for it to do so.<br />
<br />
==== M127: Close Valve ====<br />
<br />
Example: M127 P400<br />
<br />
Close the extruder's valve (if it has one) and wait 400 milliseconds for it to do so.<br />
<br />
==== M128: Extruder Pressure PWM ====<br />
<br />
Example: M128 S255<br />
<br />
PWM value to control internal extruder pressure. S255 is full pressure.<br />
<br />
==== M129: Extruder pressure off ====<br />
<br />
Example: M129 P100<br />
<br />
In addition to setting Extruder pressure to 0, you can turn the pressure off entirely. P400 will wait 100ms to do so.<br />
<br />
==== M130: Set PID P value ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || yes || || || <br />
|}<br />
<br />
Example: M130 P 0 S 8.0 # Sets heater 0 P factor to 8.0<br />
<br style="clear: both" /><br />
<br />
==== M131: Set PID I value ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || yes || || || <br />
|}<br />
<br />
Example: M130 P 1 S 0.5 # Sets heater 1 I factor to 0.5<br />
<br style="clear: both" /><br />
<br />
==== M132: Set PID D value ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || yes || || || <br />
|}<br />
<br />
Example: M130 P 0 S 24 # Sets heater 0 D factor to 24.0<br />
<br />
<br style="clear: both" /><br />
<br />
==== M133: Set PID I limit value ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || yes || || || <br />
|}<br />
<br />
Example: M130 P 1 S 264 # Sets heater 0 I limit value to 264<br />
<br />
<br style="clear: both" /><br />
<br />
==== M134: Write PID values to EEPROM ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || yes || || || <br />
|}<br />
<br />
Example: M134 <br />
<br style="clear: both" /><br />
<br />
<br />
==== M135: Set PID sample interval ====<br />
<br />
Example: M135 S300<br />
<br />
Set the PID to measure temperatures and calculate the power to send to the heaters every 300ms.<br />
<br />
==== M136: Print PID settings to host ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || Debug || || || <br />
|}<br />
<br />
Example: M136 P1 # print heater 0 PID parameters to host<br />
<br style="clear: both" /><br />
<br />
==== M140: Bed Temperature (Fast) ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || yes || yes || yes || yes<br />
|}<br />
<br />
Example: M140 S55<br />
<br />
Set the temperature of the build bed to 55<sup>o</sup>C and return control to the host immediately (''i.e.'' before that temperature has been reached by the bed).<br />
<br />
==== M141: Chamber Temperature (Fast) ====<br />
<br />
Example: M141 S30<br />
<br />
Set the temperature of the chamber to 30<sup>o</sup>C and return control to the host immediately (''i.e.'' before that temperature has been reached by the chamber).<br />
<br />
==== M142: Holding Pressure ====<br />
<br />
Example: M142 S1<br />
<br />
Set the holding pressure of the bed to 1 bar.<br />
<br />
The holding pressure is in bar. For hardware which only has on/off holding, when the holding pressure is zero, turn off holding, when the holding pressure is greater than zero, turn on holding.<br />
<br />
==== M143: Maximum hot-end temperature ====<br />
<br />
Example: M143 S275<br />
<br />
Set the maximum temperature of the hot-end to 275C<br />
<br />
When temperature of the hot-end exceeds this value, take countermeasures, for instance an emergency stop. This is to prevent hot-end damage.<br />
<br />
==== M160: Number of mixed materials ====<br />
<br />
Example: M160 S4<br />
<br />
Set the number of materials, N, that the current extruder can handle to the number specified. The default is 1.<br />
<br />
When N >= 2, then the E field that controls extrusion requires N+1 values separated by spaces after it like this: <br />
<br />
<pre><br />
M160 S4<br />
G1 X90.6 Y13.8 E22.4 0.1 0.1 0.1 0.7<br />
G1 X70.6 E42.4 0.0 0.0 0.0 1.0<br />
G1 E42.4 1.0 0.0 0.0 0.0<br />
</pre><br />
<br />
The second line moves straight to the point (90.6, 13.8) extruding 22.4mm of filament. The mix ratio at the '''end''' of the move is 0.1:0.1:0.1:0.7.<br />
<br />
The third line moves back 20mm in X extruding 20mm of filament. The mix varies linearly from 0.1:0.1:0.1:0.7 to 0:0:0:1 as the move is made.<br />
<br />
The fourth line has no physical effect, but sets the mix proportions for the start of the next move to 1:0:0:0.<br />
<br />
==== M190: Wait for bed temperature to reach target temp ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || obsolete, see M116 || yes || yes || <br />
|}<br />
<br />
Example: M190 S60<br />
<br />
This will wait until the bed temperature reaches 60 degrees, printing out the temperature of the hot end and the bed every second.<br />
<br style="clear: both" /><br />
<br />
==== M200 - Set filament diameter / Get Endstop Status ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || || || yes || <br />
|}<br />
<br />
M200 sets the filament diameter.<br />
<br />
Question: what does a firmware do with filament diameter? Has this an effect on how much an E command moves the extruder motor? --[[User:Traumflug|Traumflug]] 11:34, 14 October 2012 (UTC)<br />
<br />
==== M201 - Set max printing acceleration ====<br />
<br />
in units/s^2 for print moves (M201 X1000 Y1000)<br />
<br />
==== M202 - Set max travel acceleration ====<br />
<br />
in units/s^2 for travel moves (M202 X1000 Y1000) Unused in Marlin!!<br />
<br />
==== M203 - Set maximum feedrate ====<br />
<br />
that your machine can sustain (M203 X200 Y200 Z300 E10000) in mm/sec<br />
<br />
Note: this should be in units/minute, just like the F code.<br />
<br />
==== M204 - Set default acceleration ====<br />
<br />
S normal moves T filament only moves (M204 S3000 T7000) im mm/sec^2 also sets minimum segment time in ms (B20000) to prevent buffer underruns and M20 minimum feedrate<br />
<br />
==== M205 - advanced settings ====<br />
<br />
minimum travel speed S=while printing T=travel only, B=minimum segment time X= maximum xy jerk, Z=maximum Z jerk, E=maximum E jerk<br />
<br />
==== M206: set home offset ====<br />
<br />
Example: M206 X10.0 Y10.0 Z-0.4<br />
<br />
The values specified are added to the endstop position when the axes are referenced. The same can be achieved with a G92 right after homing (G28, G161).<br />
<br />
With Marlin firmware, this value can be saved to EEPROM using the M500 command.<br />
<br />
A similar command is G10, aligning these two is [[Talk:G-code#M104 .26 M109 Deprecation, G10 Introduction | subject to discussion]].<br />
<br />
==== M207: calibrate z axis by detecting z max length ====<br />
<br />
Example: M207<br />
<br />
After placing the tip of the nozzle in the position you expect to be considered Z=0, issue this command to calibrate the Z axis. It will perform a z axis homing routine and calculate the distance traveled in this process. The result is stored in EEPROM as z_max_length. For using this calibration method the machine must be using a Z MAX endstop.<br />
<br />
This procedure is usually more reliable than mechanical adjustments of a Z MIN endstop.<br />
<br />
==== M208: set axis max travel ====<br />
<br />
Example: M208 X250 Y210 Z180<br />
<br />
The values specified set the software limits for axis travel in the positive direction.<br />
<br />
With Marlin firmware, this value can be saved to EEPROM using the M500 command.<br />
<br />
<br />
==== M209: enable automatic retract ====<br />
<br />
Example: M209 S1<br />
<br />
This boolean value S 1=true or 0=false enables automatic retract detect if the slicer did not support G10/11: every normal extrude-only move will be classified as retract depending on the direction.<br />
<br />
==== M210: Set homing feedrates ====<br />
<br />
Example: M210 X1000 Y1500<br />
<br />
Set the feedrates used for homing to the values specified in mm per minute.<br />
<br />
==== M220:set speed factor override percentage ====<br />
<br />
Example: M220 S80<br />
<br />
S<factor in percent>- set speed factor override percentage<br />
<br />
==== M221: set extrude factor override percentage ====<br />
<br />
Example: M221 S70<br />
<br />
S<factor in percent>- set extrude factor override percentage<br />
<br />
==== M226: Gcode Initiated Pause ====<br />
<br />
Example: M226<br />
<br />
Initiates a pause in the same way as if the pause button is pressed. That is, program execution is stopped and the printer waits for user interaction. This matches the behaviour of M1 in the [http://www.nist.gov/manuscript-publication-search.cfm?pub_id=823374 NIST RS274NGC G-code standard] and M0 in Marlin firmware.<br />
<br />
==== M227: Enable Automatic Reverse and Prime ====<br />
<br />
Example: M227 P1600 S1600<br />
<br />
P and S are steps.<br />
<br />
"Reverse and Prime" means, the extruder filament is retracted some distance when not in use and pushed forward the same amount before going into use again. This shall help to prevent drooling of the extruder nozzle. Teacup firmware implements this with M101/M103.<br />
<br />
==== M228: Disable Automatic Reverse and Prime ====<br />
<br />
Example: M228<br />
<br />
See also M227.<br />
<br />
==== M229: Enable Automatic Reverse and Prime ====<br />
<br />
Example: M229 P1.0 S1.0<br />
<br />
P and S are extruder screw rotations. See also M227.<br />
<br />
==== M230: Disable / Enable Wait for Temperature Change ====<br />
<br />
Example: M230 S1<br />
<br />
S1 Disable wait for temperature change<br />
S0 Enable wait for temperature change<br />
<br />
<br />
==== M240: Start conveyor belt motor / Echo off ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || Debug: Echo off|| || || <br />
|}<br />
<br />
Example: M240<br />
<br />
The conveyor belt allows to start mass production of a part with a reprap. <br />
<br />
Echoing may be controlled in some firmwares with M111<br />
<br style="clear: both" /><br />
<br />
==== M241: Stop conveyor belt motor / echo on ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || Debug: Echo on|| || || <br />
|}<br />
<br />
Example: M241<br />
<br />
Echoing may be controlled in some firmwares with M111<br />
<br style="clear: both" /><br />
<br />
==== M245: Start cooler ====<br />
<br />
Example: M245<br />
<br />
used to cool parts/heated-bed down after printing for easy remove of the parts after print<br />
<br />
==== M246: Stop cooler ====<br />
<br />
Example: M246<br />
<br />
==== M300: Play beep sound ====<br />
<br />
Usage: M300 S<frequency Hz> P<duration ms><br />
<br />
Example: M300 S300 P1000<br />
<br />
Play beep sound, use to notify important events like the end of printing. [http://www.3dprinting-r2c2.com/?q=content/seasons-greetings See working example on] [[R2C2_RepRap_Electronics|R2C2 electronics]].<br />
<br />
==== M301: Set PID parameters - Hot End ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || || || PID || <br />
|}<br />
Example: M301 P1 I2 D3 C5<br />
<br />
Sets Proportional, Integral and Derivative values for hot end, the value C refers to an extrusion rate.<br />
<br />
Alternate implementation<br />
<br />
Example: M301 W125<br />
<br />
==== M302: Allow cold extrudes ====<br />
This tells the printer to allow movement of the extruder motor, when the hotend is not at printing temperature<br />
<br />
<br />
Example: M302<br />
<br />
==== M303: Run PID tuning ====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || || || PID || PID <br />
|}<br />
Hotend Usage: M303 S<temperature> C<cycles><br />
Bed Usage: M303 E-1 C<cycles> S<temperature> <br />
Example: M303 C8 S175<br />
<br />
Generate Proportional, Integral and Derivative values for the hotend or bed (E-1). Send the appropriate code and wait for the output to update the firmware.<br />
<br />
<br />
<br />
==== M304: Set PID parameters - Bed====<br />
{| class="wikitable" align="right"<br />
! rowspan="2" | Support || FiveD || Teacup || Sprinter || Marlin || Repetier<br />
|-<br />
| || || || PID || <br />
|}<br />
Example: M304 P1 I2 D3<br />
<br />
Sets Proportional, Integral and Derivative values for bed<br />
<br />
==== M400: Wait for current moves to finish ====<br />
<br />
Finishes all current moves and and thus clears the buffer. That's identical to <code>G4 P0</code>.<br />
<br />
Example: M400<br />
<br />
==== M420: Set RGB Colors as PWM ====<br />
<br />
Usage: M420 R<Red PWM (0-255)> E<Green PWM (0-255)> B<Blue PWM (0-255)><br />
<br />
Example: M420 R255 E255 B255<br />
<br />
Set the color of your RGB LEDs that are connected to PWM-enabled pins. Note, the Green color is controlled by the E value instead of the G value due to the G code being a primary code that cannot be overridden.<br />
<br />
<br />
==== M550: Set Name ====<br />
<br />
Example: M550 PGodzilla<br />
<br />
Sets the name of the RepRap to (in this case) Godzilla. The name can be any string of printable characters except ';', which still means start comment.<br />
<br />
==== M551: Set Password ====<br />
<br />
Example: M551 Pmy-very-secret-word<br />
<br />
On machines that need a password to activate them, set that password. The code 'P' is not part of the password. Note that as this is sent in clear it does not (nor is it intended to) offer a very high level of security. But on machines that are (say) on a network, it prevents idle messing about by the unauthorised. The password can contain any printable charcters except ';', which still means start comment.<br />
<br />
==== M552: Set IP address ====<br />
<br />
Example: M552 P192.168.1.14<br />
<br />
Sets the IP address of the RepRap machine to (in this case) 192.168.1.14. If no P field is specified, this echos the existing IP address.<br />
<br />
<br />
==== M553: Set Netmask ====<br />
<br />
Example: M553 P255.255.255.0<br />
<br />
Sets the IP address of the RepRap machine to (in this case) 255.255.255.0. If no P field is specified, this echos the existing Netmask.<br />
<br />
<br />
==== M554: Set Gateway ====<br />
<br />
Example: M554 P192.168.1.1<br />
<br />
Sets the Gateway of the RepRap machine to (in this case) 192.168.1.1. If no P field is specified, this echos the existing Gateway.<br />
<br />
==== M555: Set compatibility ====<br />
<br />
Example: M555 P1<br />
<br />
For firmware that can do it, sets the firmware to a mode where its input and (especially) output behaves exactly like other established firmware. The value of the P argument is:<br />
<br />
{| class="wikitable"<br />
|P value || Firmware <br />
|-<br />
|0 || Native (i.e. whatever the firmware actually is)<br />
|-<br />
| 1 || [[RepRap_Firmware]]<br />
|-<br />
| 2 || [[Marlin]]<br />
|-<br />
| 3 || [[Teacup]]<br />
|-<br />
| 4 || [[Sprinter]]<br />
|-<br />
| 5 || [[Repetier]]<br />
|}<br />
<br />
==== M556: Axis compensation ====<br />
<br />
Example: M556 S100 X0.7 Y-0.2 Z0.6<br />
<br />
Though with care and adjustment a RepRap can be set up with its axes at right-angles to each other within the accuracy of the machine, who wants to bother with care and adjustment when the problem<br />
can be solved by software? This tells software the tangents of the angles between the axes of the machine obtained by printing then measuring a test part. The S parameter (100 here) is the length of a triangle along each axis in mm. The X, Y and Z figures are the number of millimeters of the short side of the triangle that represents how out of true a pair of axes is. The X figure is the error between X and Y, the Y figure is the error between Y and Z, and the Z figure is the error between X and Z. Positive values indicate that the angle between the axis pair is obtuse, negative acute.<br />
<br />
==== M557: Set Z probe point ====<br />
<br />
Example: M557 P1 X30 Y40.5<br />
<br />
Set the points at which the bed will be probed to compensate for its plane being slightly out of horizontal. The P value is the index of the point (indices start at 0) and the X and Y values are the position to move extruder 0 to to probe the bed. An implementation should allow a minimum of three points (P0, P1 and P2). This just records the point coordinates; it does not actually do the probing. See G32.<br />
<br />
==== M558: Set Z probe type ====<br />
<br />
Example: M558 P0<br />
<br />
A Z probe may be a switch (the default) an IR proximity sensor, or some other device. This selects which to use. P0 gives a switch. P1 gives an IR probe. See also G31 and G32.<br />
<br />
==== M559: Upload configuration file ====<br />
<br />
Example: M559<br />
<br />
If the RepRap supports it, this uploads a file that is run on re-boot to configure the machine. This file usually is a special G Code file. After sending M559, the file should be sent, ending with an M29 (q.v.).<br />
<br />
==== M560: Upload web page file ====<br />
<br />
Example: M560<br />
<br />
For RepRaps that have web support and that can be driven by a web browser, this uploads the file that is the control page for the RepRap. After sending M560 the file (usually an HTML file) should be sent, terminated by the string <pre><!-- **EoF** --></pre>. Clearly that string cannot exist in the body of the file, but can be put on the end to facilitate this process. This should not be too serious a restriction...<br />
<br />
<br />
==== M561: Set Identity Transform ====<br />
<br />
Example: M561<br />
<br />
This cancels any bed-plane fitting as the result of probing (or anything else) and returns the machine to moving in the user's coordinate system.<br />
<br />
==== M562: Reset temperature fault ====<br />
<br />
Example: M562 P2<br />
<br />
Reset a temperature fault on heater/sensor 2. If the RepRap has switched off and locked a heater because it has detected a fault, this will reset the fault condition and allow you to use the heater again. Obviously to be used with caution. If the fault persists it will lock out again after you have issued this command. P0 is the bed; P1 the first extruder, and so on.<br />
<br />
==== M906: Set motor currents ====<br />
<br />
Example: M906 X300 Y500 Z200 E350<br />
<br />
Sets the currents to send to the stepper motors for each axis. The values are in milliamps.<br />
<br />
==== M998: Request resend of line ====<br />
<br />
Example: M998 P34<br />
<br />
Request a resend of line 34. In some implementations the input-handling code overwrites the incomming G Code with this when it detects, for example, a checksum error.<br />
Then it leaves it up to the GCode interpreter actually to request the resend.<br />
<br />
==== M999: Restart after being stopped by error ====<br />
<br />
Example: M999<br />
<br />
==== T: Select Tool ====<br />
<br />
Example: T1<br />
<br />
Select extruder number 1 to build with. <br />
<br />
The sequence followed is:<br />
<br />
# Set the current extruder to its standby temperature specified by G10 (see above),<br />
# Set the new extruder to its operating temperature specified by G10 and wait for '''all''' temperatures to stabilise,<br />
# Apply any X, Y, Z offset for the new extruder specified by G10,<br />
# Use the new extruder.<br />
<br />
Selecting a non-existent tool (100, say) just does Step 1. above. That is to say it leaves all tools in their standby state. You can, of course, use the G10 command beforehand to set that standby temperature to anything you like.<br />
<br />
Note that you may wish to move to a parking position ''before'' executing a T command in order to allow the new extruder to reach temperature while not in contact with the print. It is acceptable for the firmware to apply a small offset [by convention (-1mm x tool-number) in Y] to the current position when the above sequence is entered to allow temperature changes to take effect just away from the parking position. Any such offset must, of course, be undone when the procedure finishes.<br />
<br />
If the Z value changes in the offsets and the head moves up, then the Z move is made before the X and Y moves. If Z moves down, X and Y are done first.<br />
<br />
After a reset extruders will not start heating until they are selected. You can either put them all at their standby temperature by selecting them in turn, or leave them off so they only come on if/when you first use them. The M0, M1 and M112 commands turn them all off. You can, of course, turn them all off with the M1 command, then turn some back on again. Don't forget also to turn on the heated bed (if any) if you use that trick.<br />
<br />
Extruder numbering starts at 0.<br />
<br />
== Proposed SCARA calibration codes (Morgan) ==<br />
<br />
In order to ease calibration of Reprap Morgan, the following M-codes are used to set the machine up<br />
Implemented in qharley/Marlin armlevel branch.<br />
<br />
==== M360 : Move to Theta 0 degree position ====<br />
The arms move into a position where the Theta steering arm is parallel to the top platform edge. The user then calibrates the position by moving the arms with the jog buttons in software like pronterface until it is perfectly parallel. Using M114 will then display the calibration offset that can then be programmed into the unit using M206 (Home offset) X represents Theta.<br />
<br />
==== M361 : Move to Theta 90 degree position ====<br />
Theta move to 90 degrees with platform edge. User calibrates by using jog arms to place exactly 90 degrees. Steps per degree can then be read out by using M114, and programmed using M92. X represents Theta. Program Y (Psi) to the same value initially. Remember to repeat M360 after adjusting steps per degree.<br />
<br />
==== M362 : Move to Psi 0 degree position ====<br />
Arms move to Psi 0 degree. Check only after other Theta calibrations<br />
<br />
==== M363 : Move to Psi 90 degree position ====<br />
Arms move to Psi 90 degree. Check only after other Theta calibrations<br />
<br />
==== M364 : Move to Psi + Theta 90 degree position ====<br />
Move arms to form a 90 degree angle between the inner and outer Psi arms. Calibrate by moving until angle is exactly 90 degree. Read out with M114, and calibrate value into Home offset M206. Psi is represented by Y.<br />
<br />
==== M365 : SCARA scaling factor ====<br />
Adjust X Y and Z scaling by entering the factor. 100% scaling (default) is represented by 1<br />
<br />
==== M370 : Morgan manual bed level - clear map ====<br />
Clear the map and prepare for calibration<br />
<br />
==== M371 : Move to next calibration position ====<br />
Move to the next position for calibration. User moves the bed towards the hotend until it just touches<br />
<br />
==== M372 : Record calibration value, and move to next position ====<br />
The position of the bed is recorded and the machine moves to the next position. Repeat until all positions programmed<br />
<br />
==== M373 : End bed level calibration mode ====<br />
<br />
==== M375 : Display matrix ====<br />
Display the bed level calibration matrix<br />
<br />
Store the calibration to EEPROM using M500<br />
<br />
== Proposed EEPROM configuration codes ==<br />
<br />
BRIEFLY: each RepRap has a number of physical parameters that should be persistent, but easily configurable, such as extrusion steps/mm, various max values, etc. Those parameters are currently hardcoded in the firmware, so that a user has to modify, recompile and re-flash the firmware for any adjustments. These configs can be stored in MCU's EEPROM and modified via some M-codes. Please see the detailed proposal at [[M-codes for EEPROM config]]. (''This is proposed by --[[User:AlexRa|AlexRa]] on 11-March-2011. There is currently no working implementation of the proposed commands'').<br />
<br />
[[Marlin]] uses these codes to manipulate EEPROM values.<br />
<br />
[[Sprinter]] has implemented the following commands to manipulate EEPROM [https://github.com/kliment/Sprinter/commit/4b1b0f1d96d2be2ed3941095f40a5c2d2bbb943d Commit message].<br />
<br />
[[Teacup]] uses codes M130-M136 to set, read, and save some parameters.<br />
<br />
=== M500: stores paramters in EEPROM ===<br />
<br />
=== M501: reads parameters from EEPROM ===<br />
If you need to reset them after you changed them temporarily<br />
<br />
=== M502: reverts to the default "factory settings". ===<br />
<br />
You still need to store them in EEPROM afterwards if you want to.<br />
<br />
=== M503: Print settings ===<br />
<br />
== Replies from the RepRap machine to the host computer ==<br />
<br />
All communication is in printable ASCII characters. Messages sent back<br />
to the host computer are terminated by a newline and look like this:<br />
<br />
'''xx [line number to resend] [T:93.2 B:22.9] [C: X:9.2 Y:125.4 Z:3.7 E:1902.5] [Some debugging or other information may be here]'''<br />
<br />
'''xx''' can be one of:<br />
<br />
'''ok'''<br />
<br />
'''rs'''<br />
<br />
'''<nowiki>!!</nowiki>'''<br />
<br />
'''ok''' means that no error has been detected.<br />
<br />
'''rs''' means resend, and is followed by the line number to resend.<br />
<br />
'''<nowiki>!!</nowiki>''' means that a hardware fault has been detected. The RepRap machine will<br />
shut down immediately after it has sent this message.<br />
<br />
The '''T:''' and '''B:''' values are the temperature of the currently-selected extruder <br />
and the bed respectively, and are only sent in response to M105. If such temperatures don't exist (for example for an extruder that works at room temperature and doesn't have a sensor) then a value below absolute zero (-273<sup>o</sup>C) is returned.<br />
<br />
'''C:''' means that coordinates follow. Those are the '''X: Y:''' etc values. These are only <br />
sent in response to M114 and M117.<br />
<br />
The RepRap machine may also send lines that look like this:<br />
<br />
'''// This is some debugging or other information on a line on its own. It may be sent at any time. '''<br />
<br />
Such lines will always be preceded by '''//'''.<br />
<br />
The most common response is simply:<br />
<br />
'''ok''' <br />
<br />
When the machine boots up it sends the string<br />
<br />
'''start'''<br />
<br />
once to the host before sending anything else. This should not be replaced or augmented<br />
by version numbers and the like. M115 (see above) requests those.<br />
<br />
All this means that every line sent by RepRap to the host computer except the start line has a two-character prefix (one of '''ok''', '''rs''', '''<nowiki>!!</nowiki>''' or '''//'''). The machine should never send a line without such a prefix.<br />
<br />
<br />
'''Exceptions''': Marlin 1.0.0 Gen6 Firmware does not follow the two character rule. 'rs' is actually 'Resend' and '!!' is 'Error'.<br />
Example Lines:<br />
* Error: Line Number is not current line + 1. Last Line: 7<br />
* Resend: 8<br />
* Writing to File: print.gco<br />
* Done saving file.<br />
* File opened:print.gco Size:22992<br />
* File selected<br />
<br />
<br />
When in the code base did this change take place and what other firmwares are affected?<br />
<br />
<br />
[[Category:Model manufacturing software]]<br />
<br />
== Proposal for sending multiple lines of G-code ==<br />
<br />
So far, this is a proposal, open for discussion.<br />
<br />
==== Problem to solve ====<br />
<br />
Each line of G-code sent from the host to the controller is answered with an '''ok''' before the next line can be sent without locking communcations up. This makes operations very slow, as the usual USB-TTL converters and probably also the host's operating system drivers come with substantial latency, often 10&nbsp;milliseconds. <br />
<br />
For more details on this proposal, and some suggested solutions, and comments please see [[GCODE_buffer_multiline_proposal]]<br />
<br />
== Alternatives to G-code ==<br />
: ''Main article: [[Firmware/Alternative#alternatives to G-code]]''<br />
* [[Wikipedia: STEP-NC]]: "STEP-NC was designed to replace ... G-codes ... adding tolerance data ... [with a] XML format."<br />
* [[Elegant multispline motion controller]] "will not use G-code. It will use a custom language based on cubic Bezier curves. This allows for much better description of arcs and will result in much higher quality prints with a much lower data throughput requirements."</div>Bobchttps://reprap.org/mediawiki/index.php?title=RAMPS_Interface_Board&diff=109446RAMPS Interface Board2013-11-02T17:44:52Z<p>Bobc: /* Errors */</p>
<hr />
<div>{{Development<br />
<!--Header--><br />
|name = RAMPS-RIB<br />
|status = Experimental<br />
<!--Image--><br />
|image = RIB_concept.png<br />
<!--General--><br />
|description = RAMPS Interface Board for Arduino Due<br />
|license = GPL<br />
|author = bobc<br />
|reprap = Ramps<br />
|categories = [[:Category:Electronics|Electronics]]<br />
|cadModel = KiCAD<br />
|url = [https://github.com/bobc/bobc_hardware/tree/master/RAMPS-FD github]<br />
}}<br />
<br />
=Intro=<br />
<br />
The RAMPS Interface Board (RIB) is designed to sit between Due and RAMPS to perform level-shifting, and any other needed functions.<br />
<br />
<gallery><br />
Image:RIB_concept.png<br />
Image:RIB.svg<br />
Image:RIB-Interfacing.svg<br />
Image:RAMPS-RIB-Front.jpg<br />
Image:RAMPS-RIB-Back.jpg<br />
Image:RAMPS-RIB-Assembly.jpg<br />
</gallery><br />
<br />
= Source Files =<br />
Source files are hosted at github.<br />
[https://github.com/bobc/bobc_hardware/blob/master/RAMPS-FD/RIB-Schematic.pdf Schematic for v0.1]<br />
<br />
= Version 0.1 =<br />
<br />
== Status ==<br />
<br />
A prototype has been built, but there are some major issues:<br />
<br />
* gate drivers are not suitable<br />
* The surface mount connectors are quite expensive<br />
<br />
This project has been shelved in favour of [[RAMPS-FD]] which is compatible with Due and Mega, and has more features than RAMPS and can take advantage of the increased performance of the Due.<br />
<br />
== Features ==<br />
* 3.3V/5V level translations for endstops and UART TX/RX<br />
* gate drivers for RAMPS MOSFETs<br />
<br />
==Errors==<br />
* The analog inputs need to be routed to different pins on the Due, as it has less analog channels than Mega ''(not sure this is correct!)''</div>Bobchttps://reprap.org/mediawiki/index.php?title=RAMPS_Interface_Board&diff=109445RAMPS Interface Board2013-11-02T17:41:37Z<p>Bobc: /* Intro */</p>
<hr />
<div>{{Development<br />
<!--Header--><br />
|name = RAMPS-RIB<br />
|status = Experimental<br />
<!--Image--><br />
|image = RIB_concept.png<br />
<!--General--><br />
|description = RAMPS Interface Board for Arduino Due<br />
|license = GPL<br />
|author = bobc<br />
|reprap = Ramps<br />
|categories = [[:Category:Electronics|Electronics]]<br />
|cadModel = KiCAD<br />
|url = [https://github.com/bobc/bobc_hardware/tree/master/RAMPS-FD github]<br />
}}<br />
<br />
=Intro=<br />
<br />
The RAMPS Interface Board (RIB) is designed to sit between Due and RAMPS to perform level-shifting, and any other needed functions.<br />
<br />
<gallery><br />
Image:RIB_concept.png<br />
Image:RIB.svg<br />
Image:RIB-Interfacing.svg<br />
Image:RAMPS-RIB-Front.jpg<br />
Image:RAMPS-RIB-Back.jpg<br />
Image:RAMPS-RIB-Assembly.jpg<br />
</gallery><br />
<br />
= Source Files =<br />
Source files are hosted at github.<br />
[https://github.com/bobc/bobc_hardware/blob/master/RAMPS-FD/RIB-Schematic.pdf Schematic for v0.1]<br />
<br />
= Version 0.1 =<br />
<br />
== Status ==<br />
<br />
A prototype has been built, but there are some major issues:<br />
<br />
* gate drivers are not suitable<br />
* The surface mount connectors are quite expensive<br />
<br />
This project has been shelved in favour of [[RAMPS-FD]] which is compatible with Due and Mega, and has more features than RAMPS and can take advantage of the increased performance of the Due.<br />
<br />
== Features ==<br />
* 3.3V/5V level translations for endstops and UART TX/RX<br />
* gate drivers for RAMPS MOSFETs<br />
<br />
==Errors==<br />
* The analog inputs need to be routed to different pins on the Due, as it has less analog channels than Mega</div>Bobchttps://reprap.org/mediawiki/index.php?title=RAMPS_Interface_Board&diff=108829RAMPS Interface Board2013-10-24T22:34:07Z<p>Bobc: /* Intro */</p>
<hr />
<div>{{Development<br />
<!--Header--><br />
|name = RAMPS-RIB<br />
|status = Experimental<br />
<!--Image--><br />
|image = RIB_concept.png<br />
<!--General--><br />
|description = RAMPS Interface Board for Arduino Due<br />
|license = GPL<br />
|author = bobc<br />
|reprap = Ramps<br />
|categories = [[:Category:Electronics|Electronics]]<br />
|cadModel = KiCAD<br />
|url = [https://github.com/bobc/bobc_hardware/tree/master/RAMPS-FD github]<br />
}}<br />
<br />
=Intro=<br />
<br />
The RAMPS Interface Board (RIB) to designed to sit between Due and RAMPS to perform level-shifting, and any other needed functions.<br />
<br />
<gallery><br />
Image:RIB_concept.png<br />
Image:RIB.svg<br />
Image:RIB-Interfacing.svg<br />
Image:RAMPS-RIB-Front.jpg<br />
Image:RAMPS-RIB-Back.jpg<br />
Image:RAMPS-RIB-Assembly.jpg<br />
</gallery><br />
<br />
= Source Files =<br />
Source files are hosted at github.<br />
[https://github.com/bobc/bobc_hardware/blob/master/RAMPS-FD/RIB-Schematic.pdf Schematic for v0.1]<br />
<br />
= Version 0.1 =<br />
<br />
== Status ==<br />
<br />
A prototype has been built, but there are some major issues:<br />
<br />
* gate drivers are not suitable<br />
* The surface mount connectors are quite expensive<br />
<br />
This project has been shelved in favour of [[RAMPS-FD]] which is compatible with Due and Mega, and has more features than RAMPS and can take advantage of the increased performance of the Due.<br />
<br />
== Features ==<br />
* 3.3V/5V level translations for endstops and UART TX/RX<br />
* gate drivers for RAMPS MOSFETs<br />
<br />
==Errors==<br />
* The analog inputs need to be routed to different pins on the Due, as it has less analog channels than Mega</div>Bobchttps://reprap.org/mediawiki/index.php?title=RAMPS_Interface_Board&diff=108828RAMPS Interface Board2013-10-24T22:32:21Z<p>Bobc: </p>
<hr />
<div>{{Development<br />
<!--Header--><br />
|name = RAMPS-RIB<br />
|status = Experimental<br />
<!--Image--><br />
|image = RIB_concept.png<br />
<!--General--><br />
|description = RAMPS Interface Board for Arduino Due<br />
|license = GPL<br />
|author = bobc<br />
|reprap = Ramps<br />
|categories = [[:Category:Electronics|Electronics]]<br />
|cadModel = KiCAD<br />
|url = [https://github.com/bobc/bobc_hardware/tree/master/RAMPS-FD github]<br />
}}<br />
<br />
=Intro=<br />
<br />
The RAMPS Interface Board (RIB) to designed to sit between Due and RAMPS to perform level-shifting, and any other needed functions. See [[RAMPS-FD]].<br />
<br />
<gallery><br />
Image:RIB_concept.png<br />
Image:RIB.svg<br />
Image:RIB-Interfacing.svg<br />
Image:RAMPS-RIB-Front.jpg<br />
Image:RAMPS-RIB-Back.jpg<br />
Image:RAMPS-RIB-Assembly.jpg<br />
</gallery><br />
<br />
= Source Files =<br />
Source files are hosted at github.<br />
[https://github.com/bobc/bobc_hardware/blob/master/RAMPS-FD/RIB-Schematic.pdf Schematic for v0.1]<br />
<br />
= Version 0.1 =<br />
<br />
== Status ==<br />
<br />
A prototype has been built, but there are some major issues:<br />
<br />
* gate drivers are not suitable<br />
* The surface mount connectors are quite expensive<br />
<br />
This project has been shelved in favour of [[RAMPS-FD]] which is compatible with Due and Mega, and has more features than RAMPS and can take advantage of the increased performance of the Due.<br />
<br />
== Features ==<br />
* 3.3V/5V level translations for endstops and UART TX/RX<br />
* gate drivers for RAMPS MOSFETs<br />
<br />
==Errors==<br />
* The analog inputs need to be routed to different pins on the Due, as it has less analog channels than Mega</div>Bobchttps://reprap.org/mediawiki/index.php?title=RAMPS-FD&diff=108826RAMPS-FD2013-10-24T22:25:33Z<p>Bobc: </p>
<hr />
<div>{{Development<br />
<!--Header--><br />
|name = RAMPS-FD<br />
|status = working<br />
<!--Image--><br />
|image = RAMPS-FD_v1A.JPG<br />
<!--General--><br />
|description = RAMPS for Arduino Due<br />
|license = GPL<br />
|author = bobc<br />
|reprap = Ramps<br />
|categories = [[:Category:Electronics|Electronics]]<br />
|cadModel = KiCAD<br />
|url = [https://github.com/bobc/bobc_hardware/tree/master/RAMPS-FD github]<br />
}}<br />
= RAMPS For Arduino Due =<br />
<br />
RAMPS-FD v1.A is now in beta!<br />
<br />
<gallery><br />
Image:RAMPS-FD_v1A.JPG<br />
</gallery><br />
<br />
== Sources ==<br />
Source files are hosted at [https://github.com/bobc/bobc_hardware/tree/master/RAMPS-FD github].<br />
<br />
[https://github.com/bobc/bobc_hardware/blob/master/RAMPS-FD/RAMPS-FD-Schematic.pdf Schematic]</div>Bobchttps://reprap.org/mediawiki/index.php?title=RAMPS-FD&diff=108820RAMPS-FD2013-10-24T19:56:11Z<p>Bobc: </p>
<hr />
<div>{{Development<br />
<!--Header--><br />
|name = RAMPS-FD<br />
|status = working<br />
<!--Image--><br />
|image = RAMPS-FD_v1A.JPG<br />
<!--General--><br />
|description = RAMPS for Arduino Due<br />
|license = GPL<br />
|author = bobc<br />
|reprap = Ramps<br />
|categories = [[:Category:Electronics|Electronics]]<br />
|cadModel = KiCAD<br />
|url = [https://github.com/bobc/bobc_hardware/tree/master/RAMPS-FD github]<br />
}}<br />
= RAMPS For Arduino Due =<br />
<br />
RAMPS-FD v1.A is now in beta!<br />
<br />
== Sources ==<br />
Source files are hosted at [https://github.com/bobc/bobc_hardware/tree/master/RAMPS-FD github].<br />
<br />
[https://github.com/bobc/bobc_hardware/blob/master/RAMPS-FD/RAMPS-FD-Schematic.pdf Schematic]</div>Bobchttps://reprap.org/mediawiki/index.php?title=File:RAMPS-FD_v1A.JPG&diff=108819File:RAMPS-FD v1A.JPG2013-10-24T19:53:08Z<p>Bobc: </p>
<hr />
<div></div>Bobchttps://reprap.org/mediawiki/index.php?title=Arduino_Due_Based_Electronics&diff=108818Arduino Due Based Electronics2013-10-24T19:47:39Z<p>Bobc: /* Background */</p>
<hr />
<div>=Background=<br />
<br />
[http://arduino.cc/en/Main/ArduinoBoardDue Arduino Due]is an Arduino board that is using an ARM Cortex M3 CPU.<br />
<br />
AVR variants of Arduino are widely used by RepRap electronics, but the new Arduino Due is not compatible with AVR chips, partly because the Atmel SAM3X8E chip used on the Due operates at 3.3V and is not compatible with 5V, and also the Due requires firmware compiled for ARM Cortex.<br />
<br />
[[RAMPS]] for Arduino Mega is a popular platform, but RAMPS is not compatible with Arduino Due, mainly because the Due is 3.3V based and not 5V compatible. Worse, applying 5V to the Due's inputs will likely damage the chip.<br />
<br />
Therefore there are several possibilities:<br />
# create a new RAMPS variant which is compatible with the Due. Possibly could also be made backwards compatible with Mega.<br />
# create a RAMPS Interface Board (RIB) to sit between Due and RAMPS to perform level-shifting, and any other needed functions.<br />
<br />
=Solutions available or in design=<br />
<br />
==RADDS==<br />
<br />
RADDS is a version of RAMPS designed for Due.<br />
<br />
I don't know much about this, apart from the web page [http://www.dr-henschke.de/RADDS_due.html RADDS für den Arduino Due].<br />
<br />
[http://www.dr-henschke.de/RADDS_ob-re-1.jpg]<br />
<br />
==RAMPS-FD==<br />
<br />
[[RAMPS-FD]] is another version of RAMPS for Due.<br />
<br />
==RAMPS Interface Board (RIB)==<br />
<br />
See page [[RAMPS_Interface_Board]]<br />
<br />
=Notes for developers=<br />
<br />
== Useful resources ==<br />
<br />
* [http://arduino.cc/forum/index.php?PHPSESSID=acf48270e7b831fa783f8720629b32ba&topic=132130.0 Due pinout diagram]<br />
* [http://www.atmel.com/Images/doc11057.pdf SAM3X Series datasheet]<br />
<br />
== Significant differences between Arduino Mega and Arduino Due ==<br />
<br />
* CPU operates at 3.3V<br />
* High-current IO pins are capable of 15 mA source, 9 mA sink<br />
* Low-current IO pins capable of 3 mA source, 6 mA sink<br />
* CPU package has an absolute max of 130mA<br />
* The Due has 1 dedicated SPI port, and 4 multipurpose USART/SPI ports. The SPI port is only routed to the 6 pin header used for ICSP on Mega, but this is not used for ICSP on Due.<br />
* The Due does not have any EEPROM<br />
<br />
== Hardware issues ==<br />
<br />
* MOSFETs need to be compatible with threshold voltage of 3.3V or better have a gate driver which allows any MOSFET to be used<br />
* Expansion pins need to be level-translated, but this depends on how they are used<br />
** Add ons: SD card, thermocouple drivers, LCD boards<br />
* Is heat dissipation of Due ok with RAMPS shield over it?<br />
* Some opto-endstops need 5V power, and return 5V on signal<br />
* (AUX-3) The SPI pins on the Mega (mapped to pins D50-52) are not SPI pins on Due<br />
<br />
== Hardware features known to be compatible ==<br />
<br />
* The Allegro stepper drivers will run with VDD = 3.3V and the logic signals compatible with 3.3V. This should apply to all the Pololu style drivers.<br />
* Servos "should" be able to operate with +5V power and a PWM signal of 3.3V<br />
* Thermistors will operate at 3.3V but the Analog Ref is also 3.3V, so no changes should be necessary<br />
* Mechanical endstops should be OK, if they do not use external pullup to 5V<br />
<br />
== Add-on compatibility ==<br />
<br />
* [[Sdramps]] (AUX-3 SPI connector) This board has a 5->3.3 voltage regulator and a level translator. I think it will work and be compatible if powered from 5V, but will not work if powered at 3.3V, because the input to the regulator is too low.<br />
<br />
== Possible improvements ==<br />
<br />
* Move connectors near to board edge<br />
* Allow for latching or screw terminals<br />
<br />
== Firmware changes ==<br />
<br />
* Firmware needs to be compiled with ARM compiler (gcc)<br />
* Arduino libraries may be compatible<br />
* Any references to AVR CPU peripherals, AVR include files or AVR compiler features need to be ported<br />
* There is no EEPROM on the SAM3X.</div>Bobchttps://reprap.org/mediawiki/index.php?title=Arduino_Due_Based_Electronics&diff=108817Arduino Due Based Electronics2013-10-24T19:45:37Z<p>Bobc: </p>
<hr />
<div>=Background=<br />
<br />
[http://arduino.cc/en/Main/ArduinoBoardDue Arduino Due]is the new Arduino board that is using an ARM Cortex M3 CPU.<br />
<br />
AVR variants of Arduino are widely used by RepRap electronics, but the new Arduino Due is not compatible with AVR chips, partly because the Atmel SAM3X8E chip used on the Due operates at 3.3V and is not compatible with 5V, and also the Due requires firmware compiled for ARM Cortex.<br />
<br />
[[RAMPS]] for Arduino Mega is a popular platform, but RAMPS is not compatible with Arduino Due, mainly because the Due is 3.3V based and not 5V compatible. Worse, applying 5V to the Due's inputs will likely damage the chip.<br />
<br />
Therefore there are several possibilities:<br />
# create a new RAMPS variant which is compatible with the Due. Possibly could also be made backwards compatible with Mega.<br />
# create a RAMPS Interface Board (RIB) to sit between Due and RAMPS to perform level-shifting, and any other needed functions. <br />
<br />
=Solutions available or in design=<br />
<br />
==RADDS==<br />
<br />
RADDS is a version of RAMPS designed for Due.<br />
<br />
I don't know much about this, apart from the web page [http://www.dr-henschke.de/RADDS_due.html RADDS für den Arduino Due].<br />
<br />
[http://www.dr-henschke.de/RADDS_ob-re-1.jpg]<br />
<br />
==RAMPS-FD==<br />
<br />
[[RAMPS-FD]] is another version of RAMPS for Due.<br />
<br />
==RAMPS Interface Board (RIB)==<br />
<br />
See page [[RAMPS_Interface_Board]]<br />
<br />
=Notes for developers=<br />
<br />
== Useful resources ==<br />
<br />
* [http://arduino.cc/forum/index.php?PHPSESSID=acf48270e7b831fa783f8720629b32ba&topic=132130.0 Due pinout diagram]<br />
* [http://www.atmel.com/Images/doc11057.pdf SAM3X Series datasheet]<br />
<br />
== Significant differences between Arduino Mega and Arduino Due ==<br />
<br />
* CPU operates at 3.3V<br />
* High-current IO pins are capable of 15 mA source, 9 mA sink<br />
* Low-current IO pins capable of 3 mA source, 6 mA sink<br />
* CPU package has an absolute max of 130mA<br />
* The Due has 1 dedicated SPI port, and 4 multipurpose USART/SPI ports. The SPI port is only routed to the 6 pin header used for ICSP on Mega, but this is not used for ICSP on Due.<br />
* The Due does not have any EEPROM<br />
<br />
== Hardware issues ==<br />
<br />
* MOSFETs need to be compatible with threshold voltage of 3.3V or better have a gate driver which allows any MOSFET to be used<br />
* Expansion pins need to be level-translated, but this depends on how they are used<br />
** Add ons: SD card, thermocouple drivers, LCD boards<br />
* Is heat dissipation of Due ok with RAMPS shield over it?<br />
* Some opto-endstops need 5V power, and return 5V on signal<br />
* (AUX-3) The SPI pins on the Mega (mapped to pins D50-52) are not SPI pins on Due<br />
<br />
== Hardware features known to be compatible ==<br />
<br />
* The Allegro stepper drivers will run with VDD = 3.3V and the logic signals compatible with 3.3V. This should apply to all the Pololu style drivers.<br />
* Servos "should" be able to operate with +5V power and a PWM signal of 3.3V<br />
* Thermistors will operate at 3.3V but the Analog Ref is also 3.3V, so no changes should be necessary<br />
* Mechanical endstops should be OK, if they do not use external pullup to 5V<br />
<br />
== Add-on compatibility ==<br />
<br />
* [[Sdramps]] (AUX-3 SPI connector) This board has a 5->3.3 voltage regulator and a level translator. I think it will work and be compatible if powered from 5V, but will not work if powered at 3.3V, because the input to the regulator is too low.<br />
<br />
== Possible improvements ==<br />
<br />
* Move connectors near to board edge<br />
* Allow for latching or screw terminals<br />
<br />
== Firmware changes ==<br />
<br />
* Firmware needs to be compiled with ARM compiler (gcc)<br />
* Arduino libraries may be compatible<br />
* Any references to AVR CPU peripherals, AVR include files or AVR compiler features need to be ported<br />
* There is no EEPROM on the SAM3X.</div>Bobchttps://reprap.org/mediawiki/index.php?title=RepRap_Bounties&diff=108719RepRap Bounties2013-10-22T20:01:15Z<p>Bobc: /* Project exists, but is not listed */</p>
<hr />
<div>=Contributing to Open Source Development with Bounties=<br />
<br />
If you want to support Open Source projects, it couldn't be easier! Simply sign up to [http://www.Bountysource.com Bountysource], find the project and the issue you want to support. Then just pledge money for that issue. When the issue is closed, the reward will be paid to the developer.<br />
<br />
Bountysource administer all the details, for that they take a 10% fee. If you pledge $110, the developer will receive $100. Other Open Source bounty sites are available, if you wish to use an alternative.<br />
<br />
==Popular RepRap projects at Bountysource==<br />
<br />
<br />
[https://www.bountysource.com/trackers/32835-alexrj-slic3r Slic3r]<br />
<br />
[https://www.bountysource.com/trackers/69725-kintel-marlin Marlin firmware]<br />
<br />
[https://www.bountysource.com/trackers/266035-traumflug-teacup-firmware Teacup firmware]<br />
<br />
<br />
==Project exists, but is not listed==<br />
<br />
Ask the developer if they will add their projects to a bounty site. Note, the project may need to have an acceptable Open Source licence to qualify.<br />
<br />
==Issue not listed==<br />
<br />
If a project does not have the issue that you want, you can raise an issue. Before raising a new issue, it is best to try to discuss with the developers first, as your request may already be in work, or unfeasible, or needs clarifying as to what the request is. If you decide a new issue, you will need to sign up to Github, or wherever the project is hosted, and create a new issue in their issues tracker. Mark it "Feature Request" as appropriate. <br />
<br />
==Request for a new project==<br />
<br />
It may be that the development you want to support is a new project. In which case, you will need to find a developer to create a project. <br />
<br />
''Perhaps the way to support creation of new projects is to create a RepRap Meta-project, where people can raise issues which are new projects in themselves.''<br />
<br />
==Does a project have to use Github or git?==<br />
<br />
No, but using the guthub Issues tracker is the best way for Bountysource to track issues for you. The project files do not need to be stored in git or github, but they must be hosted at a web site that is compatible with Open Source projects.</div>Bobchttps://reprap.org/mediawiki/index.php?title=Talk:LRC&diff=108681Talk:LRC2013-10-22T09:15:56Z<p>Bobc: Created page with "'''Vote for deletion''' Please drop this whole idea, it's completely misguided and won't even work. LRC is not only a waste of time, it is detrimental to Open Source. If you..."</p>
<hr />
<div>'''Vote for deletion'''<br />
<br />
Please drop this whole idea, it's completely misguided and won't even work. LRC is not only a waste of time, it is detrimental to Open Source.<br />
<br />
If you care about Open Source, do not use LRC, it will cut you off from Open Source development. <br />
<br />
If you want to make some money for development, do not use LRC. It provides no legal or practical use. There is no queue of companies waiting to pay you for your idea.<br />
<br />
--[[User:Bobc|Bobc]] ([[User talk:Bobc|talk]]) 02:15, 22 October 2013 (PDT)</div>Bobchttps://reprap.org/mediawiki/index.php?title=Extruder_Expansion_Board&diff=108507Extruder Expansion Board2013-10-19T22:38:55Z<p>Bobc: Created page with "{{Development <!--Header--> |name = EXT6 |status = Experimental <!--Image--> |image = RAMPS-FD-EXT6.png <!--General--> |description = Extruder Expansion Board |license = GPL |..."</p>
<hr />
<div>{{Development<br />
<!--Header--><br />
|name = EXT6<br />
|status = Experimental<br />
<!--Image--><br />
|image = RAMPS-FD-EXT6.png<br />
<!--General--><br />
|description = Extruder Expansion Board<br />
|license = GPL<br />
|author = bobc<br />
|reprap = <br />
|categories = [[:Category:Electronics|Electronics]]<br />
|cadModel = KiCAD<br />
|url = [https://github.com/bobc/bobc_hardware/tree/master/RAMPS-FD-EXT github]<br />
}}<br />
= Extuder Expansion Board =<br />
<br />
An expansion board to allow up to 6 additional extruders to be operated.<br />
<br />
[[File:RAMPS-FD-EXT6.png]]<br />
<br />
== Prototype ==<br />
Features:<br />
<br />
* slots for 6 stepper driver modules<br />
* 6 thermistor inputs<br />
* 6 MOSFET outputs with PWM control<br />
* fast low latency SPI compatible interface<br />
* interface requires minimum number of pins<br />
* compatible with 3.3V or 5V electronics</div>Bobchttps://reprap.org/mediawiki/index.php?title=File:RAMPS-FD-EXT6.png&diff=108506File:RAMPS-FD-EXT6.png2013-10-19T22:35:41Z<p>Bobc: Extruder expansion board</p>
<hr />
<div>Extruder expansion board</div>Bobchttps://reprap.org/mediawiki/index.php?title=Arduino_Due_Based_Electronics&diff=108417Arduino Due Based Electronics2013-10-18T19:31:18Z<p>Bobc: Created page with "=Electronics solutions for Arduino Due= RAMPS for Arduino Mega is a popular platform, but RAMPS is not compatible with Arduino Due, mainly because the Due is 3.3V based and n..."</p>
<hr />
<div>=Electronics solutions for Arduino Due=<br />
<br />
RAMPS for Arduino Mega is a popular platform, but RAMPS is not compatible with Arduino Due, mainly because the Due is 3.3V based and not 5V compatible.<br />
<br />
==RADDS==<br />
<br />
I don't know much about this, apart from the web page [http://www.dr-henschke.de/RADDS_due.html RADDS für den Arduino Due].<br />
<br />
[http://www.dr-henschke.de/RADDS_ob-re-1.jpg]<br />
<br />
==RAMPS-FD==<br />
<br />
RAMPS-FD is another version of RAMPS for Due.</div>Bobchttps://reprap.org/mediawiki/index.php?title=RepRap_Bounties&diff=108416RepRap Bounties2013-10-18T19:21:31Z<p>Bobc: </p>
<hr />
<div>=Contributing to Open Source Development with Bounties=<br />
<br />
If you want to support Open Source projects, it couldn't be easier! Simply sign up to [http://www.Bountysource.com Bountysource], find the project and the issue you want to support. Then just pledge money for that issue. When the issue is closed, the reward will be paid to the developer.<br />
<br />
Bountysource administer all the details, for that they take a 10% fee. If you pledge $110, the developer will receive $100. Other Open Source bounty sites are available, if you wish to use an alternative.<br />
<br />
==Popular RepRap projects at Bountysource==<br />
<br />
<br />
[https://www.bountysource.com/trackers/32835-alexrj-slic3r Slic3r]<br />
<br />
[https://www.bountysource.com/trackers/69725-kintel-marlin Marlin firmware]<br />
<br />
[https://www.bountysource.com/trackers/266035-traumflug-teacup-firmware Teacup firmware]<br />
<br />
<br />
==Project exists, but is not listed==<br />
<br />
Ask the developer if they will add their projects to a bounty site. Note, the project must have an acceptable Open Source licence to qualify.<br />
<br />
==Issue not listed==<br />
<br />
If a project does not have the issue that you want, you can raise an issue. Before raising a new issue, it is best to try to discuss with the developers first, as your request may already be in work, or unfeasible, or needs clarifying as to what the request is. If you decide a new issue, you will need to sign up to Github, or wherever the project is hosted, and create a new issue in their issues tracker. Mark it "Feature Request" as appropriate. <br />
<br />
==Request for a new project==<br />
<br />
It may be that the development you want to support is a new project. In which case, you will need to find a developer to create a project. <br />
<br />
''Perhaps the way to support creation of new projects is to create a RepRap Meta-project, where people can raise issues which are new projects in themselves.''<br />
<br />
==Does a project have to use Github or git?==<br />
<br />
No, but using the guthub Issues tracker is the best way for Bountysource to track issues for you. The project files do not need to be stored in git or github, but they must be hosted at a web site that is compatible with Open Source projects.</div>Bobchttps://reprap.org/mediawiki/index.php?title=RepRap_Bounties&diff=108415RepRap Bounties2013-10-18T19:19:43Z<p>Bobc: </p>
<hr />
<div>=Contributing to Open Source Development with Bounties=<br />
<br />
If you want to support Open Source projects, it couldn't be easier! Simply sign up to [http://www.Bountysource.com Bountysource], find the project and the issue you want to support. Then just pledge money for that issue. When the issue is closed, the reward will be paid to the developer.<br />
<br />
Bountysource administer all the details, for that they take a 10% fee. If you pledge $110, the developer will receive $100. Other Open Source bounty sites are available, if you wish to use an alternative.<br />
<br />
==Popular RepRap projects at Bountysource==<br />
<br />
<br />
[https://www.bountysource.com/trackers/32835-alexrj-slic3r Slic3r]<br />
<br />
[https://www.bountysource.com/trackers/69725-kintel-marlin Marlin firmware]<br />
<br />
[https://www.bountysource.com/trackers/266035-traumflug-teacup-firmware Teacup firmware]<br />
<br />
<br />
==Project exists, but is not listed==<br />
<br />
Ask the developer if they will add their projects to a bounty site. Note, the project must have an acceptable Open Source licence to qualify.<br />
<br />
==Issue not listed==<br />
<br />
If a project does not have the issue that you want, you can raise an issue. Before raising a new issue, it is best to try to discuss with the developers first, as your request may already be in work, or unfeasible, or needs clarifying as to what the request is. If you decide a new issue, you will need to sign up to Github, or wherever the project is hosted, and create a new issue in their issues tracker. Mark it "Feature Request" as appropriate. <br />
<br />
==Request for a new project==<br />
<br />
It may be that the development you want to support is a new project. In which case, you will need to find a developer to create a project. Perhaps the way to do that is to create a RepRap Meta-project, where people can raise issues which are new projects in themselves.<br />
<br />
==Does a project have to use Github or git?==<br />
<br />
No, but using the guthub Issues tracker is the best way for Bountysource to track issues for you. The project files do not need to be stored in git or github, but they must be hosted at a web site that is compatible with Open Source projects.</div>Bobchttps://reprap.org/mediawiki/index.php?title=RepRap_Bounties&diff=108411RepRap Bounties2013-10-18T19:02:11Z<p>Bobc: </p>
<hr />
<div>=Contributing to Open Source Development with Bounties=<br />
<br />
If you want to support Open Source projects, it couldn't be easier! Simply sign up to [http://www.Bountysource.com Bountysource], find the project and the issue you want to support. Then just pledge money for that issue. When the issue is closed, the reward will be paid to the developer.<br />
<br />
Bountysource administer all the details, for that they take a 10% fee. If you pledge $110, the developer will receive $100. Other Open Source bounty sites are available, if you wish to use an alternative.<br />
<br />
==Project exists, but is not listed==<br />
<br />
Ask the developer if they will add their projects to a bounty site. Note, the project must have an acceptable Open Source licence to qualify.<br />
<br />
==Issue not listed==<br />
<br />
If a project does not have the issue that you want, you can raise an issue. Before raising a new issue, it is best to try to discuss with the developers first, as your request may already be in work, or unfeasible, or needs clarifying as to what the request is. If you decide a new issue, you will need to sign up to Github, or wherever the project is hosted, and create a new issue in their issues tracker. Mark it "Feature Request" as appropriate. <br />
<br />
==Request for a new project==<br />
<br />
It may be that the development you want to support is a new project. In which case, you will need to find a developer to create a project. Perhaps the way to do that is to create a RepRap Meta-project, where people can raise issues which are new projects in themselves.<br />
<br />
==Does a project have to use Github or git?==<br />
<br />
No, but using the guthub Issues tracker is the best way for Bountysource to track issues for you. The project files do not need to be stored in git or github, but they must be hosted at a web site that is compatible with Open Source projects.</div>Bobchttps://reprap.org/mediawiki/index.php?title=RepRap_Bounties&diff=108410RepRap Bounties2013-10-18T19:00:48Z<p>Bobc: Created page with "=Contributing to Open Source Development with Bounties= If you want to support Open Source projects, it couldn't be easier! Simply sign up to [http://www.Bountysource.com Bou..."</p>
<hr />
<div>=Contributing to Open Source Development with Bounties=<br />
<br />
If you want to support Open Source projects, it couldn't be easier! Simply sign up to [http://www.Bountysource.com Bountysource], find the project and the issue you want to support. Then just pledge money for that issue. When the issue is closed, the reward will be paid to the developer.<br />
<br />
Bountysource administer all the details, for that they take a 10% fee. Other Open Source bounty sites are available, if you wish to use an alternative.<br />
<br />
==Project exists, but is not listed==<br />
<br />
Ask the developer if they will add their projects to a bounty site. Note, the project must have an acceptable Open Source licence to qualify.<br />
<br />
==Issue not listed==<br />
<br />
If a project does not have the issue that you want, you can raise an issue. Before raising a new issue, it is best to try to discuss with the developers first, as your request may already be in work, or unfeasible, or needs clarifying as to what the request is. If you decide a new issue, you will need to sign up to Github, or wherever the project is hosted, and create a new issue in their issues tracker. Mark it "Feature Request" as appropriate. <br />
<br />
==Request for a new project==<br />
<br />
It may be that the development you want to support is a new project. In which case, you will need to find a developer to create a project. Perhaps the way to do that is to create a RepRap Meta-project, where people can raise issues which are new projects in themselves.<br />
<br />
==Does a project have to use Github or git?==<br />
<br />
No, but using the guthub Issues tracker is the best way for Bountysource to track issues for you. The project files do not need to be stored in git or github, but they must be hosted at a web site that is compatible with Open Source projects.</div>Bobchttps://reprap.org/mediawiki/index.php?title=LRC&diff=107721LRC2013-10-08T17:42:57Z<p>Bobc: </p>
<hr />
<div><br />
{{Development<br />
|name = LRC<br />
|status = concept<br />
|image = <br />
|description = A new Open Hardware licence model<br />
|license = [[LRC]]<br />
|author = KalleP<br />
|reprap = many giants<br />
|categories = {{tag:Licences}}<br />
|cadModel = <br />
|url = <br />
}}<br />
<br />
'''This page describes a license model that is in direct contradiction to the RepRap ethos. Please see http://reprap.org/wiki/RepRap_and_Open_Source. Please consider removing it.'''<br />
<br />
----<br />
<br />
<br />
=Licence Required for Commercial use=<br />
<br />
=Introduction=<br />
<br />
A significant problem exists in the larger Open Hardware community that directly affects the RepRap community as well.<br />
<br />
It pertains to the lack of a usable licensing model for ideas and designs that are disclosed to the public.<br />
<br />
The main failing is that none of the usual Open Source Software models cover the compensation of hardware development costs in any way and in a sense victimise the developers who chooses to publish.<br />
<br />
There has been much ongoing discussion in various fora about this problem but no resolution in sight as yet.<br />
<br />
This page is intended as a place holder to one such proposal.<br />
<br />
I hope others will try and round out the license if I have made some gross error in my estimation<br />
<br />
==LRC 0.1==<br />
<br />
This design or idea is free for all non-commercial use and available for commercial<br />
licensing where allowed. <br />
Fair compensation is requested by the developer from profits. <br />
Your word is your bond.<br />
<br />
==LRC 1.0==<br />
<br />
<pre>This after the first round of consensus has been achieved.</pre><br />
<br />
==Thoughts==<br />
<br />
The latest version will be implied if no version number is specified.<br />
<br />
Open source is an option but not required beyond what is needed to use the design or idea. Commented code, reference citations and formula derivations is a privilege to the end user and not an automatic right. Compiled design files (sliced 3D models) or printer ready files (PS or PFD) would be allowed. Reverse engineering or decompilation for personal use would be allowed but commercial use of such would require a licence agreement.<br />
<br />
A licensing agreement, in spirit, comes into force automatically if profits are made from the use of the design or idea. Payment of 1-20% of net profits would be a fair gesture for something that you use to make money. Negotiated licences can specify any compensation that is mutually agreeable. Payment of licence fees to a charity or Open Hardware related foundation are acceptable if the designers is not contactable of waives any fees.<br />
<br />
The scope of the idea that is covered is what is disclosed much as in a patent document. If it gives you a new idea then you can publish your new idea. If your new idea makes you very rich you can share some of the wealth with those you helped you come up with your idea.<br />
<br />
The idea is to say the maximum amount with the minimum words and offer the most meaning to a regular person. Nitpickers do not need to be accommodated. Those planing to abuse the spirit of the agreement need not be accommodated. Those wanting to get involved in development must have their rights clearly spelt out so they can see why they should apply this licence model to their work.<br />
<br />
Exclusions will exist but must be assumed, such as it would be pointless and immoral to place this licence on work that is known to be under trade secret, patent or other more restrictive licence. The reach of this licence would be universal in location and for all sentient beings. All legal wording is assumed where it might be required (gender, plurals, individuals/incorporated persons etc.) but left out as it should never see a court of law except as an example of best practice.<br />
<br />
It can be used in companionship with other Open Source licence models if it does not conflict directly with them and you want to carry over some of their fame or good will. Remember that they confer no protection on ideas and designs so technically they are the more open licence models compared to this.<br />
<br />
==Links==<br />
<br />
* [http://forums.reprap.org/read.php?1,250832 Compopoly - a fairer reward system for value creators?]<br />
* [http://forums.reprap.org/read.php?1,249120 An internal struggle between the "we" and the "me" on the community and IP]</div>Bobchttps://reprap.org/mediawiki/index.php?title=Marlin_Electronics&diff=96855Marlin Electronics2013-06-29T11:41:16Z<p>Bobc: </p>
<hr />
<div>{{Development<br />
|name = Marlin Electronics<br />
|status = development<br />
|description = ARM-Based reprap electronics<br />
|author = Erik van der Zalm<br />
|license = GPL<br />
|categories = [[:Category:Electronics|Electronics]], [[:Category:Development|Development]]<br />
|download = [https://github.com/ErikZalm/Marlin-II]<br />
}}<br />
== About Marlin Electronics ==<br />
<br />
TBD<br />
<br />
== About Marlin-II Firmware ==<br />
<br />
TBD<br />
<br />
== Compiling and uploading ==<br />
<br />
<br />
=== Overview ===<br />
<br />
# Grab the firmware [https://github.com/ErikZalm/Marlin-II here].<br />
# Compile the firmware OR get a precompiled one<br />
# Upload the firmware to the hardware</div>Bobchttps://reprap.org/mediawiki/index.php?title=Power_Supply&diff=93440Power Supply2013-05-26T14:51:25Z<p>Bobc: /* Suppliers */</p>
<hr />
<div>Most Reprap electronics use 12V DC ranging from 5A-20A.<br />
<br />
The motors plus single hotend take up to 5A or so, a heated bed typically takes 5A-15A. So for a standard setup with heated bed, look to about 18-20A total which is about 220-240W at 12V. For some setups you might be able to use less power.<br />
<br />
There are several different options of power supply that can be used and are commonly available.<br />
<br />
==Computer PSUs== <br />
<br />
<gallery><br />
Image:PC_PSU.jpg<br />
Image:Server psu.JPG<br />
</gallery><br />
<br />
===Standard PC===<br />
These provide 12V, 5V and 5V standby.<br />
<br />
A PSU from a standard PC can be used. Some electronics have connectors for direct connection to the PSU Molex connectors, for other electronics the connectors will need to be cut and connection to stripped wires made. Some electronics can use the Power-On signal to wake up the PSU from standby.<br />
<br />
PC power supplies vary a lot in quality, and many can not provide the rated power. A typical PC PSU can usually provide about half its rated voltage on the 12V lines, so it is best to use a power supply rated 400W or above. Otherwise the PSU will struggle to maintain 12V output. PC PSUs should have thermal overload protection, and shut down safely on overload, but again poor quality ones may not do so before overheating.<br />
<br />
To use a PC PSU power supply, it is necessary to jumper the "power on" signal to ground, and often it is needed to supply a load on the 5V rail to get good regulation of the 12V rail.<br />
<br />
See here for more details:<br />
*[[PCPowerSupply]] using a computer power supply<br />
<br />
===Server PSU===<br />
There are also PSUs taken from servers which can be used. These usually provide 12V only, but a LOT of current (32A), and quite cheap.<br />
<br />
They usually have a proprietary connector designed for rack mount systems, so need some custom wiring depending on the model.<br />
<br />
Here are instructions for HP PS-3381-1C1 400W PSUs http://www.rcgroups.com/forums/showthread.php?t=358340<br />
<br />
==Power Brick==<br />
<br />
<gallery><br />
Image:Psu-brick.jpg<br />
Image:Psu-xbox360-203w.jpg<br />
</gallery><br />
<br />
===General purpose power bricks===<br />
<br />
These come in a variety of types up to around 240W, for normal use select a 12V 220W version. Also available are 24V versions.<br />
<br />
They often come with a barrel type or 4 pin connector. The 4 pin connector is sometimes called "mini-DIN" or "power DIN", but is not a standard DIN connector. <br />
<br />
Also the pin assignments can vary, but for most boards you will need to cut the connector off or make an adaptor.<br />
<br />
References:<br />
http://en.wikipedia.org/wiki/DC_connector#Snap_and_lock_DC_power_connectors<br />
<br />
===Laptop chargers===<br />
<br />
Here are instructions for converting a Dell laptop charger : http://lbmakersociety.org/2012/12/creating-hacking-a-reprap-power-supply-for-ramps/<br />
<br />
===XBOX 360 PSU===<br />
<br />
There are several versions, choose the 203W version. Note that the power may be insufficient for some heated beds. The PSU will shutdown if an overload occurs.<br />
<br />
These provide 12V, 5V and 5V standby and power on input.<br />
<br />
The XBOX power connector can be cut off and connections made to stripped wire, or make an adaptor with an XBOX power socket (sold as spares on eBay etc).<br />
<br />
How to use XBOX 360 PSU with Reprap : http://www.thingiverse.com/thing:13980<br />
<br />
==OEM type PSU==<br />
<br />
<gallery><br />
Image:Oem type psu.jpg<br />
</gallery><br />
<br />
These are designed to be wired into custom installations. They have exposed mains connections which should be enclosed to prevent access. It is recommended to get closed frame types, but these still have exposed mains connections.<br />
<br />
They come in several versions, 12V or 24V and up to 400W.<br />
<br />
The input voltage is usually universal, switchable between 110V and 220V, or sometimes fixed 110V or 220V. Check that it is compatible with your mains voltage before purchasing.<br />
<br />
Using OEM PSU with Repap : [[RepRapPro_Mendel_power_supply]]<br />
<br />
=Suppliers=<br />
<br />
<br />
{| class="wikitable sortable"<br />
|+ <br />
|-<br />
| Vendors (link to product) || Shipping location || Manufacturer || Model # (link to datasheet) || Input || Output(V/A) || Tested || Additional notes<br />
|-<br />
| [http://www.lulzbot.com/en/electronics/146-12vdc-20a-240w-power-supply.html lulzbot]|| USA<br />
| MW || S-240-12<br />
| 110V or 220V || 12V 20A || {{true}} || <br />
|-<br />
| [http://www.google.com/search?q=site:ebay.com+hp+3381+psu ebay]||Various<br />
| HP|| HP PS 3381<br />
| 110V or 220V || 12V 32A || {{true}} || <br />
|-<br />
| [http://www.google.com/search?q=site:ebay.com+12v+240w+power+supply+switching ebay]||Various<br />
| Various|| 12V 240W switching PSU<br />
| 110V or 220V || 12V 20A || || <br />
|}<br />
<br />
=See also=<br />
<br />
[[RAMPS_1.4#Wiring]]<br />
<br />
http://en.wikipedia.org/wiki/Power_supply</div>Bobchttps://reprap.org/mediawiki/index.php?title=Power_Supply&diff=93437Power Supply2013-05-26T14:34:29Z<p>Bobc: /* Suppliers */</p>
<hr />
<div>Most Reprap electronics use 12V DC ranging from 5A-20A.<br />
<br />
The motors plus single hotend take up to 5A or so, a heated bed typically takes 5A-15A. So for a standard setup with heated bed, look to about 18-20A total which is about 220-240W at 12V. For some setups you might be able to use less power.<br />
<br />
There are several different options of power supply that can be used and are commonly available.<br />
<br />
==Computer PSUs== <br />
<br />
<gallery><br />
Image:PC_PSU.jpg<br />
Image:Server psu.JPG<br />
</gallery><br />
<br />
===Standard PC===<br />
These provide 12V, 5V and 5V standby.<br />
<br />
A PSU from a standard PC can be used. Some electronics have connectors for direct connection to the PSU Molex connectors, for other electronics the connectors will need to be cut and connection to stripped wires made. Some electronics can use the Power-On signal to wake up the PSU from standby.<br />
<br />
PC power supplies vary a lot in quality, and many can not provide the rated power. A typical PC PSU can usually provide about half its rated voltage on the 12V lines, so it is best to use a power supply rated 400W or above. Otherwise the PSU will struggle to maintain 12V output. PC PSUs should have thermal overload protection, and shut down safely on overload, but again poor quality ones may not do so before overheating.<br />
<br />
To use a PC PSU power supply, it is necessary to jumper the "power on" signal to ground, and often it is needed to supply a load on the 5V rail to get good regulation of the 12V rail.<br />
<br />
See here for more details:<br />
*[[PCPowerSupply]] using a computer power supply<br />
<br />
===Server PSU===<br />
There are also PSUs taken from servers which can be used. These usually provide 12V only, but a LOT of current (32A), and quite cheap.<br />
<br />
They usually have a proprietary connector designed for rack mount systems, so need some custom wiring depending on the model.<br />
<br />
Here are instructions for HP PS-3381-1C1 400W PSUs http://www.rcgroups.com/forums/showthread.php?t=358340<br />
<br />
==Power Brick==<br />
<br />
<gallery><br />
Image:Psu-brick.jpg<br />
Image:Psu-xbox360-203w.jpg<br />
</gallery><br />
<br />
===General purpose power bricks===<br />
<br />
These come in a variety of types up to around 240W, for normal use select a 12V 220W version. Also available are 24V versions.<br />
<br />
They often come with a barrel type or 4 pin connector. The 4 pin connector is sometimes called "mini-DIN" or "power DIN", but is not a standard DIN connector. <br />
<br />
Also the pin assignments can vary, but for most boards you will need to cut the connector off or make an adaptor.<br />
<br />
References:<br />
http://en.wikipedia.org/wiki/DC_connector#Snap_and_lock_DC_power_connectors<br />
<br />
===Laptop chargers===<br />
<br />
Here are instructions for converting a Dell laptop charger : http://lbmakersociety.org/2012/12/creating-hacking-a-reprap-power-supply-for-ramps/<br />
<br />
===XBOX 360 PSU===<br />
<br />
There are several versions, choose the 203W version. Note that the power may be insufficient for some heated beds. The PSU will shutdown if an overload occurs.<br />
<br />
These provide 12V, 5V and 5V standby and power on input.<br />
<br />
The XBOX power connector can be cut off and connections made to stripped wire, or make an adaptor with an XBOX power socket (sold as spares on eBay etc).<br />
<br />
How to use XBOX 360 PSU with Reprap : http://www.thingiverse.com/thing:13980<br />
<br />
==OEM type PSU==<br />
<br />
<gallery><br />
Image:Oem type psu.jpg<br />
</gallery><br />
<br />
These are designed to be wired into custom installations. They have exposed mains connections which should be enclosed to prevent access. It is recommended to get closed frame types, but these still have exposed mains connections.<br />
<br />
They come in several versions, 12V or 24V and up to 400W.<br />
<br />
The input voltage is usually universal, switchable between 110V and 220V, or sometimes fixed 110V or 220V. Check that it is compatible with your mains voltage before purchasing.<br />
<br />
Using OEM PSU with Repap : [[RepRapPro_Mendel_power_supply]]<br />
<br />
=Suppliers=<br />
<br />
<br />
{| class="wikitable sortable"<br />
|+ <br />
|-<br />
| Vendors (link to product) || Shipping location || Manufacturer || Model # (link to datasheet) || Input || Output(V/A) || Tested || Additional notes<br />
|-<br />
| [http://www.lulzbot.com/en/electronics/146-12vdc-20a-240w-power-supply.html lulzbot]|| USA<br />
| MW || S-240-12<br />
| 110V or 220V || 12V 20A || {{true}} || <br />
| -<br />
| [https://www.google.com/search?q=site:ebay.com+hp+3381+psu ebay]||Various<br />
| HP|| HP PS 3381<br />
| 110V or 220V || 12V 32A || {{true}} || <br />
|}<br />
<br />
=See also=<br />
<br />
[[RAMPS_1.4#Wiring]]<br />
<br />
http://en.wikipedia.org/wiki/Power_supply</div>Bobchttps://reprap.org/mediawiki/index.php?title=Power_Supply&diff=93434Power Supply2013-05-26T14:05:00Z<p>Bobc: </p>
<hr />
<div>Most Reprap electronics use 12V DC ranging from 5A-20A.<br />
<br />
The motors plus single hotend take up to 5A or so, a heated bed typically takes 5A-15A. So for a standard setup with heated bed, look to about 18-20A total which is about 220-240W at 12V. For some setups you might be able to use less power.<br />
<br />
There are several different options of power supply that can be used and are commonly available.<br />
<br />
==Computer PSUs== <br />
<br />
<gallery><br />
Image:PC_PSU.jpg<br />
Image:Server psu.JPG<br />
</gallery><br />
<br />
===Standard PC===<br />
These provide 12V, 5V and 5V standby.<br />
<br />
A PSU from a standard PC can be used. Some electronics have connectors for direct connection to the PSU Molex connectors, for other electronics the connectors will need to be cut and connection to stripped wires made. Some electronics can use the Power-On signal to wake up the PSU from standby.<br />
<br />
PC power supplies vary a lot in quality, and many can not provide the rated power. A typical PC PSU can usually provide about half its rated voltage on the 12V lines, so it is best to use a power supply rated 400W or above. Otherwise the PSU will struggle to maintain 12V output. PC PSUs should have thermal overload protection, and shut down safely on overload, but again poor quality ones may not do so before overheating.<br />
<br />
To use a PC PSU power supply, it is necessary to jumper the "power on" signal to ground, and often it is needed to supply a load on the 5V rail to get good regulation of the 12V rail.<br />
<br />
See here for more details:<br />
*[[PCPowerSupply]] using a computer power supply<br />
<br />
===Server PSU===<br />
There are also PSUs taken from servers which can be used. These usually provide 12V only, but a LOT of current (32A), and quite cheap.<br />
<br />
They usually have a proprietary connector designed for rack mount systems, so need some custom wiring depending on the model.<br />
<br />
Here are instructions for HP PS-3381-1C1 400W PSUs http://www.rcgroups.com/forums/showthread.php?t=358340<br />
<br />
==Power Brick==<br />
<br />
<gallery><br />
Image:Psu-brick.jpg<br />
Image:Psu-xbox360-203w.jpg<br />
</gallery><br />
<br />
===General purpose power bricks===<br />
<br />
These come in a variety of types up to around 240W, for normal use select a 12V 220W version. Also available are 24V versions.<br />
<br />
They often come with a barrel type or 4 pin connector. The 4 pin connector is sometimes called "mini-DIN" or "power DIN", but is not a standard DIN connector. <br />
<br />
Also the pin assignments can vary, but for most boards you will need to cut the connector off or make an adaptor.<br />
<br />
References:<br />
http://en.wikipedia.org/wiki/DC_connector#Snap_and_lock_DC_power_connectors<br />
<br />
===Laptop chargers===<br />
<br />
Here are instructions for converting a Dell laptop charger : http://lbmakersociety.org/2012/12/creating-hacking-a-reprap-power-supply-for-ramps/<br />
<br />
===XBOX 360 PSU===<br />
<br />
There are several versions, choose the 203W version. Note that the power may be insufficient for some heated beds. The PSU will shutdown if an overload occurs.<br />
<br />
These provide 12V, 5V and 5V standby and power on input.<br />
<br />
The XBOX power connector can be cut off and connections made to stripped wire, or make an adaptor with an XBOX power socket (sold as spares on eBay etc).<br />
<br />
How to use XBOX 360 PSU with Reprap : http://www.thingiverse.com/thing:13980<br />
<br />
==OEM type PSU==<br />
<br />
<gallery><br />
Image:Oem type psu.jpg<br />
</gallery><br />
<br />
These are designed to be wired into custom installations. They have exposed mains connections which should be enclosed to prevent access. It is recommended to get closed frame types, but these still have exposed mains connections.<br />
<br />
They come in several versions, 12V or 24V and up to 400W.<br />
<br />
The input voltage is usually universal, switchable between 110V and 220V, or sometimes fixed 110V or 220V. Check that it is compatible with your mains voltage before purchasing.<br />
<br />
Using OEM PSU with Repap : [[RepRapPro_Mendel_power_supply]]<br />
<br />
=Suppliers=<br />
<br />
<br />
{| class="wikitable sortable"<br />
|+ <br />
|-<br />
| Vendors (link to product) || Shipping location || Manufacturer || Model # (link to datasheet) || Input || Output(V/A) || Tested || Additional notes<br />
|-<br />
| [http://www.lulzbot.com/en/electronics/146-12vdc-20a-240w-power-supply.html lulzbot]|| USA<br />
| MW || S-240-12<br />
| 110V or 220V || 12V 20A || {{true}} || <br />
|}<br />
<br />
=See also=<br />
<br />
[[RAMPS_1.4#Wiring]]<br />
<br />
http://en.wikipedia.org/wiki/Power_supply</div>Bobchttps://reprap.org/mediawiki/index.php?title=Power_Supply&diff=93432Power Supply2013-05-26T14:04:03Z<p>Bobc: </p>
<hr />
<div>Most Reprap electronics use 12V DC ranging from 5A-20A.<br />
<br />
The motors plus single hotend take up to 5A or so, a heated bed typically takes 5A-15A. So for a standard setup with heated bed, look to about 18-20A total which is about 220-240W at 12V. For some setups you might be able to use less power.<br />
<br />
There are several different options of power supply that can be used and are commonly available.<br />
<br />
==Computer PSUs== <br />
<br />
<gallery><br />
Image:PC_PSU.jpg<br />
Image:Server psu.JPG<br />
</gallery><br />
<br />
===Standard PC===<br />
These provide 12V, 5V and 5V standby.<br />
<br />
A PSU from a standard PC can be used. Some electronics have connectors for direct connection to the PSU Molex connectors, for other electronics the connectors will need to be cut and connection to stripped wires made. Some electronics can use the Power-On signal to wake up the PSU from standby.<br />
<br />
PC power supplies vary a lot in quality, and many can not provide the rated power. A typical PC PSU can usually provide about half its rated voltage on the 12V lines, so it is best to use a power supply rated 400W or above. Otherwise the PSU will struggle to maintain 12V output. PC PSUs should have thermal overload protection, and shut down safely on overload, but again poor quality ones may not do so before overheating.<br />
<br />
To use a PC PSU power supply, it is necessary to jumper the "power on" signal to ground, and often it is needed to supply a load on the 5V rail to get good regulation of the 12V rail.<br />
<br />
See here for more details:<br />
*[[PCPowerSupply]] using a computer power supply<br />
<br />
===Server PSU===<br />
There are also PSUs taken from servers which can be used. These usually provide 12V only, but a LOT of current (32A), and quite cheap.<br />
<br />
They usually have a proprietary connector designed for rack mount systems, so need some custom wiring depending on the model.<br />
<br />
Here are instructions for HP PS-3381-1C1 400W PSUs http://www.rcgroups.com/forums/showthread.php?t=358340<br />
<br />
==Power Brick==<br />
<br />
<gallery><br />
Image:Psu-brick.jpg<br />
Image:Psu-xbox360-203w.jpg<br />
</gallery><br />
<br />
===General purpose power bricks===<br />
<br />
These come in a variety of types up to around 240W, for normal use select a 12V 220W version. Also available are 24V versions.<br />
<br />
They often come with a barrel type or 4 pin connector. The 4 pin connector is sometimes called "mini-DIN" or "power DIN", but is not a standard DIN connector. <br />
<br />
Also the pin assignments can vary, but for most boards you will need to cut the connector off or make an adaptor.<br />
<br />
References:<br />
http://en.wikipedia.org/wiki/DC_connector#Snap_and_lock_DC_power_connectors<br />
<br />
==Laptop chargers==<br />
<br />
Here are instructions for converting a Dell laptop charger : http://lbmakersociety.org/2012/12/creating-hacking-a-reprap-power-supply-for-ramps/<br />
<br />
===XBOX 360 PSU===<br />
<br />
There are several versions, choose the 203W version. Note that the power may be insufficient for some heated beds. The PSU will shutdown if an overload occurs.<br />
<br />
These provide 12V, 5V and 5V standby and power on input.<br />
<br />
The XBOX power connector can be cut off and connections made to stripped wire, or make an adaptor with an XBOX power socket (sold as spares on eBay etc).<br />
<br />
How to use XBOX 360 PSU with Reprap : http://www.thingiverse.com/thing:13980<br />
<br />
==OEM type PSU==<br />
<br />
<gallery><br />
Image:Oem type psu.jpg<br />
</gallery><br />
<br />
These are designed to be wired into custom installations. They have exposed mains connections which should be enclosed to prevent access. It is recommended to get closed frame types, but these still have exposed mains connections.<br />
<br />
They come in several versions, 12V or 24V and up to 400W.<br />
<br />
The input voltage is usually universal, switchable between 110V and 220V, or sometimes fixed 110V or 220V. Check that it is compatible with your mains voltage before purchasing.<br />
<br />
Using OEM PSU with Repap : [[RepRapPro_Mendel_power_supply]]<br />
<br />
=Suppliers=<br />
<br />
<br />
{| class="wikitable sortable"<br />
|+ <br />
|-<br />
| Vendors (link to product) || Shipping location || Manufacturer || Model # (link to datasheet) || Input || Output(V/A) || Tested || Additional notes<br />
|-<br />
| [http://www.lulzbot.com/en/electronics/146-12vdc-20a-240w-power-supply.html lulzbot]|| USA<br />
| MW || S-240-12<br />
| 110V or 220V || 12V 20A || {{true}} || <br />
|}<br />
<br />
=See also=<br />
<br />
[[RAMPS_1.4#Wiring]]<br />
<br />
http://en.wikipedia.org/wiki/Power_supply</div>Bobchttps://reprap.org/mediawiki/index.php?title=Power_Supply&diff=93431Power Supply2013-05-26T14:01:09Z<p>Bobc: /* General purpose power bricks */</p>
<hr />
<div>Most Reprap electronics use 12V DC ranging from 5A-20A.<br />
<br />
The motors plus single hotend take up to 5A or so, a heated bed typically takes 5A-15A. So for a standard setup with heated bed, look to about 18-20A total which is about 220-240W at 12V. For some setups you might be able to use less power.<br />
<br />
There are several different options of power supply that can be used and are commonly available.<br />
<br />
==Computer PSUs== <br />
<br />
<gallery><br />
Image:PC_PSU.jpg<br />
Image:Server psu.JPG<br />
</gallery><br />
<br />
===Standard PC===<br />
These provide 12V, 5V and 5V standby.<br />
<br />
A PSU from a standard PC can be used. Some electronics have connectors for direct connection to the PSU Molex connectors, for other electronics the connectors will need to be cut and connection to stripped wires made. Some electronics can use the Power-On signal to wake up the PSU from standby.<br />
<br />
PC power supplies vary a lot in quality, and many can not provide the rated power. A typical PC PSU can usually provide about half its rated voltage on the 12V lines, so it is best to use a power supply rated 400W or above. Otherwise the PSU will struggle to maintain 12V output. PC PSUs should have thermal overload protection, and shut down safely on overload, but again poor quality ones may not do so before overheating.<br />
<br />
To use a PC PSU power supply, it is necessary to jumper the "power on" signal to ground, and often it is needed to supply a load on the 5V rail to get good regulation of the 12V rail.<br />
<br />
See here for more details:<br />
*[[PCPowerSupply]] using a computer power supply<br />
<br />
===Server PSU===<br />
There are also PSUs taken from servers which can be used. These usually provide 12V only, but a LOT of current (32A), and quite cheap.<br />
<br />
They usually have a proprietary connector designed for rack mount systems, so need some custom wiring depending on the model.<br />
<br />
Here are instructions for HP PS-3381-1C1 400W PSUs http://www.rcgroups.com/forums/showthread.php?t=358340<br />
<br />
==Brick type==<br />
<br />
<gallery><br />
Image:Psu-brick.jpg<br />
Image:Psu-xbox360-203w.jpg<br />
</gallery><br />
<br />
===Laptop, console and general purpose Power Bricks===<br />
<br />
These come in a variety of types up to around 240W, for normal use select a 12V 220W version. Also available are 24V versions.<br />
<br />
They often come with a barrel type or 4 pin connector. The 4 pin connector is sometimes called "mini-DIN" or "power DIN", but is not a standard DIN connector. <br />
<br />
Also the pin assignments can vary, but for most boards you will need to cut the connector off or make an adaptor.<br />
<br />
References:<br />
http://en.wikipedia.org/wiki/DC_connector#Snap_and_lock_DC_power_connectors<br />
<br />
===XBOX 360 PSU===<br />
<br />
There are several versions, choose the 203W version. Note that the power may be insufficient for some heated beds. The PSU will shutdown if an overload occurs.<br />
<br />
These provide 12V, 5V and 5V standby and power on input.<br />
<br />
The XBOX power connector can be cut off and connections made to stripped wire, or make an adaptor with an XBOX power socket (sold as spares on eBay etc).<br />
<br />
How to use XBOX 360 PSU with Reprap : http://www.thingiverse.com/thing:13980<br />
<br />
==OEM type PSU==<br />
<br />
<gallery><br />
Image:Oem type psu.jpg<br />
</gallery><br />
<br />
These are designed to be wired into custom installations. They have exposed mains connections which should be enclosed to prevent access. It is recommended to get closed frame types, but these still have exposed mains connections.<br />
<br />
They come in several versions, 12V or 24V and up to 400W.<br />
<br />
The input voltage is usually universal, switchable between 110V and 220V, or sometimes fixed 110V or 220V. Check that it is compatible with your mains voltage before purchasing.<br />
<br />
Using OEM PSU with Repap : [[RepRapPro_Mendel_power_supply]]<br />
<br />
=Suppliers=<br />
<br />
<br />
{| class="wikitable sortable"<br />
|+ <br />
|-<br />
| Vendors (link to product) || Shipping location || Manufacturer || Model # (link to datasheet) || Input || Output(V/A) || Tested || Additional notes<br />
|-<br />
| [http://www.lulzbot.com/en/electronics/146-12vdc-20a-240w-power-supply.html lulzbot]|| USA<br />
| MW || S-240-12<br />
| 110V or 220V || 12V 20A || {{true}} || <br />
|}<br />
<br />
=See also=<br />
<br />
[[RAMPS_1.4#Wiring]]<br />
<br />
http://en.wikipedia.org/wiki/Power_supply</div>Bobchttps://reprap.org/mediawiki/index.php?title=Power_Supply&diff=93430Power Supply2013-05-26T13:55:41Z<p>Bobc: /* See also */</p>
<hr />
<div>Most Reprap electronics use 12V DC ranging from 5A-20A.<br />
<br />
The motors plus single hotend take up to 5A or so, a heated bed typically takes 5A-15A. So for a standard setup with heated bed, look to about 18-20A total which is about 220-240W at 12V. For some setups you might be able to use less power.<br />
<br />
There are several different options of power supply that can be used and are commonly available.<br />
<br />
==Computer PSUs== <br />
<br />
<gallery><br />
Image:PC_PSU.jpg<br />
Image:Server psu.JPG<br />
</gallery><br />
<br />
===Standard PC===<br />
These provide 12V, 5V and 5V standby.<br />
<br />
A PSU from a standard PC can be used. Some electronics have connectors for direct connection to the PSU Molex connectors, for other electronics the connectors will need to be cut and connection to stripped wires made. Some electronics can use the Power-On signal to wake up the PSU from standby.<br />
<br />
PC power supplies vary a lot in quality, and many can not provide the rated power. A typical PC PSU can usually provide about half its rated voltage on the 12V lines, so it is best to use a power supply rated 400W or above. Otherwise the PSU will struggle to maintain 12V output. PC PSUs should have thermal overload protection, and shut down safely on overload, but again poor quality ones may not do so before overheating.<br />
<br />
To use a PC PSU power supply, it is necessary to jumper the "power on" signal to ground, and often it is needed to supply a load on the 5V rail to get good regulation of the 12V rail.<br />
<br />
See here for more details:<br />
*[[PCPowerSupply]] using a computer power supply<br />
<br />
===Server PSU===<br />
There are also PSUs taken from servers which can be used. These usually provide 12V only, but a LOT of current (32A), and quite cheap.<br />
<br />
They usually have a proprietary connector designed for rack mount systems, so need some custom wiring depending on the model.<br />
<br />
Here are instructions for HP PS-3381-1C1 400W PSUs http://www.rcgroups.com/forums/showthread.php?t=358340<br />
<br />
==Brick type==<br />
<br />
<gallery><br />
Image:Psu-brick.jpg<br />
Image:Psu-xbox360-203w.jpg<br />
</gallery><br />
<br />
===General purpose power bricks===<br />
<br />
These come in a variety of types up to around 240W, for normal use select a 12V 220W version. Also available are 24V versions.<br />
<br />
They often come with a barrel type or 4 pin connector. The 4 pin connector is sometimes called "mini-DIN" or "power DIN", but is not a standard DIN connector. <br />
<br />
Also the pin assignments can vary, but for most boards you will need to cut the connector off or make an adaptor.<br />
<br />
References:<br />
http://en.wikipedia.org/wiki/DC_connector#Snap_and_lock_DC_power_connectors<br />
<br />
<br />
===XBOX 360 PSU===<br />
<br />
There are several versions, choose the 203W version. Note that the power may be insufficient for some heated beds. The PSU will shutdown if an overload occurs.<br />
<br />
These provide 12V, 5V and 5V standby and power on input.<br />
<br />
The XBOX power connector can be cut off and connections made to stripped wire, or make an adaptor with an XBOX power socket (sold as spares on eBay etc).<br />
<br />
How to use XBOX 360 PSU with Reprap : http://www.thingiverse.com/thing:13980<br />
<br />
==OEM type PSU==<br />
<br />
<gallery><br />
Image:Oem type psu.jpg<br />
</gallery><br />
<br />
These are designed to be wired into custom installations. They have exposed mains connections which should be enclosed to prevent access. It is recommended to get closed frame types, but these still have exposed mains connections.<br />
<br />
They come in several versions, 12V or 24V and up to 400W.<br />
<br />
The input voltage is usually universal, switchable between 110V and 220V, or sometimes fixed 110V or 220V. Check that it is compatible with your mains voltage before purchasing.<br />
<br />
Using OEM PSU with Repap : [[RepRapPro_Mendel_power_supply]]<br />
<br />
=Suppliers=<br />
<br />
<br />
{| class="wikitable sortable"<br />
|+ <br />
|-<br />
| Vendors (link to product) || Shipping location || Manufacturer || Model # (link to datasheet) || Input || Output(V/A) || Tested || Additional notes<br />
|-<br />
| [http://www.lulzbot.com/en/electronics/146-12vdc-20a-240w-power-supply.html lulzbot]|| USA<br />
| MW || S-240-12<br />
| 110V or 220V || 12V 20A || {{true}} || <br />
|}<br />
<br />
=See also=<br />
<br />
[[RAMPS_1.4#Wiring]]<br />
<br />
http://en.wikipedia.org/wiki/Power_supply</div>Bobchttps://reprap.org/mediawiki/index.php?title=Power_Supply&diff=93429Power Supply2013-05-26T13:52:44Z<p>Bobc: /* Server PSU */</p>
<hr />
<div>Most Reprap electronics use 12V DC ranging from 5A-20A.<br />
<br />
The motors plus single hotend take up to 5A or so, a heated bed typically takes 5A-15A. So for a standard setup with heated bed, look to about 18-20A total which is about 220-240W at 12V. For some setups you might be able to use less power.<br />
<br />
There are several different options of power supply that can be used and are commonly available.<br />
<br />
==Computer PSUs== <br />
<br />
<gallery><br />
Image:PC_PSU.jpg<br />
Image:Server psu.JPG<br />
</gallery><br />
<br />
===Standard PC===<br />
These provide 12V, 5V and 5V standby.<br />
<br />
A PSU from a standard PC can be used. Some electronics have connectors for direct connection to the PSU Molex connectors, for other electronics the connectors will need to be cut and connection to stripped wires made. Some electronics can use the Power-On signal to wake up the PSU from standby.<br />
<br />
PC power supplies vary a lot in quality, and many can not provide the rated power. A typical PC PSU can usually provide about half its rated voltage on the 12V lines, so it is best to use a power supply rated 400W or above. Otherwise the PSU will struggle to maintain 12V output. PC PSUs should have thermal overload protection, and shut down safely on overload, but again poor quality ones may not do so before overheating.<br />
<br />
To use a PC PSU power supply, it is necessary to jumper the "power on" signal to ground, and often it is needed to supply a load on the 5V rail to get good regulation of the 12V rail.<br />
<br />
See here for more details:<br />
*[[PCPowerSupply]] using a computer power supply<br />
<br />
===Server PSU===<br />
There are also PSUs taken from servers which can be used. These usually provide 12V only, but a LOT of current (32A), and quite cheap.<br />
<br />
They usually have a proprietary connector designed for rack mount systems, so need some custom wiring depending on the model.<br />
<br />
Here are instructions for HP PS-3381-1C1 400W PSUs http://www.rcgroups.com/forums/showthread.php?t=358340<br />
<br />
==Brick type==<br />
<br />
<gallery><br />
Image:Psu-brick.jpg<br />
Image:Psu-xbox360-203w.jpg<br />
</gallery><br />
<br />
===General purpose power bricks===<br />
<br />
These come in a variety of types up to around 240W, for normal use select a 12V 220W version. Also available are 24V versions.<br />
<br />
They often come with a barrel type or 4 pin connector. The 4 pin connector is sometimes called "mini-DIN" or "power DIN", but is not a standard DIN connector. <br />
<br />
Also the pin assignments can vary, but for most boards you will need to cut the connector off or make an adaptor.<br />
<br />
References:<br />
http://en.wikipedia.org/wiki/DC_connector#Snap_and_lock_DC_power_connectors<br />
<br />
<br />
===XBOX 360 PSU===<br />
<br />
There are several versions, choose the 203W version. Note that the power may be insufficient for some heated beds. The PSU will shutdown if an overload occurs.<br />
<br />
These provide 12V, 5V and 5V standby and power on input.<br />
<br />
The XBOX power connector can be cut off and connections made to stripped wire, or make an adaptor with an XBOX power socket (sold as spares on eBay etc).<br />
<br />
How to use XBOX 360 PSU with Reprap : http://www.thingiverse.com/thing:13980<br />
<br />
==OEM type PSU==<br />
<br />
<gallery><br />
Image:Oem type psu.jpg<br />
</gallery><br />
<br />
These are designed to be wired into custom installations. They have exposed mains connections which should be enclosed to prevent access. It is recommended to get closed frame types, but these still have exposed mains connections.<br />
<br />
They come in several versions, 12V or 24V and up to 400W.<br />
<br />
The input voltage is usually universal, switchable between 110V and 220V, or sometimes fixed 110V or 220V. Check that it is compatible with your mains voltage before purchasing.<br />
<br />
Using OEM PSU with Repap : [[RepRapPro_Mendel_power_supply]]<br />
<br />
=Suppliers=<br />
<br />
<br />
{| class="wikitable sortable"<br />
|+ <br />
|-<br />
| Vendors (link to product) || Shipping location || Manufacturer || Model # (link to datasheet) || Input || Output(V/A) || Tested || Additional notes<br />
|-<br />
| [http://www.lulzbot.com/en/electronics/146-12vdc-20a-240w-power-supply.html lulzbot]|| USA<br />
| MW || S-240-12<br />
| 110V or 220V || 12V 20A || {{true}} || <br />
|}<br />
<br />
=See also=<br />
<br />
http://en.wikipedia.org/wiki/Power_supply</div>Bobchttps://reprap.org/mediawiki/index.php?title=Power_Supply&diff=93428Power Supply2013-05-26T13:43:27Z<p>Bobc: /* OEM type PSU */</p>
<hr />
<div>Most Reprap electronics use 12V DC ranging from 5A-20A.<br />
<br />
The motors plus single hotend take up to 5A or so, a heated bed typically takes 5A-15A. So for a standard setup with heated bed, look to about 18-20A total which is about 220-240W at 12V. For some setups you might be able to use less power.<br />
<br />
There are several different options of power supply that can be used and are commonly available.<br />
<br />
==Computer PSUs== <br />
<br />
<gallery><br />
Image:PC_PSU.jpg<br />
Image:Server psu.JPG<br />
</gallery><br />
<br />
===Standard PC===<br />
These provide 12V, 5V and 5V standby.<br />
<br />
A PSU from a standard PC can be used. Some electronics have connectors for direct connection to the PSU Molex connectors, for other electronics the connectors will need to be cut and connection to stripped wires made. Some electronics can use the Power-On signal to wake up the PSU from standby.<br />
<br />
PC power supplies vary a lot in quality, and many can not provide the rated power. A typical PC PSU can usually provide about half its rated voltage on the 12V lines, so it is best to use a power supply rated 400W or above. Otherwise the PSU will struggle to maintain 12V output. PC PSUs should have thermal overload protection, and shut down safely on overload, but again poor quality ones may not do so before overheating.<br />
<br />
To use a PC PSU power supply, it is necessary to jumper the "power on" signal to ground, and often it is needed to supply a load on the 5V rail to get good regulation of the 12V rail.<br />
<br />
See here for more details:<br />
*[[PCPowerSupply]] using a computer power supply<br />
<br />
===Server PSU===<br />
There are also PSUs taken from servers which can be used. These usually provide 12V only.<br />
<br />
TODO: wiring<br />
<br />
==Brick type==<br />
<br />
<gallery><br />
Image:Psu-brick.jpg<br />
Image:Psu-xbox360-203w.jpg<br />
</gallery><br />
<br />
===General purpose power bricks===<br />
<br />
These come in a variety of types up to around 240W, for normal use select a 12V 220W version. Also available are 24V versions.<br />
<br />
They often come with a barrel type or 4 pin connector. The 4 pin connector is sometimes called "mini-DIN" or "power DIN", but is not a standard DIN connector. <br />
<br />
Also the pin assignments can vary, but for most boards you will need to cut the connector off or make an adaptor.<br />
<br />
References:<br />
http://en.wikipedia.org/wiki/DC_connector#Snap_and_lock_DC_power_connectors<br />
<br />
<br />
===XBOX 360 PSU===<br />
<br />
There are several versions, choose the 203W version. Note that the power may be insufficient for some heated beds. The PSU will shutdown if an overload occurs.<br />
<br />
These provide 12V, 5V and 5V standby and power on input.<br />
<br />
The XBOX power connector can be cut off and connections made to stripped wire, or make an adaptor with an XBOX power socket (sold as spares on eBay etc).<br />
<br />
How to use XBOX 360 PSU with Reprap : http://www.thingiverse.com/thing:13980<br />
<br />
==OEM type PSU==<br />
<br />
<gallery><br />
Image:Oem type psu.jpg<br />
</gallery><br />
<br />
These are designed to be wired into custom installations. They have exposed mains connections which should be enclosed to prevent access. It is recommended to get closed frame types, but these still have exposed mains connections.<br />
<br />
They come in several versions, 12V or 24V and up to 400W.<br />
<br />
The input voltage is usually universal, switchable between 110V and 220V, or sometimes fixed 110V or 220V. Check that it is compatible with your mains voltage before purchasing.<br />
<br />
Using OEM PSU with Repap : [[RepRapPro_Mendel_power_supply]]<br />
<br />
=Suppliers=<br />
<br />
<br />
{| class="wikitable sortable"<br />
|+ <br />
|-<br />
| Vendors (link to product) || Shipping location || Manufacturer || Model # (link to datasheet) || Input || Output(V/A) || Tested || Additional notes<br />
|-<br />
| [http://www.lulzbot.com/en/electronics/146-12vdc-20a-240w-power-supply.html lulzbot]|| USA<br />
| MW || S-240-12<br />
| 110V or 220V || 12V 20A || {{true}} || <br />
|}<br />
<br />
=See also=<br />
<br />
http://en.wikipedia.org/wiki/Power_supply</div>Bobchttps://reprap.org/mediawiki/index.php?title=Power_Supply&diff=93427Power Supply2013-05-26T13:42:47Z<p>Bobc: /* XBOX 360 PSU */</p>
<hr />
<div>Most Reprap electronics use 12V DC ranging from 5A-20A.<br />
<br />
The motors plus single hotend take up to 5A or so, a heated bed typically takes 5A-15A. So for a standard setup with heated bed, look to about 18-20A total which is about 220-240W at 12V. For some setups you might be able to use less power.<br />
<br />
There are several different options of power supply that can be used and are commonly available.<br />
<br />
==Computer PSUs== <br />
<br />
<gallery><br />
Image:PC_PSU.jpg<br />
Image:Server psu.JPG<br />
</gallery><br />
<br />
===Standard PC===<br />
These provide 12V, 5V and 5V standby.<br />
<br />
A PSU from a standard PC can be used. Some electronics have connectors for direct connection to the PSU Molex connectors, for other electronics the connectors will need to be cut and connection to stripped wires made. Some electronics can use the Power-On signal to wake up the PSU from standby.<br />
<br />
PC power supplies vary a lot in quality, and many can not provide the rated power. A typical PC PSU can usually provide about half its rated voltage on the 12V lines, so it is best to use a power supply rated 400W or above. Otherwise the PSU will struggle to maintain 12V output. PC PSUs should have thermal overload protection, and shut down safely on overload, but again poor quality ones may not do so before overheating.<br />
<br />
To use a PC PSU power supply, it is necessary to jumper the "power on" signal to ground, and often it is needed to supply a load on the 5V rail to get good regulation of the 12V rail.<br />
<br />
See here for more details:<br />
*[[PCPowerSupply]] using a computer power supply<br />
<br />
===Server PSU===<br />
There are also PSUs taken from servers which can be used. These usually provide 12V only.<br />
<br />
TODO: wiring<br />
<br />
==Brick type==<br />
<br />
<gallery><br />
Image:Psu-brick.jpg<br />
Image:Psu-xbox360-203w.jpg<br />
</gallery><br />
<br />
===General purpose power bricks===<br />
<br />
These come in a variety of types up to around 240W, for normal use select a 12V 220W version. Also available are 24V versions.<br />
<br />
They often come with a barrel type or 4 pin connector. The 4 pin connector is sometimes called "mini-DIN" or "power DIN", but is not a standard DIN connector. <br />
<br />
Also the pin assignments can vary, but for most boards you will need to cut the connector off or make an adaptor.<br />
<br />
References:<br />
http://en.wikipedia.org/wiki/DC_connector#Snap_and_lock_DC_power_connectors<br />
<br />
<br />
===XBOX 360 PSU===<br />
<br />
There are several versions, choose the 203W version. Note that the power may be insufficient for some heated beds. The PSU will shutdown if an overload occurs.<br />
<br />
These provide 12V, 5V and 5V standby and power on input.<br />
<br />
The XBOX power connector can be cut off and connections made to stripped wire, or make an adaptor with an XBOX power socket (sold as spares on eBay etc).<br />
<br />
How to use XBOX 360 PSU with Reprap : http://www.thingiverse.com/thing:13980<br />
<br />
==OEM type PSU==<br />
<br />
<gallery><br />
Image:Oem type psu.jpg<br />
</gallery><br />
<br />
These are designed to be wired into custom installations. They have exposed mains connections which should be enclosed to prevent access. It is recommended to get closed frame types, but these still have exposed mains connections.<br />
<br />
They come in several versions, 12V or 24V and up to 400W.<br />
<br />
The input voltage is usually universal, switchable between 110V and 220V, or sometimes fixed 110V or 220V. Check that it is compatible with your mains voltage before purchasing.<br />
<br />
<br />
[[RepRapPro_Mendel_power_supply]]<br />
<br />
=Suppliers=<br />
<br />
<br />
{| class="wikitable sortable"<br />
|+ <br />
|-<br />
| Vendors (link to product) || Shipping location || Manufacturer || Model # (link to datasheet) || Input || Output(V/A) || Tested || Additional notes<br />
|-<br />
| [http://www.lulzbot.com/en/electronics/146-12vdc-20a-240w-power-supply.html lulzbot]|| USA<br />
| MW || S-240-12<br />
| 110V or 220V || 12V 20A || {{true}} || <br />
|}<br />
<br />
=See also=<br />
<br />
http://en.wikipedia.org/wiki/Power_supply</div>Bobchttps://reprap.org/mediawiki/index.php?title=Power_Supply&diff=93426Power Supply2013-05-26T13:41:46Z<p>Bobc: /* Standard PC */</p>
<hr />
<div>Most Reprap electronics use 12V DC ranging from 5A-20A.<br />
<br />
The motors plus single hotend take up to 5A or so, a heated bed typically takes 5A-15A. So for a standard setup with heated bed, look to about 18-20A total which is about 220-240W at 12V. For some setups you might be able to use less power.<br />
<br />
There are several different options of power supply that can be used and are commonly available.<br />
<br />
==Computer PSUs== <br />
<br />
<gallery><br />
Image:PC_PSU.jpg<br />
Image:Server psu.JPG<br />
</gallery><br />
<br />
===Standard PC===<br />
These provide 12V, 5V and 5V standby.<br />
<br />
A PSU from a standard PC can be used. Some electronics have connectors for direct connection to the PSU Molex connectors, for other electronics the connectors will need to be cut and connection to stripped wires made. Some electronics can use the Power-On signal to wake up the PSU from standby.<br />
<br />
PC power supplies vary a lot in quality, and many can not provide the rated power. A typical PC PSU can usually provide about half its rated voltage on the 12V lines, so it is best to use a power supply rated 400W or above. Otherwise the PSU will struggle to maintain 12V output. PC PSUs should have thermal overload protection, and shut down safely on overload, but again poor quality ones may not do so before overheating.<br />
<br />
To use a PC PSU power supply, it is necessary to jumper the "power on" signal to ground, and often it is needed to supply a load on the 5V rail to get good regulation of the 12V rail.<br />
<br />
See here for more details:<br />
*[[PCPowerSupply]] using a computer power supply<br />
<br />
===Server PSU===<br />
There are also PSUs taken from servers which can be used. These usually provide 12V only.<br />
<br />
TODO: wiring<br />
<br />
==Brick type==<br />
<br />
<gallery><br />
Image:Psu-brick.jpg<br />
Image:Psu-xbox360-203w.jpg<br />
</gallery><br />
<br />
===General purpose power bricks===<br />
<br />
These come in a variety of types up to around 240W, for normal use select a 12V 220W version. Also available are 24V versions.<br />
<br />
They often come with a barrel type or 4 pin connector. The 4 pin connector is sometimes called "mini-DIN" or "power DIN", but is not a standard DIN connector. <br />
<br />
Also the pin assignments can vary, but for most boards you will need to cut the connector off or make an adaptor.<br />
<br />
References:<br />
http://en.wikipedia.org/wiki/DC_connector#Snap_and_lock_DC_power_connectors<br />
<br />
<br />
===XBOX 360 PSU===<br />
<br />
There are several versions, choose the 203W version. Note that the power may be insufficient for some heated beds. The PSU will shutdown if an overload occurs.<br />
<br />
These provide 12V, 5V and 5V standby and power on input.<br />
<br />
The XBOX power connector can be cut off and connections made to stripped wire, or make an adaptor with an XBOX power socket (sold as spares on eBay etc).<br />
<br />
http://www.thingiverse.com/thing:13980<br />
<br />
==OEM type PSU==<br />
<br />
<gallery><br />
Image:Oem type psu.jpg<br />
</gallery><br />
<br />
These are designed to be wired into custom installations. They have exposed mains connections which should be enclosed to prevent access. It is recommended to get closed frame types, but these still have exposed mains connections.<br />
<br />
They come in several versions, 12V or 24V and up to 400W.<br />
<br />
The input voltage is usually universal, switchable between 110V and 220V, or sometimes fixed 110V or 220V. Check that it is compatible with your mains voltage before purchasing.<br />
<br />
<br />
[[RepRapPro_Mendel_power_supply]]<br />
<br />
=Suppliers=<br />
<br />
<br />
{| class="wikitable sortable"<br />
|+ <br />
|-<br />
| Vendors (link to product) || Shipping location || Manufacturer || Model # (link to datasheet) || Input || Output(V/A) || Tested || Additional notes<br />
|-<br />
| [http://www.lulzbot.com/en/electronics/146-12vdc-20a-240w-power-supply.html lulzbot]|| USA<br />
| MW || S-240-12<br />
| 110V or 220V || 12V 20A || {{true}} || <br />
|}<br />
<br />
=See also=<br />
<br />
http://en.wikipedia.org/wiki/Power_supply</div>Bobchttps://reprap.org/mediawiki/index.php?title=Power_Supply&diff=93425Power Supply2013-05-26T13:35:38Z<p>Bobc: </p>
<hr />
<div>Most Reprap electronics use 12V DC ranging from 5A-20A.<br />
<br />
The motors plus single hotend take up to 5A or so, a heated bed typically takes 5A-15A. So for a standard setup with heated bed, look to about 18-20A total which is about 220-240W at 12V. For some setups you might be able to use less power.<br />
<br />
There are several different options of power supply that can be used and are commonly available.<br />
<br />
==Computer PSUs== <br />
<br />
<gallery><br />
Image:PC_PSU.jpg<br />
Image:Server psu.JPG<br />
</gallery><br />
<br />
===Standard PC===<br />
These provide 12V, 5V and 5V standby.<br />
<br />
A PSU from a standard PC can be used. Some electronics have connectors for direct connection to the PSU Molex connectors, for other electronics the connectors will need to be cut and connection to stripped wires made. Some electronics can use the Power-On signal to wake up the PSU from standby.<br />
<br />
*[[PCPowerSupply]] using a computer power supply<br />
<br />
===Server PSU===<br />
There are also PSUs taken from servers which can be used. These usually provide 12V only.<br />
<br />
TODO: wiring<br />
<br />
==Brick type==<br />
<br />
<gallery><br />
Image:Psu-brick.jpg<br />
Image:Psu-xbox360-203w.jpg<br />
</gallery><br />
<br />
===General purpose power bricks===<br />
<br />
These come in a variety of types up to around 240W, for normal use select a 12V 220W version. Also available are 24V versions.<br />
<br />
They often come with a barrel type or 4 pin connector. The 4 pin connector is sometimes called "mini-DIN" or "power DIN", but is not a standard DIN connector. <br />
<br />
Also the pin assignments can vary, but for most boards you will need to cut the connector off or make an adaptor.<br />
<br />
References:<br />
http://en.wikipedia.org/wiki/DC_connector#Snap_and_lock_DC_power_connectors<br />
<br />
<br />
===XBOX 360 PSU===<br />
<br />
There are several versions, choose the 203W version. Note that the power may be insufficient for some heated beds. The PSU will shutdown if an overload occurs.<br />
<br />
These provide 12V, 5V and 5V standby and power on input.<br />
<br />
The XBOX power connector can be cut off and connections made to stripped wire, or make an adaptor with an XBOX power socket (sold as spares on eBay etc).<br />
<br />
http://www.thingiverse.com/thing:13980<br />
<br />
==OEM type PSU==<br />
<br />
<gallery><br />
Image:Oem type psu.jpg<br />
</gallery><br />
<br />
These are designed to be wired into custom installations. They have exposed mains connections which should be enclosed to prevent access. It is recommended to get closed frame types, but these still have exposed mains connections.<br />
<br />
They come in several versions, 12V or 24V and up to 400W.<br />
<br />
The input voltage is usually universal, switchable between 110V and 220V, or sometimes fixed 110V or 220V. Check that it is compatible with your mains voltage before purchasing.<br />
<br />
<br />
[[RepRapPro_Mendel_power_supply]]<br />
<br />
=Suppliers=<br />
<br />
<br />
{| class="wikitable sortable"<br />
|+ <br />
|-<br />
| Vendors (link to product) || Shipping location || Manufacturer || Model # (link to datasheet) || Input || Output(V/A) || Tested || Additional notes<br />
|-<br />
| [http://www.lulzbot.com/en/electronics/146-12vdc-20a-240w-power-supply.html lulzbot]|| USA<br />
| MW || S-240-12<br />
| 110V or 220V || 12V 20A || {{true}} || <br />
|}<br />
<br />
=See also=<br />
<br />
http://en.wikipedia.org/wiki/Power_supply</div>Bobchttps://reprap.org/mediawiki/index.php?title=Power_Supply&diff=93420Power Supply2013-05-26T13:11:34Z<p>Bobc: </p>
<hr />
<div>Most Reprap electronics use 12V DC ranging from 5A-20A.<br />
<br />
The motors plus single hotend take up to 5A or so, a heated bed typically takes 5A-15A. So for a standard setup with heated bed, look to about 17A total which is about 200W at 12V.<br />
<br />
There are several different options of power supply that can be used and are commonly available.<br />
<br />
==Computer PSUs== <br />
<br />
<gallery><br />
Image:PC_PSU.jpg<br />
Image:Server psu.JPG<br />
</gallery><br />
<br />
===Standard PC===<br />
A PSU from a standard PC can be used. Some electronics have connectors for direct connection to the PSU Molex connectors, for other electronics the connectors will need to be cut and connection to stripped wires made. Some electronics can use the Power-On signal to wake up the PSU from standby.<br />
<br />
*[[PCPowerSupply]] using a computer power supply<br />
<br />
===Server PSU===<br />
There are also PSUs taken from servers which can be used.<br />
<br />
TODO: wiring<br />
<br />
==Brick type==<br />
<br />
<gallery><br />
Image:Psu-brick.jpg<br />
Image:Psu-xbox360-203w.jpg<br />
</gallery><br />
<br />
===General purpose power bricks===<br />
<br />
These come in a variety of types, for normal use select a 12V 200W version.<br />
<br />
http://www.thingiverse.com/thing:13980<br />
<br />
===XBOX 360 PSU===<br />
<br />
The 203W version makes a good choice. The Xbox connector can be cut off and connections made to stripped wire.<br />
<br />
TODO: wiring<br />
<br />
==OEM type PSU==<br />
<br />
<gallery><br />
Image:Oem type psu.jpg<br />
</gallery><br />
<br />
These are designed to be wired into custom installations. They have exposed mains connections which should be enclosed to prevent access. It is recommended to get closed frame types, but these still have exposed mains connections.<br />
<br />
They come in a variety of output voltages and power ratings.<br />
<br />
The input voltage is usually switchable between 110V and 220V, check that it is compatible with your mains voltage before purchasing.<br />
<br />
<br />
[[RepRapPro_Mendel_power_supply]]<br />
<br />
=Suppliers=<br />
<br />
<br />
{| class="wikitable sortable"<br />
|+ <br />
|-<br />
| Vendors (link to product) || Shipping location || Manufacturer || Model # (link to datasheet) || Input || Output(V/A) || Tested || Additional notes<br />
|-<br />
| [http://www.lulzbot.com/en/electronics/146-12vdc-20a-240w-power-supply.html lulzbot]|| USA<br />
| MW || S-240-12<br />
| 110V or 220V || 12V 20A || {{true}} || <br />
|}<br />
<br />
=See also=<br />
<br />
http://en.wikipedia.org/wiki/Power_supply</div>Bobchttps://reprap.org/mediawiki/index.php?title=File:Psu-xbox360-203w.jpg&diff=93418File:Psu-xbox360-203w.jpg2013-05-26T12:58:36Z<p>Bobc: XBOX 360 203W PSU</p>
<hr />
<div>XBOX 360 203W PSU</div>Bobc