Labview with FTDI D2XX drivers?

[jfalcon]

I am attempting to read 1 byte of data after sending a 2 byte command using the D2XX application library calls with LV 2010 SP1.

Here are the steps as it is coded:

1. Open device for use

2. Configure Baud Rate (19200), Word Length (8 bit), Stop Bit (1 bit), Parity (None) and Flow Control (None)

3. Clear transmit (TX) and receive (RX) buffers

4. Wait 100 ms

5. Send 2 byte command

6. Clear receive (RX) buffer

7. Query receive (RX) buffer

8. Read data only if buffer has greater than 0 bytes else timeout

When executing the steps above, on the first execution, sometimes it returns the correct data but most of the time it comes back with incorrect data. On the second execution (using same 2 byte command), the correct data is returned. So it appears that 2 (at most 3) executions are required to return the correct data. I don't think that two executions are required to obtain the data.

I tried reducing the latency from 16 to 8 to 4 ms but saw no change.

I also tried adding a 50 ms wait time between steps 7 and 8 above but saw no change.

Anyone else seen this issue?

[glstill]

Why are you clearing the RX buffer after sending the command if it was already cleared after configuring the baud rate?  You could be racing against how quickly the device you are communicating with responds and how quick it takes your computer to clear teh RX buffer.  What latency are you talking about? the 100 ms wait?

[glstill]

When i mentioned "racing", i meant that there could be a race condition.  It is possible that the device responds before you clear the RX buffer and then you miss the response.  I would not clear the RX buffer and then simply poll the RX buffer by putting the FT_Get_Queue_Status.vi in a while loop setup with a timeout.  You can then put a wait in the loop and specify how often to pull the RX buffer.

[jfalcon]

glstill

For some reason, clearing the RX buffer before performing a read produced consistent results, they may not be correct results but at least the read data was repeatable.

The latency time is the time before the receive buffer is flushed out in the the FTDI device, which can be set using FT_SetLatencyTimer (default is 16 ms).

I will try what you suggested to see if it resolved this issue.

[jfalcon]

glstill

For clarification, inside the while loop, is the read being performed at the polling intervals or at the end?

[glstill]

I would have a case structure inside the while loop that only makes the read if the Get_Queue_Status.vi returns more than 0 bytes.

I made an example VI to illustrate this.  It is attached and a screenshot of it is also attached.

[glstill]

In the example, the Handle wire needs wired to the read function too.  I just put that VI together real quick to illustrate polling the RX buffer until bytes are available or the specified timeout has elapsed.  Thus the true case of the case structure will only execute if data is received in the RX buffer within the timeout period.

(Please accept as a solution or give Kudos if this is what you were looking for)

Gary

[jfalcon]

glstill

I tried the implementation you posted plus several variations of it and I am not seeing the correct data coming in.  It seems that the queue is being populated but with wrong data (no timeouts occurred).  If I were to run the VI at least 4 times, then I see the correct data appearing.

[tintin_99]

Hi, I tried the example on the FTDI site ( loopback test,  Write-Read String Demo and Read Byte demo ). all the function works fine except the read function and I either read nothing or bogus number like 65666 while I just write 6 bytes .

I have also shorted TXE and RXF to do this loopback test ( not sure I should do it or not )

Could you please help me on this . Basically I would like to make sure I can communicate with this FIFO and a simple write and read might be enough for me

I use FT245R 

Any help really appercaited

[Odd_Modem]

Isn't it easier to VCP rather than the DLL?