That would be very helpful! If I get it working with Python in the meantime, I'll send you what I have.
So, one thing I did already is to wrap the MoveJ(..., blocking=False) statement in two lines that will measure the elapsed time. When I reduce the rate that I call MoveJ(..., blocking=False) at (e.g., every 50th time instead of every time), I get time elapsed measurements something like:
0.02692437171936035
0.02892446517944336
0.02849864959716797
0.030916213989257812
0.03730583190917969
0.032895565032958984
0.03286123275756836
0.033863067626953125
0.04114723205566406
0.0465848445892334
0.020911693572998047
So, on average, 33 milliseconds.
However, when I call MoveJ(..., blocking=False) at the desired rate (in my case, 125 Hz), the numbers seem to go up quite a bit:
0.05566143989562988
0.03397536277770996
0.052632808685302734
0.03386187553405762
0.03390979766845703
0.0668799877166748
0.03586983680725098
0.04915642738342285
0.04779958724975586
0.046747446060180664
0.05224156379699707
0.04627823829650879
0.0688173770904541
0.04802346229553223
0.05086350440979004
0.031949520111083984
0.031914710998535156
0.05627083778381348
So, on average, 47 milliseconds.
This could be because my computer is unable to keep up...? The code I am timing is simply Fanuc_2_Pose(...) and MoveJ(..., blocking=False).
In fact, this actually seems to indicate what at least one of the problems is... At 125 Hz, this code needs to be executed in 8 ms or less in order to keep up. But, it takes more time than that.
On the flip side, if all the positions weren't queued in the robot controller, then I think it would matter less because it would simply execute the latest, latent command I give it.
You may want to time your code as well.
The next step I will try is to use RTDE instead of RoboDK to control the robot and see if that makes a difference:
https://www.universal-robots.com/article...tde-guide/
https://pypi.org/project/ur-rtde/