This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
[BUG]On very first start, all inputs are triggered, despite being correctly pulled to ground #870
Comments
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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"
The text was updated successfully, but these errors were encountered: