Problem with LibFT260.dll from FTDI => data written not as expected

[BDeh]

Hi together,

I have the following problem with the LibFT260.dll from FTDI:

I would like to output data (byte array) via the eval board UMFT260EV1A with LabView.
The initialization of the board has worked so far.
However, the data I read back after the output via hterm does not match what I have output.
Exactly the same with a read of received data.

Am I making a mistake when passing the IpBuffer to the dll?

Unfortunately, I did not succeed in importing the libFT260.dll with the wizard. so I used the call libraray function.

The file uart.ccp is a sample code from FTDI.

I attached the following:
-My vi
-the DLL + headers
-the c++ example
-user guide to the DLL

Thanks for your support.

Bernd

[rolfk]

You should not wire magic constants to the terminals dwBufferLength and dwBytesToWrite, but instead use and ArrayLength node to see what the input length of the data is and simply wire that value to the two parameters. Not sure why the function would use two values for this, usually it should be enough to know how many valid values are in the buffer. It almost sounds like the function wants to use the buffer internally for its own scratch space, which would be highly strange for a write function.

Also don't configure the buffer value as Adapt To Type. In this way if someone for whatever reason changes the datatype of the control, the datatype of the buffer would change too, but since this C API has a datatype of array of bytes you should configure it accordingly. So make it an Array Of Integers, U8, passed as Array Data Pointer.

Also change all the FT260_HANDLE parameters to be a pointer sized integer. This will save you some trouble when you eventually will move to LabVIEW 64-bit, and the hopefully available 64-bit version of this DLL. The days of LabVIEW 32-bit are definitely counted!

[BDeh]

Hello Rolf,

many thanks for your quick reply.

I changed the vi as follows:

If I understood the description of the dll correctly, the array length is specified via BufferLength. BytestoWrite then describes how many bytes should be transferred from the array.

Unfortunately, however, I still have the same result.
E.g. I send 0x00 0x00 0x00 0x00 and read FF FF FF 00 outside on the receiver side.

I didn't quite understand the change of "FT260_HANDLE parameters to be a pointer sized integer"!?

Unfortunately I don't have the possibility to address the dll via C++. It would be interesting if the same thing happens.

BR Bernd

[BDeh]

Hi Rolf,
Thanks for your quick reply.
I have changed as follows:

unfortunately without change.

can you watch it again

I didn't quite understand that with the FT260_Handle.

BR Bernd

[BDeh]

Unfortunately I don't have the possibility to access the DLL via C++. It would be interesting if the output of the data behaves identically.

Currently I am sending 0x00 0x00 0x00 0x00 and receiving 0xFF 0xFF 0xFF 0X00 !? why?

[rolfk]

There is a lot of things fishy with this DLL and also the VI that you created.

First, the device enumeration returns 22 devices on my computer. Without any FTDI hardware (that I know of) plugged in. Of course Dell may build in some FTDI 260 chips in a computer but certainly not 22!

So if I then go and select any of those 22 it happily will go through the calls until I try to do the FT260_GetChipVersion() call. That one returns an error code 12, which means according to the header file FT260_BUFFER_SIZE_ERROR. Huuhh? Wait a minute, what? That errror doesn't really make sense, but I guess any error returned here at least will mean that the selected device is not the wanted FTDI device, so at least something. And it means that in your VI you should basically abort everything and not attempt to execute anything more!

Because if I go through your program and execute the FT260_UART_Init() call then, very bad things will happen! The Call Library Node returns the threaded 1097 error, so apparently that function tries to do something internally and because it is not an actual FTDI 260 chip it totally trips over its own feet and causes some internal error that LabVIEW catches but after a Call Library Node returns 1097 it is basically unsafe to continue executing anything. Your memory may be corrupted and whatever your program may try next could theoretically eat your hard drive or make your computer go in flames! And no, this isn't completely over exaggerated but a real potential problem.

So your VI needs to be a lot more diligent about error handling. If a function returns an error you should simply not continue to execute anything and just close the session and return with that error.

As to your read after write. I'm not sure what the problem exactly is but you may actually deal with the same problem that most LabVIEW beginners happen to have when using VISA. They use the "funny" Bytes at Serial Port function and wonder why they don't receive the data they expect.

But you need to consider what is connected at the other side. First that device must understand the data that you send to it. If it doesn't it may go into panic, erase itself, or just sit there and think "Don't talk nonsense to me, I'll only answer when I understand what you are telling me!"

And that means that it needs to understand the data it receives including a possible termination indication that tells the device: "Voila, this is the command! Now you can go and parse it and react to it!" And that command you send of course needs to be a command that prompts the device to actually respond in some way. It means you need to understand the protocol that this devices is using. And that also means that you can't talk to the FT260 chip itself but instead need to have an actual device, for instance a microcontroller attached on the other side of this chip, and this device needs to run a program that receives data on the serial line and responds to it. And this requires time! Serial data lines are pretty slow (in terms of what your PC can do) so by the time your LabVIEW program reads how many bytes have arrived in the incoming queue, the device likely hasn't even received the entire data, let's not talk about decoding it, and answering to it and sending it back over the equally slow serial line.

