I was playing around and found something interesting. If an LCD (i2c or otherwise) is even PRESENT in the patch, the lag shows up (even in the watch nodes while debugging). The LCD doesn’t have to be connected to anything, just present, and there’s lag. Remove the LCD and the lag is gone.
Here’s my diagram anyway -
I’m guessing both the encoder and LCD communication are trying to use interrupts. Probably LCD code it disabling interrupts, then encoder has to catch up when interrupts are enabled again. This shouldn’t be an issue after initialization if LCD isn’t connected and getting updates, though. Maybe they are using same interrupt, so LCD code is running when encoder interrupt triggers?
I’m not sure. What’s really odd is the lag happens even when the LCD isn’t connected to anything (in the patch or RL), it’s just present -
HI, LCD pulse “loop”, test with never.
Use change-pulse to update lcd, from OUT
To expand on cesars’ comment, since UPD pin on LCD is set to “Loop”, it is continuously updating even though it has no inputs. If it is competing with encoder for interrupts, that will be a problem.
LCD code includes this at the top:
if (!isInputDirty<input_UPD>(ctx))
return;
So display will never refresh if you set it to “Never”, but you could have it refresh when needed instead of continuously. Setting it to never in the above patch should eliminate the lag you are seeing.
Not sure why you are seeing so much lag with just encoder & LCD, though. I used LCD with line-following & obstacle avoidance robot (UPD set to Loop) with an UNO without much issue. Are you just missing ticks completely, or is it jumping as it counts groups of ticks?
Yep, that makes total sense. Before it would be hit or miss on turns of the encoder. Some CW turns would register as CCW, and vice versa; many turns just didn’t register at all.
If I do things this way then the lag is gone and, as long as you don’t go super fast, none of the rotations are missed -
This helped me understand the issue, thank you both!
You can replace or and all these links with just one node pulse-on-change between encoders’ OUT and LCDs’ UPD. 
Even better, thanks!
