Marlin configuration auto generator?

Hi all, I havent been using my printer for a while and am now trying to beck into it. I recently purchased an old i3 of off CraigsList and I wanted to flash the RAPMS with the Marlin firmware. I could have sworn that about a year ago, I remember seeing somewhere that there is a tool out there that would allow you to basically auto generate the "config.h" section of Marlin for you, based on the input you provide? So, for example, you could select the type of board you're using, thermistor, etc and auto generate the config.h. Is this something that's already out and available out there, or am I just dreaming and perhaps a bit dillusional? =) I don;t mind going through the manual way, but if there's already a tool out there, I would rather use that. Thanks.

Romel

I've been working on a "configurator" as part of the official Marlin project. I got pretty far, but it needs a lot of work to handle the updated configuration files. There are a couple of configurators online that can produce configurations for older versions of Marlin.

• [marlinkimbra.it]
• [marlinbuilder.robotfuzz.com]

Meanwhile, you can try using your old configuration files (Configuration.h and Configuration_adv.h) with the latest Marlin, then when you try to compile it should stop and warn you about any settings that no longer apply. If you can compare your custom configuration files to the default configuration files (from the same point in time that yours were edited), then you should be able to start with the newest default configuration files and make the equivalent changes. If you get stuck, feel free to ask for assistance here, or in the Marlin issue queue on Github.

