Hello, guys This is my first post, if there is anything wrong, please let me know. I use cRIO 9035 to control my motor system with 9263 and design a timing loop with 1ms sampling time as the main structure to send the command to my driver. All Vi codes are run on the FPGA. When I send short commands (about 15 seconds), everything works well. However, the longer command causes the timing loop finished late. For example, send command for 30 seconds and it works well before 25 seconds and starts to have finished late until to the end. After several testing, I can bypass this situation by "Run continuously". That is, send 30-second long command will have finished late at the first round and the same command works well at following rounds until I click the abort execution button. Anyone can tell me what happens and how to solve it? Thank you

LabVIEW

cRIO 9035 with finished late

It would be helpful if you could show the algorithm that you are implementing on the FPGA. We might be able to advise you on how to re-write the algorithm to run on the FPGA. It is likely to be different than how it would be run on the RT.

From what I understand you want motors to drive in a sine wave pattern, so perhaps they trace a circle. If your RT program generated a set of points that described the movement and then stepped through that set, telling the motors where to go, via the FPGA, then this approach may not work on the FPGA. I describe this approach as top-down and sequential: First you work out what to do and then you do it.

I recommend that you use a lower-level and iterative algorithm for the FPGA. Work out how each individual step relates to each other step, work out where you need to go for the next step and then go there, then repeat. For a circle, you just need to calculate sine and cosine of time.

The FIFO method will result in faster, more deterministic data transfer, but your original problem is probably caused by jitter in your RT, probably from when it initialises. If this is unacceptable then you should redesign your system in the manner I have described. I can imagine some work arounds; you could program a delay so that the RT starts, and stabilises, before you tell the FPGA to start. This would reduce the problem, but sudden spikes in demand for the RT processor could result in 'random' jitter that would probably be a big problem for you.

CLA - Kudos is how we show our appreciation for comments that helped us!