First DOWN after powerup not working?

[Greg Cormier]

Flashing the current megaupdate builds... after plugging in a board, pushing DOWN button has no effect. Pushing UP button moves the desk, and subsequent DOWN button works without issues.

[philwmcdonald]

I couldn't repro this. Anything special about your setup?
Down button is held for >0.4s right?
I'm guessing feedback and bothbuttons options are off.

[Greg Cormier]

Hmm odd. I can't repro it now on my main unit. But it was the case for 50 boards.

Basically, it's flashed on a desk with no connection to a desk, and then powered down. Rinse and repeat. Then I bring a batch upstairs and test each one.

I wonder if it has to do with the auto detection of the IDLE value the first time it is up and running?

[philwmcdonald]

There's no state info that survives a reset apart from the contents of eeprom. None of the eeprom slots contain anything that should impact this either. However your desk keeps state: the encoder values on each leg/motor... Resetting the freshly flashed/installed controller after it can't descend does that work? How about resetting after it *can* descend?

[Greg Cormier]

This is on my todo list for this weekend...

[Greg Cormier]

Okay, I swear I'm not crazy, but I can't repro this either right now :)

Next batch of assembly, I'm going to pay a bit more attention and check it out.

[philwmcdonald]

I'm witnessing similar behavior now, sporadically.
With both up and down buttons.
But I've been making changes to linBurst() too so I'm not convinced I haven't made a mess of things.

I noticed a reset does recover and recalling a memory position in that direction also works.
At least one time the drift in position between the motors was 15.

[philwmcdonald]

It occurs to me that if the motors don't report idle then movement isn't possible. That should apply to any movement, so that's not a likely cause here. enabling SERIAL_IDLE allows that to be triaged/eliminated as a cause.
Also I enabled SERIAL_IDLE and notice that the idle value isn't always consistent:
sometimes the motors report:

>i0,0
sometimes:
>i37,37

[philwmcdonald]

I'm seeing if motor a reports 37, and b reports 0 It gets stuck in STOPPING4 state, and never goes idle.
For me that's the state where manual up/down buttons don't work.
What confused me was that memory recall shouldn't work either, I believe the difference is that the memory-recall beeps delay the regularly scheduled linBurst() long enough that both motors report the same value, transitioning to OFF state and allows subsequent movement.

[Greg Cormier]

Confirmed fixed! :)