BasicMicro

As an aside, your responsiveness to the issue was very encouraging - thank you! It makes me a lot more likely to recommend Roboclaws as a low-cost solution for a lot of our internal R&D needs for the robotics and other motion-related groups. They're really capable little controllers, they respon...

I'd been looping through a 16 and 17 (get encoder counts), a 49 (get motor currents), a 79 (read ispeeds counters), and a 90 (get status), and up to the point where things went wonky, I'd received valid responses to each command. The huge chunk of data that I was getting back were a single block of ...

Slowing things down didn't make any difference, but I did make more progress. It occurred to me that my example code (which worked) wasn't doing something that my production code did - it did not send a "Set S3, S4 and S5 Modes" (74) command on startup. I removed that command from the prod...

I got some time to follow up on this a bit more, as my demo code wouldn't exhibit the problem but the in-situ code continues to do so. I finally found my logic analyzer, and hooked it up to the TX/RX pins to see exactly what was happening. Every half-second or so, I'm retrieving the status of the Ro...

Sorry for the late response. I'm not really able to post the existing code as-is due to corporate rules, so what I did was distill it down to the simplest representative code I could. I ran that, and haven't been able to get the behavior to repeat itself. Soooo, it looks a lot more likely that there...

I'm working with a Roboclaw 2x7A with firmware v4.1.34. I'm connected via TTL serial from a Beaglebone Black at 115.2 Kbit/sec, and for the most part, things seem to work pretty well. Where I have been running into some issues is when polling the Roboclaw for encoder counts and/or status via C++, us...