On very first start, all inputs are triggered, despite being correctly pulled to ground

[bschwand]

Describe the bug
I did read the documentation explaining uCNC uses normally closed limit switches, e-stop, which trigger by opening, thus letting the cpu pullups to pull the line up and trigger.. I understand by default uCNC will be in alarm mode if this is not taken care of appropriately.
So, with that said, On my very first start of uCNC after flashing I made sure to put jumpers on all inputs and limits to pull to ground.
uCNC started in alarm mode. The ? command showed everything triggered. So I thought that is weird, it seems inversed... removnig all jumpers pulling to ground allowed to start, then I did the RST command to reset, restarted... and now all inputs are triggered (as expected since they are now open). (and my config does have pullup enabled)

I think this is rather confusing, the behavior changed between two boots. Is that expected ? I did not see a warning about this.

Might it be that on first boot, with a totally erased flash (so it contains 0xFF), the parameters are nonetheless used and thus all inputs are inverted ? Then upon reset of settings, everything is set to zero and on the next boot inputs are not inverted anymore (i.e. require normally closed switches) ?

I think either a signature should be checked in the flash, if not present, delete everything, or the flash stored values are actually inverted from their meaning so that a fresh complete erase leads to all values being "disabled"

[Paciente8159]

Might it be that on first boot, with a totally erased flash (so it contains 0xFF), the parameters are nonetheless used and thus all inputs are inverted ? Then upon reset of settings, everything is set to zero and on the next boot inputs are not inverted anymore (i.e. require normally closed switches) ?

I think either a signature should be checked in the flash, if not present, delete everything, or the flash stored values are actually inverted from their meaning so that a fresh complete erase leads to all values being "disabled"

This was the previous default behavior in the past (similar to Grbl) up to version 1.10.2.
After some incident reported by a user that was storing the settings in an SD card and not in the EEPROM a new safety feature was implemented regarding the settings.

When the user powered the machine, the machine did not detect the external settings correctly and loaded the default settings. Unaware of that the user crashed the machine because it did it was not expecting that to happen.

If an error is found in the settings checking the machine is locked in Alarm mode and forces the user check the machine. The user can either check if the external memory is correctly connected (SD card, external EEPROM or FLASH, whatever), or if the internal memory got corrupted and then reboot the machine to se if the settings are correctly loaded again. Or do a full settings reset and this way be aware that the machine no longer has the user configuration and that it should be reconfigured.
This is a safety feature that forces the operator to be fully aware of the correctness of the settings. The settings reset must be intentional and not an automated thing.

That being said you can always revert to the old way of working by enabling this option here

This is also referenced in the FAQ section of the Wiki

[bschwand]

ok I understand that now.

However, I was not able to issue the reset command until I triggered all the switches. Maybe that was operator error but I could not do anything until I triggered all switches. Then I was able to issue the reset command, then untrigger and configure.

[Paciente8159]

I'll see if I can reproduce that situation and I'll give you some feedback