Brett was kind enough to alert me to this thread. And thank you Brett for all the time you have spent helping out. I read through all the posts, and one thing I would like to mention about the red LED is that it needs to be on before the FPGA on the board will program. There is a signal that is output from the FPGA that says it is ready to be programmed, and this signal drives the red LED. It needs to clear its internal memory before it is ready, and it needs to wait for all three of its power supplies to be within specification (1.2V, 2.5V, and 3.3V). It should be within a tenth of a second or so. In other words, fast. The blue LED is simply connected to the 5V of the board. The green LED is the DONE signal from the FPGA. When it first powers up, the blue and red LEDs should be on steady. Then it will program once the plugin runs, and the red LED will go out and the green LED will come on. The only LED of the three that can be turned on or off by the FPGA is the red one. Once the plugin is talking to the FPGA, it will command it to blink the red LED every time it sends a packet of information. This happens approximately 10 times per second.
I'm not sure why you are seeing the inaccuracy with the X axis, but I have an idea. The current plugin can be off by one step at any moment in time, but it will never accumulate errors. The reason is because I needed to find a way that it would respect setup and hold times for the step signal relative to direction. In other words, lets say that it just output a step signal at the time it was doing a direction reversal. To make sure the stepper (or servo) driver's timings were not violated, I had to implement some hysteresis in the step signal. If it just output the step, then it can't output a step immediately when it changes direction. It has worked out well, especially for machines that have a high number of steps/unit, because in those systems, one step means very little. Like I said, it never accumulates error, it just could be off by a step. Being the perfectionist I am, I am going to remove the hysteresis, yet also provide the necessary delays that I couldn't add before. I have a solution in mind that will work quite well. I will implement it soon, after I finish threading and soft limits.
Please let me know if the error you see is more than one step, otherwise this probably explains it.
Thanks,
Greg