Jep, I‘m aware about 
Yes, I read your notes. They leave a lot of details to the imagination. Simply naming a list of features doesn’t really tell me what I need to know.
For example, you say you “fixed Velleman under-extrusion” without any commentary about why you think the stock firmware is under-extruding, how you determined the “correct” value, or what code changes you made in response. (If the default MM_PER_STEPS settings are wrong, it would be good to know it!)
I don’t think we need a new code branch just to encapsulate changes to Configuration.h. But if you have made more substantial enhancements to the code, it would be good to know what you are doing and why you think it is necessary. And those enhancements would, in theory, be of interest to people who own other brands of 3D printers.
Without more details, I either have to diff your code against the Marlin branch, or I need to install your “not everything is tested” firmware onto my printer and hope for the best.
You are doing some great work with this. It could have a lot more impact if documented more clearly.
1 Like
Sorry, but I’m doing this on my free time. Everything is wide open, you don’t need to diff anything, you can follow the commits to the branches. I’m doing this for myself at first, Basically yes, It’s a configuration.h and a configuration_adv.h commit on a repo so I don’t have to rewrite them everytime Marlin updates as Velleman clearly shows no envy to follow Marlin. I want to follow Marlin if/when I can so I do it. It can be useful for some people or not at all for others that do already change their own firmware by themselves. Plus I accept to implement things that make sense to me asked by others on Github. And rethink a few points so it fits my way of working. These are documented
I’m not gonna document what the commits already say, I simply don’t have time for this. Besides, I soon don’t have any Vertex Delta anymore, one of my two just fried the mainboard, stepper driver gone mad, doesn’t count one axis anymore and Velleman doesn’t support Switzerland/doesn’t send replacement main boards
So yes, I’m doing this because I once said I would. Flash if you want or not, but I’m not gonna be a scribe documenting every bits made
1 Like
Ok, thanks for everything you do.
1 Like
You’re welcome!
1 Like
Is there a reason why you declared these variables as ‘const’ in configuration_store.cpp? It seems that this could confuse the compiler. You should have gotten a warning…?
#if !ENABLED(AUTO_BED_LEVELING_LINEAR) && !ENABLED(AUTO_BED_LEVELING_BILINEAR)
const int16_t abl_grid_max_points_x;
const int16_t abl_grid_max_points_y;
#endif
EEPROM_READ(abl_grid_max_points_x);
EEPROM_READ(abl_grid_max_points_y);
What makes you think it would confuse the compiler? There’s no warning when compiling. I’m anyway gonna retract that part
I tried the latest version ‘After many tests, it seems better to be at 5x5 grid for bed levelling’
and added my changes for a heated bed. 3 times it did crash (software reboot) after skirt of some old gcods from SD card. 
movements are still odd.
I went back to Vellemans 1.1.4 with my alterations. Maybe I will give it a try after a while.
Thx for testing! Too bad you don’t report the bugs, I can’t fix what I can’t experience
I see now what you are doing there. The warning would only occur if you have disabled both linear and bilinear bed leveling.
If the variables are declared ‘const’ then the compiler assumes the values do not change, and can lead it to incorrectly optimize your code. In extreme cases this could break your EEPROM reading code entirely, but can cause more subtle problems. Worse yet, your code may behave very differently when run through different versions of the compiler, or with different options selected in the IDE.
Lool, didn’t know who’s who, sorry!
I tried the firmware and first thing the delta height was too small for my endstops and probing always failed, after i manually increased that from the lcd both probing and calibration runs. I enabled babysteps while I was in the Arduino environment and it works great.
The bed levelling is still a bit crappy but IMO this is due to some movement quirks because I’ve noticed the nozzle always seems to be too close in particular spots where it’s moving along a certain tower tower down.
Did you use the repo version or the release?
Sorry for slow reply, yes I did use the release. The probing problem was probably due to my endstops being particuraly high.
I’ve had some other problems and that made me create my own updated firmware fork (using parts of your config). This fork I intend to keep as clean as possible and also I added the Marlin firmware as a submodule to be able to update it easily in the future. Github repo there is both improved 1.1.4 version and the new one there.