Is there anybody who wants to make a perfect Delta Firmware??

[sr005307]

Hey guys.

As you noticed Marlin FW supports Delta. However Marlin is not a perfect solution for Delta. (Marlin has too much code for other types I think.) so Delta needs more elaborate, easy to use Firmware which doesn't exist on earth yet.

Is there anyone who wants to fork Marlin and make a Delta-Concentrated Firmware??

Furthermore, I'm planning on developing User friendly UI with Electron. It is for simple G-code input and Manual Calibration for first time users.

Join me. Thanks for reading.

[Sebastianv650]

Marlin uses #if #endif statements to control which sections of code gets compiled. So there is no not needed code inside the final .hex.

I would prefer if you would contribute to Marlin and improve what you think can be improved. Splitting the forces especialy on a such special subject is possible not the best way..

[LVD-AC]

It sounds rather temping... maybe there could be a delta_bugfix branch where a stripped down version of the FW is used for delta specific development; as such the efforts do not go to waste and can be incorporated in the general FW as well.

[Sebastianv650]

I'm not owning a delta, so I have to ask: What's special on a delta where you think Marlin is no good solution for deltas?

[LVD-AC]

See e.g. endless discussions like #9226

[sr005307]

Well Thx @Sebastianv650 @LVD-AC

First things first. Delta is highly accurate and fast machine which were used in industries... We can make our Delta 3d printers much better at even industrial state using Marlin FW I think.. (At current stage, still needs improvements.)

Well... Let me explain this simply with 2 criteria; problem and suggestion.

Problems are...

1. There is no fully detailed explanation regarding Delta_calibration. I already read in this github about calibration and on other blogs as well, but they missed several parts each. Merging every variable needed for 1 Delta First Setup 2 Calibration is needed for the RepRap Delta-bot.

Ex) rod lengths, diagonal height, radius... Those must be "accurate". However, there is no basic manuals of these numbers. From which exact point to which point is missing. And what "standard error" should we accept? 0.1mm? 0.01mm? We should make it clear.

Ex) Bike mechanics use standardized methods and tools when day repair their bikes. 3D printers are really similar. We can learn something from those processes.

2. Auto_calibration is still not "Auto" If it were to be Auto, GUI + step by step guideline with conversational interfaces should be done. However, they are not Auto actually... Before we use Auto calibration, we need to set every variables by our own hands... Not by computation of computer itself. I understand in this repository there are many brilliant devs... But think about 3D printer users.... Even elementary students without knowledge about programming may use our FW for their hobbies daily.

3. No fail_safe design. When using Delta, if Motor moves crazy, the head moves out of a safe coordination, out of printable area. Delta has a cylindrical printable area. and sometimes head moves out of it, toward upper, side, or even below directions. Normally delta-bots have no eyes or visual sensors on it.... They use only end_stops.. Yes, it is cheap and comparably accurate even it is cheap...

However... other than Delta,,,, XY system's endstop is enough because there is no other way below endstop..

For Delta, Even 3 motors(xyz) are whitin endstap's range, the head can charge to the ground or one of the pillars.It is really annoying when head crashes again and again. And Marlin devs could and should solve it.

================================================================ Suggestions

1. Dedicated Configuration. h, Configuration_adv. h files for Delta.

Well, Configuration.h is just a set of [if functions with 0 or 1] and [variables]

But it was truly annoying when I wanted to set Delta from standard FW conf file, cuz the order was messy and variables other than Delta were too many....

-Order should be "Delta first" and then others should follow... We can apply this concept for other 3D printer Types... (Ex) CoreXY first and then others...)

2. Improve Delta_Auto and Manual Calibration.

   • define which variables should be checked before calibration
   • define detailed orders regarding Calibration.
   • Our goal here is to calibrate just for making the 1st layer perfect.

3. Make GUI for changing Configuration.h, Configuration_adv.h files. This is basically for novices and kids.

   • I suggest using Electron which is powerful and simple Javascript+HTML app-Maker for multi-platform.

======================================================== I think the true improvements of Marlin FW should be "easy to use" "fully detailed manual".

Until now delta was great easy-to-use for many high-level 3Dp users... Let's make it more public. Let's make it easy to use.

[LVD-AC]

Why do you need a special delta Marlin branch to do that?

[sr005307]

Well They are too busy debugging original codes.

It is just my opinion.

[thinkyhead]

See e.g. endless discussions

That looks like a very interesting one and that it was helping develop understanding. I now might have enough free time and headspace to read it. Although really, I'd rather have more live demos.

---

Einstein once explained his famous Theory in this way:

“Gravitation cannot be held responsible for people falling in love. How on earth can you explain in terms of chemistry and physics so important a biological phenomenon as first love? Put your hand on a stove for a minute and it seems like an hour. Sit with that special girl for an hour and it seems like a minute. That's Relativity."

[LVD-AC]

Marlin uses #if #endif statements to control which sections of code gets compiled. So there is no not needed code inside the final .hex.

