ASCII Protocol collision

1

What happens if I constantly send speed commands to have the least amount of delay

v 0 1000 0\n

and once a while read a variable? I believe those two command sequences need to be synced, so I can send the next speed command only one the read has finished. I find that a bit dangerous.

My concrete problem is, in many cases I do never ever get a response to e.g. r axis0.error although I keep querying that every 5 seconds once.
In fact, I have the impression that if there is just one collision, it will never recover.

Wouldn’t it make more sense - assuming I am right - accept commands that do not return a value always?

2

Hi W_D. I’m not sure what you mean by “collision”. I see you’re using the ASCII protocol. Is this on UART or USB? As far as I know, commands are buffered as they come in.

ODrive does have a watchdog that will kill the drive if you stop feeding it via comms. The watchdog is configurable via <axis>.config.watchdog_timeout

3

I use UART.
That’s not the point. Let me describe the situation:

Every 0.05 seconds I send a speed command via the ASCII protocol. Works perfectly. Motor reacts fast and precise.
Every 5 seconds I send a “r axis0.error” command and print out all response on the UART line. Silence. Nothing happens.

If I remove the speed commands, then there is a response on above read command.

My conclusion: If I send a read command followed immediately with a speed command, the read does not send data.

Is that possible? Or is it more likely the problem is on my side, in your opinion?

4

Are you terminating the read command? “r axis0.error \n”?

5

Yes, else it would not work when I comment out the speed command and send read commands only.

6

It will still work without termination when sent in isolation.

7

What’s your UART baud set at?

8

Okay. But really, I send the full “r axis0.error\n” line in one command.
UART baud rate is the default 115k.

I get the impression you are saying that the odrive can handle such situations just fine and the problem must be on my side? Hmmmm. What could it be?

9

No I don’t know, but maybe there is a way to find out and if we do, next time I might want to use ascii in a similar way and then I don’t struggle :). Have you tried to either increase the baud or reduce your send frequency? It might be faster to test by reducing your send frequency from 20hz to 5hz and seeing if that makes a difference. Alternatively have a delay after requesting the read and see at which point it no longer replies, might be easier to figure out the problem this way.

10

That’s a good idea - will do.

11

Still not sure what was going on but it was definitely on my side.

Ich can read parameters via the ASCII protocol while constantly sending position commands also, no need to wait for the read to complete before sending the speed.