Geeetech

_kaktus_ wrote: Fri Oct 12, 2018 11:07 pm Hi


Wouldn't it be better to introduce conditional compilation with one parameter
Depending on its value, part of the code could be omitted for compilation. What still requires a lot of work to adjust the whole code.

Then you have two firmware versions in one source. When making changes, it is very convenient and includes both versions at once.

This would make sense for bigger projects and solutions. Here, however, the bed levelling requires different firmware because
it's basically hardcoded. If it's enabled, you can't disable it without reinstalling the different version. And vice versa.

But since "3d touch" version perfectly fits into memory and flash, I see no reason why firmware can't be universal and contain both support and ability to disable/enable the sensor from menus.

For example nobody re-compiles Linux kernel each time they want to plug in a USB-device which wasn't there during the first kernel build. That would be absolutely idiotic.

Same goes for printer. And to maintain 2 different firmwares, from which one is ~supporting~ (I should write demanding) the sensor while the other doesn't demand nor support - that's insane.

The compiled hex file size difference between the two of them is neglible. The small firmware size difference has zero effect on performance of this printer, as touch sensor's routines are active only during bed levelling. The only slight difference in controller load during the print is coming from not having this functionality compiled in, but rather from the fact that levelled bed means that first print layers will be calculated against levelling measurement vectors. However, there is no difference whether multi-point levelling was done manually, or using the touch sensor.

That being said, maintaining 2 different firmware versions only because there's no way to control the function from end user interface - this is far from being optimal or reliable approach to software development. And what if I want to re-adjust offsets on the fly? You can't, as these 3 values are also hardcoded. That means that for each and every different sensor type (or even if manufacturers are cloning sensor designs) there are small variations in alignment, so all these variants must also have different firmware builds, only because of a few missing settings from printer's menus?

Sorry, but I must disagree with your view on this

Hello.


You don't have anything to apologize for.

Simply maintaining two firmware versions is a nuisance.
That's what we agree on.

If you program this functionality as an option available to the user, it will be a better solution than the one I suggested.
But more labour-intensive.

For my part, it was just a suggestion to avoid keeping two versions of the code.

So, I finished familiarising myself with the code. Although initially I'd like to bring some of it into 1.1.9 but this is going to be just Geeetech-specific. Eventually I'd like contribute main development version of Marlin, which now is 2.0.x

1.1.9 was the final version of 1.1.x branch.

I also reviewed all the pending pull requests and some forks of 2.0.x and it does seem that nobody else is looking into this, so it'd be a great new feature candidate

Started thinking today of a possible Web site, which would enable people to customise main configuration and after you press make button, it would compile the firmware and zip it along with chosen config for you to download. Only if I find TIME...

Hi


An ambitious plan.
I remain to wish you only perseverance in its implementation.

Meanwhile, some updates: viewtopic.php?f=91&t=61728