Sorry for the late answer.
have you done some tests like checking the input voltage ? Cause I had electrics problem at the same time as this TimeOut problem.
I didn’t have time to work on it, but I’ll try to solve this problem (with the electric ones) very soon. I’ll let you know about it !
"protocol": 2 + "sync_read": true + USB2AX -> don’t work
"protocol": 2 + "sync_read": false + USB2AX -> work
"protocol": 2 + "sync_read": true + pixl -> work
The second point is the more strange.
How did you manage to make the USB2X work with XL-320 ? Dynamixel protocol v2 is not supported with the embedded firmware of the USB2AX sold (firmware v03), you need to update the firmware to the v04 to do that.
If you already did, it is more likely an issue of the firmware but I would be very surprised.
All unit of USB2AX v3.2a sold for the last few years already have the v04 firmware. You can check on the back of the unit to see which version you have, and if it’s v3.2a it’s not necessary to update at this time.
And as such, they happily work with Dxl2.0 only without the advanced USB2AX commands - commands that are not needed anymore due to the very features of Dxl2.0.
The Sync_read command of the USB2AX is an advanced feature for the Dynamixel Protocol v1.0 (Dxl 1.0), and as such does not work with XL-320 which speak Dxl 2.0.
To add to the confusion, the new protocol Dxl 2.0 has its own form of efficient read packets, sync_read and bulk_read. These are real packets that do not receive any special treatment when sent to the USB2AX, and are directly forwarded to the servos.
So now the thing to check is if in the library code there is a difference in the way the sync_read packet is issued based on the presence or not of a USB2AX, that would push the lib to issue a Dxl1.0 sync_read instead of the correct Dxl2.0 sync_read.
Rigth. And this with one motor or 23 motors. And I can add :
“protocole”: 2 + “sync_read”: true + USB2dynamixel → don’t work
“protocol”: 2 + “sync_read”: false + USB2dynamixel → work
I have the same behavior for USB2AX(v3.2a) and USB2dynamixel.
With low level communication using : dxl_io = pypot.dynamixel.Dxl320IO('COM3', use_sync_read=True)
(without the pypot sync loop) setting use_sync_read = true doesn’t raise any error and the time for communication is about 2 times faster compared with sync= false.
I need to precise no error IF I don’t send command to quickly (under 200 Hz) if I send command very quickly I have a parse error (and I don’t have this parse error on Rpi + Pixl).
Just an idea, but It is like there is a collision between send and receive packets when using USB, sync_read and high frequency.
So the issue is present even if you control only one motor (with sync_read) ?
200Hz is very high for a sync_read packet (200*23 packets/s )
It shoudn’t impact the USB2AX, but on Windows, you have to change the latency of the FTDI driver (16ms by default) to 0 (or 0.1ms) for the USB2Dynamixel.
What exactly do you mean by that. Timeout seems to be way more frequent when using the sync_read instruction. But in average it’s still more efficient.
If you are using the protocol v2 in pypot it will use the “Dynamixel sync read” and if you use the protocol v1it will use the “USB2Ax sync read”.
Same as @Theo I don’t get how you reach such high frequency? On my test setup (with 6 motors) I can reach about 100Hz.
Numbers of timeout are not stable, sometimes no timeout for 20 secondes and other times one per second. Anyway I can not really use sync_read with USB2AX.
The good point is that it works with sync_read = false and it works with PIXL.
