LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Running NI 9871 at 1.25MBps continuously

Solved!
Go to solution

Hello

 

I am writing a communication protocol between the 9871 serial module and a DSP.  The code is: Send a command from LbV to the DSP and then read n bytes back. In this case I try to read 4006 bytes, but the issue is present whenever I try to read some amount over the serial buffers size. (Assume I can not change the DSP code)

 

Now the baudrate is either 1.25MBps or 115200Bps, there is no other baud rates where the error is below 5%. (Again assume that I can not change the DSP code). 

 

So because this application is time sensitive, I elected to go with 1.25MBps. This also works with <64 bytes packages, but it is apparent elements are written to the Serial buffer faster than I can consume them. This can be seen in the "Timeout500datapoints.PNG", where a boolean is latched if there was ever more than 63 bytes at the port. In the same picture it can be seen that it was supposed to read 1006 bytes, but only read 455 bytes, meaning 551 bytes were overwritten in the serial buffer before they could be read.

 

I have tried to increase the FPGA derived clock to 160MHz (From 120MHz) but this did not change the amount of bytes read, indicating to me that I in fact have no control over the clock on the 9871 module. I also tried removing computations from the read while loop to make it execute faster, but again this did nothing, indicating again that this is a limitation imposed by the 9871 module.

 

So my question is: Is it even possible to read 1.25MBps continuously on the 9871 module? And if yes, what do I need to do?

 

Sinc. Jonas

Download All
0 Kudos
Message 1 of 2
(1,294 Views)
Solution
Accepted by topic author jjacob95

To anyone who might've had the same issues as me, I found a solution. The solution was to address the "bytes at port" node as few times as possible and then read as much as possible from the 9871 module in chunks in a for loop.

 

So addressing the "bytes at port" in every iteration incurred a large overhead. My theory is that because the "Bytes at port" was followed by a true/false case, the FPGA optimisation algorithm had no choice but to open/close the connection between the 9871 module and the CRIO FPGA for every iteration. 

 

I hope this is useful for someone, I definitely have some good monologues about this product, seems like no one is using it above 115200 Bps.

 

Jonas

0 Kudos
Message 2 of 2
(1,233 Views)