So there are many many things that could go wrong. Interfacing to the chip is only a first step and once that works you need to do actual device protocol debugging. But first try to make some better error handling.

As to what I meant with the handle, look at this library. I did not fix anything else discussed earlier, just cleaned up the Call Library Nodes a little and changed the handle type to be a pointer sized integer.

[BDeh]

There is a lot of things fishy with this DLL and also the VI that you created.

Okay, I'll be looking for Core2 soon... hopefully it will be better after that 😉

First, the device enumeration returns 22 devices on my computer. Without any FTDI hardware (that I know of) plugged in. Of course Dell may build in some FTDI 260 chips in a computer but certainly not 22!

The DLL shows all HID Devices devices on your computer, including those without an FT260 chip.

So if I then go and select any of those 22 it happily will go through the calls until I try to do the FT260_GetChipVersion() call. That one returns an error code 12, which means according to the header file FT260_BUFFER_SIZE_ERROR. Huuhh? Wait a minute, what? That errror doesn't really make sense, but I guess any error returned here at least will mean that the selected device is not the wanted FTDI device, so at least something. And it means that in your VI you should basically abort everything and not attempt to execute anything more!

Yes, if the HID device does not contain an FT260 chip, you will get this error message.

Because if I go through your program and execute the FT260_UART_Init() call then, very bad things will happen! The Call Library Node returns the threaded 1097 error, so apparently that function tries to do something internally and because it is not an actual FTDI 260 chip it totally trips over its own feet and causes some internal error that LabVIEW catches but after a Call Library Node returns 1097 it is basically unsafe to continue executing anything. Your memory may be corrupted and whatever your program may try next could theoretically eat your hard drive or make your computer go in flames! And no, this isn't completely over exaggerated but a real potential problem.

So your VI needs to be a lot more diligent about error handling. If a function returns an error you should simply not continue to execute anything and just close the session and return with that error.

Yes, I will then improve the error handling in the application. This vi is initially only used to communicate with the FT260 => therefore ....firstSteps

As to your read after write. I'm not sure what the problem exactly is but you may actually deal with the same problem that most LabVIEW beginners happen to have when using VISA. They use the "funny" Bytes at Serial Port function and wonder why they don't receive the data they expect.

But you need to consider what is connected at the other side. First that device must understand the data that you send to it. If it doesn't it may go into panic, erase itself, or just sit there and think "Don't talk nonsense to me, I'll only answer when I understand what you are telling me!"

And that means that it needs to understand the data it receives including a possible termination indication that tells the device: "Voila, this is the command! Now you can go and parse it and react to it!" And that command you send of course needs to be a command that prompts the device to actually respond in some way. It means you need to understand the protocol that this devices is using. And that also means that you can't talk to the FT260 chip itself but instead need to have an actual device, for instance a microcontroller attached on the other side of this chip, and this device needs to run a program that receives data on the serial line and responds to it. And this requires time! Serial data lines are pretty slow (in terms of what your PC can do) so by the time your LabVIEW program reads how many bytes have arrived in the incoming queue, the device likely hasn't even received the entire data, let's not talk about decoding it, and answering to it and sending it back over the equally slow serial line.

I don't use a receiver in the form of a microcontroller in my setup. I only send a few bytes which I read back with an interface diagnosis tool (hterm) via a COM port. The data is then read back in the form that I send back a few bytes via the interface tool. My current problem is that the write-bytes that I transfer to the DLL for sending are not received identically by the interface diagnosis tool.

write 0x01 0x02 0x03 0x04 to the dll => receiving 0xFD 0xFB 0xF0 0x00 with diagnostic tool.

I don't see any logical connection between the output data and what I'm receiving via diagnostics

So there are many many things that could go wrong. Interfacing to the chip is only a first step and once that works you need to do actual device protocol debugging. But first try to make some better error handling. Roger that. However, the error handling does not seem to be the problem at the moment, since no errors are displayed. all functions return 0=OK.

As to what I meant with the handle, look at this library. I did not fix anything else discussed earlier, just cleaned up the Call Library Nodes a little and changed the handle type to be a pointer sized integer.

I saw that. Many Thanks. The vi works so far. However, the problem with the implausible data that I read back with the diagnostic tool still exists. I will now ask FTDI for support. The data might have to be transferred or interpreted differently.

Thanks for your support;-)

[BDeh · Accepted solution]

I could find the error. The TTL-RS232 converter I used was defective. With a new converter, the transfer worked. The send and receive data are okay now.

@Rolf: Thank's for your support and the helpful tips 😉

[moatez]

can you give me you library LibFT260.lib with the functions i am working with the same board UMFT260EV1A