Leaderboard

This is a bit late for you but for others here is some info. While that DLL does have a ReadWrite function for SPI operation it has no such function for the I2C part of the functions. One thing you could try is to change the threading of the Call Library Node for the Read and Write function to be run in any thread. This should save some time in invoking the function as no thread switch has to be performed and the execution for of the DLL function has not to arbitrate for the CPU with other UI related things in LabVIEW. While the documentation does not state that it is safe to call these functions from different threads it could be sort of inferred from the fact that it does state for the functions GetNumChannels() and GetChannelInfo() that it is not safe to do that, while this note is missing for the Read and Write functions. Of course it is very likely not a good idea to let LabVIEW run the Read and Write in parallel on the same communication handle as it is not only not clear which one would execute first but also might mess up the management information stored inside the handle itself if those two functions are executing simultaneously. So make sure there is proper data dependency between the Read and Write function (usually through error wire) to avoid that problem. It's questionable that you will get guaranteed 10kS data transfer with this but you should be considerably faster than with the current VI setup. Personally if I had to use this in a real project I would most likely implement the I2C and SPI operation entirely in LabVIEW directly on top of the FTD2xx library.

RomainP already mentioned that change in his post here: - conversion from and to string for "Data" deleted => Be able to receive also bytes with a value of 0. Another useful change not mentioned elsewhere would be to change all the Call Library Nodes to use a Pointer Sized Unsigned Integer variable for the handle parameter and change the controls on the VI frontpanel for the handle to be a 64-bit Unsigned Integer, in order to make the library more future proof to also work with the 64-bit version of the DLL.