Labview with FTDI D2XX drivers?

[Hoss183]

Ok, the actual mode is 'Asynchronous bit-bang'.

I will look for & play with the set latency. Lower values=better right?

Heres a screen capture of my init

and here are logs of the same operation on the 2 different machines

a typical write may be about 100 bytes, and reads 30-40 bytes.

Cheers, Paul

[myle00]

Ok, I'm pretty sure that latency hasn't an effect in async but bang mode, only in sync bit bang mode. So your problem might be something else.

I have written a small exe that you can use to test read/write timing to see if latency is what slows it down. Also, if it's not latency, this exe is about the simplest test so if you still see timing discrepancies between computers you might want to contact ftdi directly. In my experience when contacting (US) FTDI support they responded immediately. Just make sure you describe the problem completely including referencing the code (probably referencing the c code, since they might not help you with LabVIEW code) so that they take you seriously.

Now back to the exe, it's 32 bit release version and was built against version .14 of the driver. To run it, first name the exe filename with the device description followed by ".exe"; we'll use the filename to open the device by description. So if the device description is "a device", the filename should be "a device.exe". Then just run it.

On the screen it'll write 100 bytes followed by 124 bytes followed by a read of 100 bytes and 124 bytes. For each stage it'll repeat 20 times and then print how long an average read/write took. When writing/reading the same number of bytes as the transfer size (actually transfer_size/64*62) and if the transfer size is a multiple of 64 (we set it to 128), latency never comes into play. If latency comes into play, the 100 bytes read/write should take much longer than the 124 counterpart (Latency was set to 200ms, so if it has an effect it will be very obvious).

Either way, you can run it on multiple computers and compare for example each read/write between computers.

At the moment I'm away so I cannot test the code, but I have mutated it of some of the testing I do on FTDI devices so it should work. Let me know if you have any issues and of the results.

Matt

P.S. I'm also attaching the code used to make the exe.

[Hoss183]

HI Matt,

Thanks, this is really going above and beyond...

I've not had time to try your C code yet, i'll report back later on that.

But i have been playing wth 'bit mode', 'latency timer', 'read timeout' and 'write timeout'

I can get about a 25% improvement in speed (on the slow machines, cant try fast one at the moment) by setting to 'synchronous bit bang' mode. Setting the other 3 parameters to anything (0-100) has not noticable effect on the speed.

[Hoss183]

Ok, running your program.

Fast PC:

Write 100 bytes 0.00255232

Write 124 bytes 0.00309379

Read 100 bytes 5.33587e-006

Read 124 bytes 5.41968e-006

Slow PC:

Write 100 bytes 0.00255275

Write 124 bytes 0.00313539

Read 100 bytes 2.30394e-006

Read 124 bytes 2.27055e-006

Not a lot of difference (slow PC slightly faster on the reads)

[JÞB]

You are probably not going to like hearing this but,  There is a known bug in LabVIEW 2010 related to VISA reads not respecting the async flag.  Not pretty- but is it possible to move to LV 2011 where the bug is fixed?  Other than that It sounds like you understand the FTDI driver and the latency timer issue.... further reading can be found here just as a sanity check

[Hoss183]

HI Jeff,

Thanks for your input, but i'm not using VISA calls, and i'm not getting any timeouts, so i dont think that bug is related.

However, from sheer frustration i may try an upgrade to 2011 on one machine.

[JÞB]

Hmmmm. ... no VISA so ... (obviously WHY not? but.....)This could be similar to an issue with Windows clean-up not having the time to release a referance in between calls.   (Played in that pool once too).  what are the step load options for the calling sequence?  Consider loading the module dynamically and call a wait 0mS step just after to help Windows out

[myle00]

I don't know anything about test stand so I cannot help you there. But I'd try to run it in LabVIEW and time it yourself, without test stand. Calling the ft VIs from LabVIEW itself should be just the same as I was calling it from c. If in LabVIEW there's no difference between the fast and slow computer than you'd know that it's a case of measuring affecting the measurement (i.e. test stand screwing up as Jeff said). But I imagine, in your final system you'd run it in LabVIEW directly so it might not be issue?

Also, I'd change the call library function nodes in the ftdi VIs from run in the UI thread to run in any thread. That might possibly help.

As a side note, I've read somewhere that you should set the baud rate after setting the bit mode because that might affect the actual clock rate.

[Hoss183]

I have both a Labview application, and a Teststand system (which actually uses some common sub-vi's anywayy)

The time traces that i posted above are using the labview app with debug messages embedded at certain points.

So yes,  there definatly is a difference in the labview app between the fast & slow computer(s)

Teststand has the option to use either the Labview Runtime engine, or the development engine (if installed) - it makes not difference to my problem.

By the way the only fast PC i have is running Win XP, but i think i can disregard the OS as cause as i have tried both XP and Win7 and they all perform slowly.

I didnt understand the comment about the call library fucntion nodes, could you elucidate?

Baud rate after bit - ok will try that.

[myle00]

Ok, then you should post an image of your read and write calls so we can see if something is wrong there, otherwise it's hard to guess. If it's interleaved with other VIs, then you should do a test VI where you do only reads and writes (and post the VI). This way we can isolate the problem to the ft VIs. Because as it looks it's probably something with the LabVIEW code other than the ftdi VIs because the FTDI VIs are doing exactly what I was doing in c.

In the original post you said the problem was when you deployed it. By that you mean that on the deployed machine you only had the runtime engine and ran it as an exe?

---

Hoss183 wrote:

I didn't understand the comment about the call library fucntion nodes, could you elucidate?

---

Just to be sure, you're using these (http://www.ftdichip.com/Support/SoftwareExamples/CodeExamples/LabVIEW.htm) or similar VIs? If so, when you open say, FT_Write_Byte_Data.vi and look in the block diagram you'll see all the control going in and out of a call library function node (CLFN). Double click on it and you'll see a window like in the image. Select Run in any thread as in the image.