Unusable lookup table

[haley0918]

I'm opening an issue here as I had no reply for my post at Google Groups.

I have v0.1 hardware using the latest firmware from master branch.

Most of the time when I do calibration, the generated lookup table is unusable with the angle not changing at the beginning and end of the table. The angle only increase by 0.01 degree around middle of the table.

Occasionally I do get correct lookup table with about 0.02 degree increments.

I had checked through the encoder readouts and there are no problem.

bad lookup table.txt

good lookup table.txt

What could be causing my Mechaduino to get bad lookup table almost all of the time?

[jcchurch13]

That's strange. Can you try uncommenting line 193 in utils.cpp and commenting lines 194 & 195 to help debug this issue?

   193    // SerialUSB.println(fullStepReadings[x], DEC);      //print readings as a sanity check
   194    SerialUSB.print(100.0*x/spr,1);
   195    SerialUSB.println("%");

[haley0918]

Here's the debug log of the full step readings. On closer inspection, the count sequence below doesn't look right to me.

16131 16218 16305 14743 79 166 253 329

Could this be the cause? If so, what is causing this?

debug_log_0.txt

[jcchurch13]

Ok, I think I see what's happening. The calibration routine averages 10 readings at each full step location, and it looks like your setup has a full step right near the encoder's 16383/0 transition. For that one full step, the code averages values on either side of that transition, leading to the false intermediate value of 14743 (which throws off the whole cal routine). This is definitely a bug, and I'll try to patch this in the next day or so. In the mean time, you can try rotating your board a tiny bit, or removing the averaging by setting avg = 1 in the calibration routine in Utils.cpp.

Thanks for reporting this issue!

[haley0918]

Thanks for looking into this.

Would it be better to add a delay for each full step before taking readings? I'm thinking possibly either the shaft was oscillating or the encoder haven't caught up to a particular full step. So maybe a delay to let the shaft settle at new step and let the encoder catch up?

Will look forward to your patch.

[jcchurch13]

Ok, this issue should be fixed now!