Hey thanks for the reply Thinkyhead. That is so funny! I was just asking from another thread if a "configurator" is something that is worth investigating further and perhaps improving. I saw that in the link provided by madmike in the other thread I mentioned (http://www.marlinfirmware.org/configurator/), there seem be some issues when I try to used this site to generate the config.h file. You can read the response I mentioned here:

[forums.reprap.org]

So what are you having issues with if you don't mind me asking? I am by no means a programmer for embedded systems or anything like that, but I have done website programming and as well as desktop (a little bit). I am primarily on the .NET stack and would love to help out, but I don't think my skills would be applicable to your situation?

Romel

IMO having to edit the firmware source, re-build it and re-flash it every time you want to change the configuration is ridiculous. Modern electronics/firmware combinations use a configuration file on the SD card instead. Marlin is showing its age.

Edited 1 time(s). Last edit at 07/24/2015 06:49PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I can agree to that, but correct me if I am wrong, but isn't Marlin still "the primary choice" of firmware available for RepRap machines out there? What are the other ones? lol... =) Please excuse my lack of knowledge in this area... I did use Sprinter in the past, so I know that's one.

Romel

Quote
dc42
IMO having to edit the firmware source, re-build it and re-flash it every time you want to change the configuration is ridiculous. Modern electronics/firmware combinations use a configuration file on the SD card instead. Marlin is showing its age.

Pssst, don´t tell him the right way.
You´ll loose one off the few advantages of the duet-concept...
-Olaf

@romels,
for arduino Mega / Ramps combos the marlin firmware still is No1 choice.
-Olaf

Quote
dc42
IMO having to edit the firmware source, re-build it and re-flash it every time you want to change the configuration is ridiculous. Modern electronics/firmware combinations use a configuration file on the SD card instead. Marlin is showing its age.

In theory, you are actually 100% correct. It is indeed a waste of time to have to recompile a firmware and re-flash it, just to change some configuration parameter.

In practice though, this entire recompile/flash cycle takes at most 5 minutes, and it forces you to understand what you are doing. The default Configuration.h file in Marlin is practically a template for the Prusa i3, and the parameters that need to be changed are well documented. Imho this is a small part of the rather tall learning curve when assembling a RepRap and making it print quality objects.

Quote
Olaf
for arduino Mega / Ramps combos the marlin firmware still is No1 choice.

There is also Repetier firmware, which is Open Source and works very well too. And it has an online configuration tool.

Yeah, and it's not like editing a config file and uploading it is much different . . . yeah, no compile, but for me, that's 30 seconds to a minute at best . . . Seems like a solution in search of a problem . . . once the config is set, no need for any of it anyhow . . .

And I like Marlin for it's leanness as an embedded controller. In my mind, web interfaces and all that secondary crap has no place in an embeddded controller - just more to go wrong or screw up a print. I don't want to sound like a broken record, but modularity is golden for flexibility, maintainability, and upgradeability as long as interfaces are standardized, and gcode does that well.

32 bit processor, separate interface card, separate stepper drivers, something like Octoprint and a Pi for interface . . . stay best of breed, and no proprietary low volume components to drive cost up or present a single point of failure. A bit harder to integrate, but my goal, at least, isn't to constantly strive to dumb thing down, but to help to help give folks a stronger skill set . . . we as a species don't need tp get any dumber! And should I hate the UI, I am not either locked in, or forced to change everything . . . just alter the components/software driving the function in question.

- Tim

Edited 1 time(s). Last edit at 07/25/2015 01:06PM by tadawson.

Tim, we will have to disagree. Marlin isn't lean, it's bloated with every feature anyone ever wanted to add. If you want lean firmware, maybe you should try Teacup. Gcode is OK for controlling a printer, but is not an adequate interface for getting status information from it. Stepper drivers integrated in the controller electronics can be cooled much better - the PCB area of a stepstick-type driver is way too small to provide adequate cooling for the chip, hence they can't get close to their rated current and are more prone to overheating. Adding another electronics board to provide a web interface adds unnecessary complexity and cost when modern low-cost microcontrollers are more than capable of serving web pages. IMO every printer should have a web interface, even low-cost printer kits (a view that RepRapPro evidently agrees with - even their low-cost Fisher kit provides one) - it makes managing the printer so much easier, and avoids tying it to a PC.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Marlin *IS* lean in the sense it doesnt have bloat from useless UI code . . . and the rest is largely conditional at compile time, so what's in the codebase vs. what hits the flash is only loosely related at best.

Cooling is a BS argument since either could be made to work fine. Put the chip on the bottom of the stepper module, and a copper plan, heatsink on the back and done . . . pin for pin compatible, and not crippled with non serviceability.

And while an external processor for UI is more complex (well, if you consider a USB cable complex. . it*IS* more parts, though . . .), it's hardly more expensive. Start at about $55 for the whole think vs. more like $100 for the 'single point of failure' solutions . . .

It's just a sign of the times that the younger generation has been fooled into thinking that total replacement is preferable to repair, and the elctronics companies are laughing all the way to the bank . . . sad, very sad . .

- Tim

Quote
tadawson
Marlin *IS* lean in the sense it doesnt have bloat from useless UI code

Repraps have moved from being strictly for techies, to being on the verge of becoming consumer electronics. Any consumer electronics engineer will tell you that the UI is one of the the most important parts of the product.

Quote
tadawson
Cooling is a BS argument since either could be made to work fine. Put the chip on the bottom of the stepper module, and a copper plan, heatsink on the back and done . . . pin for pin compatible, and not crippled with non serviceability.

Yes it could be done, but only a very few very expensive driver modules do it. So not a BS argument.

Quote
tadawson
And while an external processor for UI is more complex (well, if you consider a USB cable complex. . it*IS* more parts, though . . .), it's hardly more expensive. Start at about $55 for the whole think vs. more like $100 for the 'single point of failure' solutions . . .

Your mention of single point of failure is BS, because we're not talking about life critical systems here. As for cost, a Duet from Replikeo is less then $60, not the $100 you quote. To meet your $55 price including the Rpi, the Arduino/RAMPS/stepstick would have to be a cheap Chinese slone with 2-layer stepstick boards, probably an inadequate heated bed mosfet, and poor quality power connector. Also you have to put up with the 5V regulator on the Arduino being prone to overheating if you add an LCD display, no digital stepper motor current control, and no flow control on the USB port. I'll gladly pay $5 extra to avoid those limitations and design flaws.

Quote
tadawson
It's just a sign of the times that the younger generation has been fooled into thinking that total replacement is preferable to repair, and the elctronics companies are laughing all the way to the bank . . . sad, very sad . .

Better a system that rarely needs repairing or replacing than a fragile one (i.e. cheap Arduino/RAMPS/stepstick clone) that is more prone to failure.

IMO most of the RepRap community and most of the kit manufacturers have got stuck in a rut as far as electronics is concerned. The cost of building an Arduino/RAMPS/stepstick package is a lot higher than building a 32-bit all-in-one controller board in the same quantity would be. It is only the production volume coupled with the quality shortcuts taken by some of the clone manufacturers that keeps the price of the Arduino/RAMPS combo so low. But things are changing, with the arrival of low-cost Smoothieboard derivatives and a second source for the Duet.

Marlin and RAMPS have served the community well for a number of years. But the market is changing and technology has advanced, so it really is time the community moved on to something better. I guess the problem is that the community can't decide what to standardise on.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

The problem I see with Marlin configuration is that there is basically a single massive configuration file that has settings for every type of board that is supported. When you're looking at the file, you have to take into account what your motherboard type is and if you are in that section of the file. With all of the nesting and conditional complications, it can be difficult to see if a particular setting applies to your printer.

Yes I realize there are two configuration files, but that hardly addresses the issue.

I recently wrote the configuration utility for teacup firmware. While doing so, I came to greatly appreciate the decision by the teacup developers to have a separate configuration file for each type of board. It makes perfect sense; the files themselves are very straight forward and there are no questions about what is included in your build. Actually in the course of developing the config tool, we took the next step of breaking the configuration file into two - one for the board characteristics, and one for the printer characteristics. I think the marlin team would be wise to follow a similar path.

Quote
dc42
IMO having to edit the firmware source, re-build it and re-flash it every time you want to change the configuration is ridiculous.

... unless this re-flashing is a one-click operation, which it is with Teacup Configtool. It's a simple write to flash, after all, no more, no less. No need to fiddle with files, no need to operate SD cards, just click and be done. Putting compilation in between greatly reduces the complexity of the executed binary, making printing faster and more reliable. May I say it's ridiculous to figure the same configuration over and over again at runtime, on the smallest and slowest CPU participating instead of doing it once on the fastest one available?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug

Quote
dc42
IMO having to edit the firmware source, re-build it and re-flash it every time you want to change the configuration is ridiculous.

... unless this re-flashing is a one-click operation, which it is with Teacup Configtool. It's a simple write to flash, after all, no more, no less. No need to fiddle with files, no need to operate SD cards, just click and be done.

It's certainly nicer if it's a 1-click operation, but I wonder how many combinations of settings you actually test? Conditional compilation features have a nasty habit of interacting with each other. How long does the compile & flash cycle take?

I don't need to fiddle with SD cards either, I just edit the config file and upload it via the web interface. For newbies, a config tool to generate the config file would be advantageous, and I hope somebody writes one for RepRapFirmware.

Quote
Traumflug
Putting compilation in between greatly reduces the complexity of the executed binary, making printing faster and more reliable.

My printers are fast and I find the electronics/firmware combination highly reliable. I have nothing to gain by making the executable binary smaller by removing code that a particular printer configuration doesn't need.

Quote
Traumflug
May I say it's ridiculous to figure the same configuration over and over again at runtime, on the smallest and slowest CPU participating instead of doing it once on the fastest one available?

I disagree. Speaking as someone who maintains firmware, it's much easier for me to maintain a single binary that is configured at startup time.

I am aware that Teacup is designed to run on 8 bit processors with very little RAM - that's your choice. I can see that for you it is better to make heavy use of conditional compilation and compile the minimum code needed to make a binary for a particular printer configuration. But processing power is so cheap now that unlike you, I can't be bothered to write 3D printer firmware for 8-bit processors. I'd rather advance the state of the art using 32-bit ones.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

This is quickly degenerating into an off-topic discussion that we have had dozens of times in the various forums here on reprap.org.

Going back to the original question, Marlin currently does not have a working configuration auto generator, although as pointed out by Thinkyhead (who is currently the main Marlin maintainer, if I understand it correctly), there is an ongoing effort to update an old one, and there are a couple of online ones for previous versions of Marlin.

So indeed, users who may not have a clue about how the firmware works are forced to delve into a somewhat arcane configuration file if they want to compile a current version of Marlin, and that cannot possibly be construed as a Good Thing (tm). In other words, the lack of a configuration generator for Marlin is a shortcoming for sure, but there are solutions in the works.

Also, there are two alternative Open Source, GPL firmwares available with configuration generators:

1. Repetier Firmware.

2. Teacup (thanks to jbernardis).

So it's not like people don't have a choice...


The other issues discussed above (e.g. "leanness" or fat of Marlin, compiling and flashing vs. loading parameters from SD card, 8-bit vs 32-bit, RAMPS stack vs AIO controllers, etc) are all OT, as I am sure most of you will agree.

Quote
dc42
I wonder how many combinations of settings you actually test?

Not relevant regarding upload method, the number of combinations is the same.

Quote
dc42
Conditional compilation features have a nasty habit of interacting with each other.

The same is true when having these conditionals at runtime. Actually, the compiler has quite a number of code plausibility checks up in the sleeve which runtime-configuring firmwares don't have, making configuration combinations safer due to being compiled.

Quote
dc42
How long does the compile & flash cycle take?

1.5 seconds for the compilation, 1.5 seconds for the upload.

Quote
dc42
I am aware that Teacup is designed to run on 8 bit processors with very little RAM

Teacup supports many platforms across several binary formats, including 8, 32 and 64 bit. Writing efficient code simply results in small binaries and there's no point in artifically bloating it. Actually I'm porting right now to yet another 32-bit platform and the required changes are limited to what that platform does different.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
dc42
Marlin and RAMPS have served the community well for a number of years. But the market is changing and technology has advanced, so it really is time the community moved on to something better. I guess the problem is that the community can't decide what to standardise on.

The Market has standardized. The standard is Cheap and Free. RAMPS is cheap, and Marlin is free. As long as they can achieve a good functioning printer, they will stick with it. I can order Ramps/mega/4988x5 combo for ~$25. When 32 bit hits that range, it will be the end of that combo... Unless that combo is $15 by then... Lol...

I'm still waiting on news about your cheap 32 bit board... Hopefully progress is moving forward...

BTW, I just used the Teacup config tool on a Uno build, and it worked great! I didn't time it or anything, but the build/upload time had to be less than 20 secs I guess... I definitely would like to see the same kind of tool for Marlin.

Edited 1 time(s). Last edit at 07/26/2015 12:54PM by madmike8.

Quote
madmike8
I'm still waiting on news about your cheap 32 bit board... Hopefully progress is moving forward...

I stopped work on that for a couple of reasons:

1. My potential volume customers didn't want plug-in driver modules, they wanted the drivers on the board. The reason given by one of them was that they found drivers integrated on boards a lot more reliable, so they had fewer customer returns.

2. So the board ended up looking rather like a Duet, but without the web interface and with dual extruder capability. But Replikeo is now selling the Duet at $59.99. So we now have a low-cost 32-bit board, and unlike my proposed board, it has Ethernet. There is now also the MKS SBASE Smoothieware-compatible board for just a little more. All of which means that a 32-bit board without Ethernet would have to retail for no more than about $45, and I can't meet that price point without high volume production.

I have another board design on the drawing board. It's intended to be a worthy successor to the Duet, with a higher specification (including dual extrusion) but similar or lower build cost. I can't devote a lot of time to it right now; but when I have more time, I may do a Kickstarter campaign to fund the initial production batch.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

As I mentioned earlier... Price is the main concern. Build it however you like... But price will determine how well it sells...

Quote
romels33
I saw that in the link provided by madmike in the other thread I mentioned (http://www.marlinfirmware.org/configurator/), there seem be some issues when I try to used this site to generate the config.h file.

I'm not entirely surprised. The configurator is really out-of-date right now. Over the last few months we've been doing a lot of overhaul of the Configuration files – mainly to make them smaller by moving things out that can live elsewhere.

Quote
romels33
So what are you having issues with if you don't mind me asking?

The only issue at this time is that I need to update the configurator's code (Javascript + jQuery). It needs some additional parsing to deal with conditional blocks that override settings. And it needs to be able to parse and make use of the new files Conditionals.h and SanityCheck.h, and I need to update its parsing of Configuration.h and Configuration_adv.h. The configurator is also not yet updated to handle changes we recently made, replacing #ifdef SOMETHING and #if defined(SOMETHING) with #if ENABLED(SOMETHING).

So basically, I need to put in a good solid week on it and bring it up to date, then start working on some prefabs and reducing the "expert interface" down to the essentials. It will also benefit from having a built-in calculator to get steps-per-mm for each axis. And, it wouldn't be bad going forward to sketch out the design and intention of the utility more, since it can go in many directions.

The configurator is written in Javascript because of its ubiquity, and apart from its run-anywhere and AJAX features, there is extra benefit in that it could be used as a web front-end with an AVR build system behind it.

Edited 1 time(s). Last edit at 07/30/2015 06:11PM by Thinkyhead.

---

|
| Lead Developer of Marlin Firmware
| Help support my work at Patreon and Elsewhere.
|

@Thinkyhead

Sounds good! I am sure when the configuration generator is completed it will be an awesome tool!

Quote
dc42
IMO having to edit the firmware source, re-build it and re-flash it every time you want to change the configuration is ridiculous. Modern electronics/firmware combinations use a configuration file on the SD card instead. Marlin is showing its age.

You don't have to re-flash just to change configurations. You only have to re-flash if you want to add or remove a feature, thus adding or removing code. This is essential to be able to build Marlin for very small boards, while allowing you to build a fully loaded Marlin for a printer with lots of extras and a nice roomy board. (You also need to re-flash in cases where the printer itself is altered, such as moving an endstop to the other end of an axis. Obviously such cases are rare.)

There are several configuration options that you can alter (through GCode or through the LCD menu) and save to EEPROM. Here is the current list of all configurable options (in Marlin 1.1.0 dev):

/**
 * V20 EEPROM Layout:
 *
 *  ver
 *  M92 XYZE  axis_steps_per_unit (x4)
 *  M203 XYZE max_feedrate (x4)
 *  M201 XYZE max_acceleration_units_per_sq_second (x4)
 *  M204 P    acceleration
 *  M204 R    retract_acceleration
 *  M204 T    travel_acceleration
 *  M205 S    minimumfeedrate
 *  M205 T    mintravelfeedrate
 *  M205 B    minsegmenttime
 *  M205 X    max_xy_jerk
 *  M205 Z    max_z_jerk
 *  M205 E    max_e_jerk
 *  M206 XYZ  home_offset (x3)
 *
 * Mesh bed leveling:
 *  M420 S    active
 *            mesh_num_x (set in firmware)
 *            mesh_num_y (set in firmware)
 *  M421 XYZ  z_values[][]
 *  M851      zprobe_zoffset
 *
 * DELTA:
 *  M666 XYZ  endstop_adj (x3)
 *  M665 R    delta_radius
 *  M665 L    delta_diagonal_rod
 *  M665 S    delta_segments_per_second
 *
 * ULTIPANEL:
 *  M145 S0 H plaPreheatHotendTemp
 *  M145 S0 B plaPreheatHPBTemp
 *  M145 S0 F plaPreheatFanSpeed
 *  M145 S1 H absPreheatHotendTemp
 *  M145 S1 B absPreheatHPBTemp
 *  M145 S1 F absPreheatFanSpeed
 *
 * PIDTEMP:
 *  M301 E0 PIDC  Kp[0], Ki[0], Kd[0], Kc[0]
 *  M301 E1 PIDC  Kp[1], Ki[1], Kd[1], Kc[1]
 *  M301 E2 PIDC  Kp[2], Ki[2], Kd[2], Kc[2]
 *  M301 E3 PIDC  Kp[3], Ki[3], Kd[3], Kc[3]
 *
 * PIDTEMPBED:
 *  M304 PID  bedKp, bedKi, bedKd
 *
 * DOGLCD:
 *  M250 C    lcd_contrast
 *
 * SCARA:
 *  M365 XYZ  axis_scaling (x3)
 *
 * FWRETRACT:
 *  M209 S    autoretract_enabled
 *  M207 S    retract_length
 *  M207 W    retract_length_swap
 *  M207 F    retract_feedrate
 *  M207 Z    retract_zlift
 *  M208 S    retract_recover_length
 *  M208 W    retract_recover_length_swap
 *  M208 F    retract_recover_feedrate
 *
 *  M200 D    volumetric_enabled (D>0 makes this enabled)
 *
 *  M200 T D  filament_size (x4) (T0..3)
 *
 * Z_DUAL_ENDSTOPS:
 *  M666 Z    z_endstop_adj
 *
 */

Edited 1 time(s). Last edit at 08/05/2015 09:20PM by Thinkyhead.

---

|
| Lead Developer of Marlin Firmware
| Help support my work at Patreon and Elsewhere.
|

Replikeo has decided on Marlin for its Dual head addition.
I am about to switch to Repetier and drop the dual option. The replikeo deal wasnt a deal but I got a start.

Quote
Thinkyhead

Quote
dc42
IMO having to edit the firmware source, re-build it and re-flash it every time you want to change the configuration is ridiculous. Modern electronics/firmware combinations use a configuration file on the SD card instead. Marlin is showing its age.

You don't have to re-flash just to change configurations. You only have to re-flash if you want to add or remove a feature, thus adding or removing code. This is essential to be able to build Marlin for very small boards, while allowing you to build a fully loaded Marlin for a printer with lots of extras and a nice roomy board. (You also need to re-flash in cases where the printer itself is altered, such as moving an endstop to the other end of an axis. Obviously such cases are rare.)

There are several configuration options that you can alter (through GCode or through the LCD menu) and save to EEPROM. Here is the current list of all configurable options (in Marlin 1.1.0 dev):

/**
 * V20 EEPROM Layout:
 *
 *  ver
 *  M92 XYZE  axis_steps_per_unit (x4)
 *  M203 XYZE max_feedrate (x4)
 *  M201 XYZE max_acceleration_units_per_sq_second (x4)
 *  M204 P    acceleration
 *  M204 R    retract_acceleration
 *  M204 T    travel_acceleration
 *  M205 S    minimumfeedrate
 *  M205 T    mintravelfeedrate
 *  M205 B    minsegmenttime
 *  M205 X    max_xy_jerk
 *  M205 Z    max_z_jerk
 *  M205 E    max_e_jerk
 *  M206 XYZ  home_offset (x3)
 *
 * Mesh bed leveling:
 *  M420 S    active
 *            mesh_num_x (set in firmware)
 *            mesh_num_y (set in firmware)
 *  M421 XYZ  z_values[][]
 *  M851      zprobe_zoffset
 *
 * DELTA:
 *  M666 XYZ  endstop_adj (x3)
 *  M665 R    delta_radius
 *  M665 L    delta_diagonal_rod
 *  M665 S    delta_segments_per_second
 *
 * ULTIPANEL:
 *  M145 S0 H plaPreheatHotendTemp
 *  M145 S0 B plaPreheatHPBTemp
 *  M145 S0 F plaPreheatFanSpeed
 *  M145 S1 H absPreheatHotendTemp
 *  M145 S1 B absPreheatHPBTemp
 *  M145 S1 F absPreheatFanSpeed
 *
 * PIDTEMP:
 *  M301 E0 PIDC  Kp[0], Ki[0], Kd[0], Kc[0]
 *  M301 E1 PIDC  Kp[1], Ki[1], Kd[1], Kc[1]
 *  M301 E2 PIDC  Kp[2], Ki[2], Kd[2], Kc[2]
 *  M301 E3 PIDC  Kp[3], Ki[3], Kd[3], Kc[3]
 *
 * PIDTEMPBED:
 *  M304 PID  bedKp, bedKi, bedKd
 *
 * DOGLCD:
 *  M250 C    lcd_contrast
 *
 * SCARA:
 *  M365 XYZ  axis_scaling (x3)
 *
 * FWRETRACT:
 *  M209 S    autoretract_enabled
 *  M207 S    retract_length
 *  M207 W    retract_length_swap
 *  M207 F    retract_feedrate
 *  M207 Z    retract_zlift
 *  M208 S    retract_recover_length
 *  M208 W    retract_recover_length_swap
 *  M208 F    retract_recover_feedrate
 *
 *  M200 D    volumetric_enabled (D>0 makes this enabled)
 *
 *  M200 T D  filament_size (x4) (T0..3)
 *
 * Z_DUAL_ENDSTOPS:
 *  M666 Z    z_endstop_adj
 *
 */

Thank you very much for that, it helped a lot. Currently re-coding Marlin for the HICTOP Prusa i3 'aluminum frame/budget' printer. Using the Marlin 1.1.0-RC3 source and having good luck and fun with it. 'China' supplied source code would not even compile properly, had multiple syntax errors and other issues =are you kidding me, looked like hacked code. Starting from scratch with the github source. Thanks again, Cheers.

Edited 1 time(s). Last edit at 03/24/2016 10:41AM by GeorgeL16.

Quote
GeorgeL16
Starting from scratch with the github source.

Excellent. Yeah, some manufacturers use very old versions of Marlin which are usually fine, but not the prettiest source code. It's been getting a lot of cleanup and patches, but believe me there's plenty more to go! We're accelerating the release cycle, so I should be releasing 1.1.0-RC5 later tonight, which includes all the patches from RC4 plus some additional fixes for issues that slipped through. Gotta make sure 1.1.0 is the best release ever!