Does the Pro controller happen to break out the PUL and DIR by any chance for each axis motor? I’m lost trying to figure out if the issue is the controller or the drivers.
I’m actually hoping the issue is just some mechanical flaw at the end of the day (bearing blocks, rails, etc) since it’s very difficult to get fiber controllers.
Did you try the Arduino by any chance?
I don’t have a pro, but it’s based on the same mcu and same firmware.
Not yet. It’s quite a bit of work to remove the rack enclosure without having to disconnect the fiber and gas supply.
As directed by LightBurn, we ordered a cheap-ish logic analyzer which will confirm if each driver is receiving equal amount of pulses to create a 360º shape. 
Unfortunately due to the weird weather in TX, packages are delayed by about a week. 
Analyzer finally came after serious package delays in TX. Ran tests, but they aren’t repeatable, so now we don’t know if the issue is the analyzer or the DSP…
Three pics of three seperate tests with 10 seconds of total sample time and 500kHz sample rate. Channels 0 and 1 are the Y axis outputs from the DSP and channel 2 is the X axis. The fact that the two Y axis results don’t match and that the results are different on each test doesn’t make much sense.
No idea where to go from here 
…
More progress! Changed the analyzer settings to get more consistent results. If anyone has experience, please feel free to double check!
We did three separate tests again.
The last three pics are the results of three tests. One test was a 50mm ø circle, and the pulses were 16000. Second test was a 75mm ø circle, and the pulses were 24000. Third test was a 100mm ø circle, and the pulses were 32000. Logically, this makes perfect sense.
To recap, the X and Y axes distance per pulse are set at 6.25 µM in the Trocen DSP. So, I’m not sure what math is necessary to determine if the total pulses are correct.
All of the X and Y axes pulses matched (again, please check if I did something wrong).
Settings
First Test
Second Test
Third Test
My math seems to work out to this for the 100mm ø circle results:
32000 pulses * 6.25 µM per pulse = 200000 total microns of movement.
Which equals 200mm. 
200mm would make sense since you have to go both directions. (go out 100mm and then have to return 100mm to get back to start)
Sooooo, backlash? 
Just did a 200mm x 200mm square, and the pulses for each axis were 64000 (correct).
I’m assuming that on circle shapes, the flat spots could in no way be caused by the X axis lagging the Y artificially during interpolation? Doesn’t seem plausible based on the earlier pics in this thread with the flat spots?
Now we’re still waiting on those genuine Gates GT3 belts and pulleys to arrive to hopefully put this to bed…
Swapped the X axis driver for the Z driver to rule out a bad driver. Still no change:
I still maintain that the result is exactly the same as the onscreen version you posted earlier. The onscreen version is a badly drawn circle, and so is the result.
Has nothing to do with it unfortunately. (Thought I mentioned earlier). The preview is just that, a rough preview to save on display resources and has nothing to do with the drawing.
I know it was mentioned earlier, but errors in the bitmap are directly visible in the finished cut.
The quality of that bitmap circle is not consistent with any attempt to save display resources or draw circles more efficiently. They weren’t drawn that badly in 1984 on a 128K Macintosh.
That may be so regarding the Mac, but that’s how it is regardless.
The new belts and pulleys are supposedly coming today
Best of luck! I hope it fixes things for you.
Essentially this Fusion360 drawing shows it better exaggerated: (Y axis is much less because there’s two belts) I actually think I’ve seen this when people put a J tech laser engraver on their Shapeoko and don’t get great circles: Shapeoko Pro and 4th Axis / Laser - #7 by AsylumWoodworks
Can you export a DXF or something from LightBurn just to rule that out?
50mmCircle.dxf (30.4 KB)