Bytes at Serial port using 9870

[hkhiroya]

Hi,

Regarding the above message, when probing the bytes at port, it shows 61 bytes for anything above 61 bytes, thus the read vi only reads 61 bytes. I dont understand why this is the case....

Are there any settings that I am missing?

regards

Harshil 

[david.bolt]

Hi Harshil

 
The data in the FIFO are always correct, so to rule out some probable causes, a leak is not one.

One idea I have is to use the Debugging TDMS file. This is done by:

1. Opening the project

2. Add your cRIO to the project and copy FPGA.vi, RT.vi and the FIFO to the new target.

3. Compile the FPGA.vi

4. Run the RT.vi

5. The program creates a TDMS file named "mydebug". FTP this file to you local hard disk and inspect it. The file contains two channels: one with the error code and one with elements remaining. The elements remaining channel should always increase until it reaches 1000 elements where it drops to zero. If you inspect the curve in great detail, you should see that the curve will have a few small drops in between. This should have been impossible as the number of elements will always increase until it reaches 1000.What does this error file say?

If your not aware, your module has a 64B buffer size. So just to confirm this is the maximum number of bytes you can store, incase you try to add any more elements to be read.

Another solution I have is as follows:

The timeout is in clock ticks and not in milliseconds. Increase the timeout on the read and the DMA write to reduce data being dropped. As mentioned previously the 9870 only has a 64byte buffer so at 115200kbps and 11bits per byte it could get up to 10kbytes per second and could fill up within 4ms. But as this is in clock ticks please adjust accordingly.

[Robbob]

2. The vi (criovi) executes well sometimes, however sometimes I would set it to run and it stay there not finishing. I have to manually stop it. Why is this?

Harshil,

You have made a very fatal mistake in this code. You are opening the FPGA VI reference twice in parallel, this is know as a race condition. Each time you call this code, it could act differently depending on which call executes first. You are having two locations try and access a single resource (in this case, an FPGA VI) Why would you open and run and reset the same VI twice in parallel?

[david.bolt]

Hi Harshil

How did you get on with myself and Robbob's solutions? Did this work for you?

[VittoHAN]

Hi Robbob,

I'm trying to communicate with the 9870 moudle in my realtime target,

Could you please explain a bit that what kind of data type (U8, U32, etc...) should I set for the FIFO?

Thanks a lot!

Vitto

[Robbob]

Vitto,

Serial data is U8 ( 8 unsigned bits to make an ASCII character), and you could get by with using that as a FIFO size for most applications, with a few exceptions:

1) You have more channels than available FIFO's. Many targets are limited to 3 DMA FIFOs, so if you had 4 channels or more, you could not use 4 FIFO's, one for each channel. You would have to interleave data with whatever method is best for you to get by. For example, send a U32 with the first 8 bits as ch0, second 8 as ch1, third 8 as ch2, last 8 as ch4. If only the third channel was currently receiving a transmission, the other 3 channels would all send zeroes i.e. (00000000 00000000 10100110 00000000). Not the most efficient since u have to then extract this data on the RT target and you are sending more information than needed. Other ways to interleave would be to use a U16, with 8 of the bits identifying the channel the data is coming from and the other 8 bits being the actual data. i.e. data from channel 1 would be (00000001 01001010) and channel 2 would be (00000010 10101001)

2) You want to be as efficient as possible. Passing U32 data is slightly more efficient than U8 data. This is unnecessary unless you are very strapped for resources. Edit - I will add that this requires you have a LOT of information coming in as well on all channels involved. I dont want to confuse you by saying it is not efficient and then it is...this only works with huge amounts of data coming in.

I work very little with the 9870 module now, if you have further questions I would suggest opening a new thread and titling it appropriately.

[VittoHAN]

Dear Rob,

Thanks a lot for your reply.

Just one more question, when I was using the ¨NI 9870 - Continous Serial Read - On-Demand Write¨ example, I ran into this problem:

1. There is a tiny red arrow in the input wiring of the ¨Data¨ port of FIFO write invoke method,

2. And an error occurred (with code −63195, which means ¨The handle for device communication is invalid or has been closed. Restart the application.¨ http://zone.ni.com/reference/en-XX/help/370984R-01/criodevicehelp/ni_rio_fcf_error_codes/)

Could you please take a look at the attached pictures and what should my problem be? Could it be data type mismatch or what?

Thanks!

[Robbob]

---

@Robbob wrote:

I work very little with the 9870 module now, if you have further questions I would suggest opening a new thread and titling it appropriately.

---

However, it is very cold here in Austin, so I am feeling generous. The tiny red arrow is a coercion dot, so it is a data type mismatch. Your FIFO is most likely not set up as U8. Or, a recent change in the driver now coerces arrays to scalars, I havent worked with it since the last version so this is a possibility.

For the error codes, always search the knowledgebase first. Go to www.ni.com. In the search box, type '63195' and you will find your answer at the top of the results.

Since these questions are not related to 'Bytes at serial port', I would suggest making a new thread. Applications engineers will look at new threads and give you a hand if nobody helps out.

Good luck!