This was the case until I think 1.1.6. But now if you disable the typical Cartesian stuff the FW no longer works. E.g. disable the work-space that is only needed to do bed tilt that is related to having a bed on springs that can not be mechanically altered by the FW, or applying skew factors that are only related to having two axis not being exactly 90°. Deltas in principle do not have their bed on springs and do not have axis that move at 90° from each other, so they do not have to deal with those problems.

9226 is yet another step in that direction: if you want baby-stepping you should mandatory enable all the stuff that deals with the problems of having the min-endstops misaligned, even on deltas that do not have min-endstops.

Since 1.1.6 this seems to be the philosophy of all further development in Marlin: whatever typical Cartesian problem that can be found, it should artificially be imposed on all other types of printers as well whiteout having the possibility of disabling that 'feature'; even on printers that did not suffer from such problems to start with, because... well because all printers should be dealt with the Cartesian way, and in order to do this you first have to ensure they all suffer from the same problems and shortcomings.

And as stated before I think 1.1.6 was a bit the turning point in this: before one was able to disable all the unwanted problems by the use of #if #endif statements and setting an environment variable in Configuration.h; but it has been quit a while now this is no longer the case, all the typical Cartesian problems and related solutions have to be mandatory turned on now, without them the FW no longer functions properly.

So a typical delta branch (or even a completely separate FW) becomes more and more a necessity for those delta users who do not which to have bed-spring, perpendicular axis or min end-endstop related problems artificially imposed on them, none of them do physically exist on delta and all this without no longer having the choice to diable them in the FW.

[jemenake]

(As someone who has only started looking at the Marlin code in the last couple of weeks), I think forking it is probably a bad idea. There are too many common functions (driving the LCD, parsing all of the gcodes, etc) for which you don't want to duplicate effort. However, I get sr's point that, at present, delta support seems to be squeezed in here and there. It appears that there could be better encapsulation/separation between the code which wants to place the extruder tip within some virtual printable volume (cube for cartesian printers, cylinder for deltas, etc) and the code which moves physical servos (within their own limits) to make that happen.

For example, when I'm sending gcodes to my delta, Marlin will prevent me from driving the extruder into negative Z territory, and from sending any of the three carriages up past the limit switches, but, if I have the extruder fairly low, and try to move the extruder to the edge of the print-bed, Marlin will happily try to send one of the carriages right into its bottom stop, which causes the stepper to skip, and throws off all positioning until a re-homing is done. So, one of my wishlist items is for Marlin to better manage the positions of the carriages with limits.

I also find it confusing how Configuration.h uses X, Y, and Z to refer to the coordinate space for the extruder, and also for the towers. Perhaps better separation of the delta code (and it's configs) could refer to the towers as A, B, and C. I realize that they're labeled X, Y, and Z on RAMPS boards and such, but it's easier for me to convert X=>A, Y=>B, Z=>C in my head than it is to look at some #define like "MAX_X" and divine whether that's the maximum the x-carriage can travel or the furthest the extruder can go in the lateral x direction.

I can appreciate the appeal of having almost all of the config in Configuration.h, but I think Marlin is outgrowing that model, especially if Marlin is going to support other geometries (polar, robotic arms) in the future. Perhaps making Configuration.h a "meta" include, wherein the user uncomments "#include" or "#include", and the particular parameters of each type being in those files. You could even do some of your sanity checking that way by having each of those config files check for (and then set) a define like PRINTER_TYPE_SELECTED.

Apologies if these ideas have already been discussed to death. I'm new here. :)

[thinkyhead]

delta support seems to be squeezed in here and there.

That is accurate to how it has been developed. Johann Rocholl originally shunted delta support into cartesian-only Marlin, and it has been gaining support bit by bit over time.

its bottom stop

That's unusual. Deltas should ideally not have "bottom stops." If your effector can't be moved to the edge of the bed when the nozzle is touching the glass without hitting an obstacle at the bottom of the tower, the solution is to reduce your delta printable radius.

I also find it confusing how Configuration.h uses X, Y, and Z to refer to the coordinate space for the extruder, and also for the towers.

This is evolving, and is being changed as instances are found by sharp-eyed contributors.

I can appreciate the appeal of having almost all of the config in Configuration.h

More of the optional features are being gradually moved to Configuration_adv.h. At one point we pulled all the #include statements out of the configurations to make them "cleaner" and less breakable, but for delta / SCARA / Polar / Hangprinter / etc. –who knows?– maybe it makes sense to throw in conditional includes rather have additional kinematic-specific configs in the kinematic examples. Technically it is possible to split up the configs into several files by section and by feature, but we find it easier to keep all the example configs in sync with changes when there are fewer files to maintain.

[boelle]

@sr005307 Please post your question either on discord: https://discord.gg/n5NJ59y or on facebook: https://www.facebook.com/groups/2080308602206119/ The issue list is for bugs and feature requests only Please close this issue once you have posted it on one of the 2 links Thanks :-D

[boelle]

@thinkyhead i think we can close this one

[boelle]

@thinkyhead Another one that needs to be closed. Sorry, I got bored.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.