Can't go up

[gcormier]

Can't go up

[gcormier]

Can you try a firmware reset?

[Mummer]

I did restart, reflash and anything what comes to my mind. I don't have original controller because I bought this table on crazy sale in ikea. Just before calibration everything work ok. In fact I was super happy because of this new feature and today was first day of working bekant since I bought it.

[gcormier]

Do you have the ability to connect a serial device to it to get some output? I wonder if we can use the features added by @philwmcdonald to spit out some information on the edge case here that you might be hitting.

[philwmcdonald]

Were you using the latest code on the dev branch or something else?

After recalibration/reset, do you get a full 4 (or 5) note arpeggio/tune played during power-on?
That indicates successful communications with both motors.

Is there anything physical obstruction on/around the leg? All connectors are fully inserted? reseat them to be sure.

Turning on #defines HUMANSERIAL is enough to get useful telemetry from megadesk with common serial-usb devices.
I think the current position (reported after issuing "<C,,") is based on only 1 motor's position however. We expect reported position of 99 or slightly less when at it's bottom/recalibrated position. There appears to be some coordination between motors and if the reported positions don't agree then neither will move.

[Mummer]

I'll try what you said and let you know about outcomes.

[gcormier]

Thought about this last night.

Just like there are different motor codes that report the IDLE status, it is also possible that the recalibration protocol varies between different motors/desks. We know of at least 3 variants that exist. I have 2 of them so I'll try the recal on my wife's.

Perhaps we can get HUMANSERIAL to spit out a startup message if it knows the variant? Mummer can check what is reported.

Another angle is that recal brings it to the lowest point. Did the motors somehow overshoot (heavy stuff on the desk?)... and after a recal, should we send an UP movement for a few units? However, we already have code that allows you to "escape" that bottom area if needed, so this shouldn't be needed.

megadesk/Code/src/megadesk.cpp

Lines 718 to 723 in 6188000

	else if (manualMove == Command::UP)
	{
	memoryMoving = false;
	// max() allows escape from recalibration (below DANGER_MIN_HEIGHT)
	targetHeight = max(currentHeight + HYSTERESIS + 1, DANGER_MIN_HEIGHT);
	}

[Mummer]

I have some info.
I don't use attiny but Arduino Nano and I reproduced a schematic from here:
https://github.com/trainman419/bekant

I think that I know what is the reason.
After calibration position raprorted from legs is close to 65000(a little bit over) which is not compliant with DANGER_MAX_HEIGHT and is close to int limit.
I dismantled motors form legs that they can spin freely and pushed button down until I can see some more valid position about 1000. Then I can finally move legs up and down. I wanted to change DANGER_MAX_HEIGHT to something more but rest of the code relies on that it is 16 bit int so that is not easy.
Sorry that I'm writing so late but I live in Poland so little timezone issue.

[philwmcdonald]

That's cool. Depending on what you found i was going to suggest disassembling and running the motors as you did. As I say, 99 is the lowest expected position. min/max defaults the danger max height all assume an operating range based on that minimum.
Were any changes to the code required to run megadesk on the nano?

[Mummer]

Very minor changes were required
declaration of the board

[env:nanoatmega328]
platform = atmelavr
board = nanoatmega328
framework = arduino
monitor_speed = 19200

Change all Serial1 to Serial
Thats it!
Flashing procedure is unusual because Serial port is used for programing and communication with MCP2003 so my current procedure looks like this.

1. Connect board to legs and let a second for setup/handshake
2. Unplug RX/TX pins from MCP2003
3. Plugin Arduino with USB cable to computer
4. Flash
5. Plug RX/TH pins and reboot board

If there is no MCP2003 connected to Arduino I have some problems with Arduino and I can't flash it. Only led on Arduino blik fast.

I solved my problem with calibration. I must be extremely carefull after this but it works. I'll post an update after final tweaks.
So basically now I'm storing DANGER_MAX_HEIGHT as long instead of int in eeprom with this code and I moved this value a little bit higher in memory to prevent overwrite some other values.

long EEPROMReadlong(long address) {
  long four = EEPROM.read(address);
  long three = EEPROM.read(address + 1);
  long two = EEPROM.read(address + 2);
  long one = EEPROM.read(address + 3);
  
  return ((four << 0) & 0xFF) + ((three << 8) & 0xFFFF) + ((two << 16) & 0xFFFFFF) + ((one << 24) & 0xFFFFFFFF);
}

void EEPROMWritelong(int address, long value) {
  byte four = (value & 0xFF);
  byte three = ((value >> 8) & 0xFF);
  byte two = ((value >> 16) & 0xFF);
  byte one = ((value >> 24) & 0xFF);
  
  EEPROM.write(address, four);
  EEPROM.write(address + 1, three);
  EEPROM.write(address + 2, two);
  EEPROM.write(address + 3, one);
}

[gcormier]

What are the highest/lowest values your desk can move to? I wonder if we switch this back to a long or something if that would help?

[philwmcdonald]

I'm not sure I understand why a long would be required for DANGER_MAX_HEIGHT.
The encoder value read from the motors is only ever 2 bytes and therefore a uint16_t will hold any value reported...

[gcormier]

Sorry quickly skimmed this as we just got back into town, I thought it was going past maxint.

As it was bought cheap/used from IKEA, maybe it had a problem? At the lowest position, if the values are over 65000.. that is really weird. I think the encoder that is on the motor is out of sync with the actual legs - it goes down from, say, 3000,2000,1000,0, then it wraps around to 65000.

1. The recalibration procedure merely lowers to the lowest points and then stops.
2. The recalibration procedure lowers to the lowest points, then issues some command which tells each motor "reset your counter/encoder to report this as height value 162 (DANGER_MIN_HEIGHT).

For the first, I can't think of how to reliably approach this issue as I think it's a physical issue with the legs and/or the motor control units.

For the second, based on what I am seeing, this is already done. The only thing I can think of would be if I dismantled my desk and messed with the motors, reconnected them, and then started seeing if there is additional back and forth between controller/motors that is missing to re-establish.

[Mummer]

I need a day or two to reassemby the desk as I rewired whole thing and to resolder my 'controller' to perfboard from breadboard.
I'll let you know about status after that actions.

[gcormier]

Sounds good, keep us posted :)