FTDI drivers usage in Labview

[VinnyAstro]

Uuuuf Coming back to this thread hurts ^^

After fighting quite too long to have a non-working code, we've finally invested in the NI USB 8451.

In literrally less than half a day I had a very well functionning communication program...

[Magesh003]

Hi!

As you are attached the zip for SPI communication. I'm looking for the same FT232H driver for I2C to read and write data. could you please share if possible for I2C.

Thanks in Advance!

[rolfk]

In my first response I posted two links to LavaG threads. The first is for the I2C version, the second for the SPI version for the MPSSE library.

But read the thread, the VIs as is won't work for 64-bit LabVIEW and they have a bug in the Read function as well as potentially in the Get Channels function, just as the SPI library had.

[TomMc7]

Rolf,

Thank you for your thoughtful and concise post.

I was having difficulty finding the error in handling the "handle".  I was searching for possible errors with importing FTDI's old LabVIEW 7 code example into LabVIEW 2020.  #3 in your post nailed it.

Now, with some of these updated DLL Call Library bricks in my foundation, I can proceed.

Note for others: FTDI says their "LabVIEW guru" has left, so they could not offer any insight on this "handle" failure.

Also, I have not searched yet, but there is probably a good tech note somewhere that points out more of these upgrade issues?

Blessings,

Tom

[MK2012]

Hello Gentremen, 

I had similar difficulty with handle in the past.

And might found the solution.

However, as the functionarity of FT4222 device was not enough for my application, I switched another device.

So that I didn't complete this investigation. 

The situation was as below.

I used two FTDI dll routines and the handle was not work correctly.

My solution was to make a kind of wrapper by C, which has a diffinition of handle and call two separate dlls through this warapper.

By doing so, two dlls will be in a same thread at the time of call.

Just for information.

Masao

[rolfk]

It should not be neccessary to write a wrapper for things like dealing with handles. Making sure the Call Library Nodes are configured correctly should be all that is needed. Yes it might mean that you can’t use the Import library Wizard but that should be a minor issue. If you can’t do that configuration yourself correctly you are playing with fire to trust that the Wizard can. It often can’t since the C syntax it has to use from the header file is not sufficient to describe all the possibilities of how parameters can be passed and pretty much nothing about memory management requirements for them.

[MK2012]

I'm sorry for the intuitive judgment, but what I mean is dealing with threads.

When you embed two independent DLLs in your program, the question is whether the common variable handle is recognized correctly if they are executed in different threads.

I created a Wrapper based on such suspicion, defined a handle in it, and called each of the two DLLs, and the problem was solved.

As I said at the beginning, I haven't verified that the idea is correct. However, handle can now be used without problems.

Best Regards,

Masao Kaizuka

[MK2012]

Now I restart the work that uses FT4222 device under LabVIEW.

Since I had many issues, I considered to switch to NI USB 8451 several times, but it could not be a solution because USB 8451 is too expensive.

As you are LabVIEW guru, you can create the set of Call Library Nodes, which can be used supporting all type of SPI and I2C devices, which FT4222 could support.

However, I just need only one device to connect same as other person's case. 

I did many mail transactions with FTDI support.  He mentions he can't support LabVIEW because the person who knows LabVIEW has quit.  

Instead, he suggested to check the sample code, which can be executed by Microsoft Visual Studio. 

As a result, all problems with FTDI devices have been resolved.

Then I defined a macro interface to call from LabVIEW.

Of course, this interface can only be used with this AAS33001.

When using other devices, it is necessary to rewrite the DLL source, but FTDI supports it well.  Furthermore, I don't like it because it is too complicated to change the SPI protocol in LabVIEW.

I am attaching the source code for your reference.

[rolfk]

---

@MK2012 wrote:

I did many mail transactions with FTDI support.  He mentions he can't support LabVIEW because the person who knows LabVIEW has quit.  

---

That person has quit 15 years or more ago already. Maybe they had someone else in the meantime picking up the pieces for a while but I would not know. It is the standard sentence they use for anyone asking about LabVIEW support.

The LabVIEW library they have for some of their interfaces is in LabVIEW 7.1 (released around 2004), reasonably ok but could just as well be a user contribution at some point. Maybe they had a technical support engineer who knew enough of LabVIEW to check the contribution and vouch for it to be good enough to be added to the support downloads. I don't know.

And I can understand that they don't feel like hiring someone specifically for LabVIEW support and buy a current LabVIEW license too. Although it may have been a good idea to do so 15 to 20 years ago for their test and validation departement.

Thanks for your contribution. I'll take a look at it when I get some time. It's always nice when users post the results they have come up with when solving a problem for themselves, even if it is a very specific solution for their own specific problem rather than a general purpose library (which is hard to create, test and maintain and usually can't be done as part of a different commercial project).

[TomMc7]

I just went through this with FTDI in my implementation of the UM232H in a current test fixture.  Earlier in this thread, Thanks to Rolfk, I found the reason that the version 7.1 dll interfaces don't work with newer LabVIEW.  The Handle input to all dll Call Library Functions must be changed to an "Unsigned Pointer-sized Integer".  After updating all the call library functions, my application is working flawlessly in V20 LabVIEW.  I attached a zip file of the updated FTDI call library saved in V9 and V20 LabVIEW. See the picture for the actual change required for the Handle pointer. I also provided this to FTDI.