Labview 2014 x64 bugs ( x32 as well) while calling FTCSPI DLL 2.0

[Labview_VCP]

Hello, i am working on labview program to interface with my hardware. I am using FTDI FTCSPI 2.0DLL.

For reason unknow to science, if i try to change control field with contants, DLL stops working, same happens if i just try to paint some variable ( connect to chart)

If i undo what i add, program starts to work ( by program i man data colledtion fron ftdi ftcspi dll. I never had this problem, and i have no idea why it's happening 

Just in case i attached program, so some one can look it up. When program stops working, i get error from DLL ( code, but it does not make sance, usually its FTC_INVALID_CONFIGURATION_HIGHER_GPIO_PIN, problem is, at any time i am using contant control box, and it does not change)

Any one have idea why it' happening ?

[Daniel.Parrott]

Hi,

Does this happen only when you change a certain number of controls to constants or is it if you change just one or more? Are you also placing the constants down by selecting the control and then choosing replace with constant?

[Labview_VCP]

even non DLL related tasks, like adding loop counter indicator can make it non functional. if i delete it, it works again. this is nuts. labview works, only dll returns no data, and give error that is not listed or have nothing to do with controll/indicator i added

[nyc_(is_out_of_here)]

---

@Labview_VCP wrote:

even non DLL related tasks, like adding loop counter indicator can make it non functional. if i delete it, it works again. this is nuts. labview works, only dll returns no data, and give error that is not listed or have nothing to do with controll/indicator i added

---

If you can, you might want to try calling the DLL in VB.NET/VB6  and see if you see the same behavior.

It can very well be that the DLL is buggy and that it isn't a LabVIEW problem.

[Labview_VCP]

originaly i writed program in VB. It works without any problems first time every time. i am making same exact function calls for open/init device to same dll. with same variables values. Still, with labview it just random problems 😞

[nyc_(is_out_of_here)]

---

@Labview_VCP wrote:

originaly i writed program in VB. It works without any problems first time every time. i am making same exact function calls for open/init device to same dll. with same variables values. Still, with labview it just random problems 😞

---

I would suggest calling your DLL from some other environment other than VB6.

[Labview_VCP]

its visual basic .NET 4.5 compiled on 2014 edition

[rolfk]

Well I don't have any LabVIEW 2014 here at the moment but what you describe is not nuts but simply the signs of a badly configured/used Call Library Node. And from the sound of it you do call a function that wants to return data in a buffer parameter but you forgot to make sure that buffer is properly sized BEFORE you call the function through the Call Library Node. The function assuming that it got a valid buffer simply writes its things into that buffer and in doing so overwirites memory areas that LabVIEW is using for something very different.

This is one of the most common errors most users do when using the Call Library Node, since in LabVIEW you do normally not have to resize an array to a certain size before a function can write its stuff into. In C you almost always have to do that and the Call Libraray Node is in fact interfacing to C code (even if it is written in another language the DLL interface is invented for C developed code and follows C conventions).

So don't blame LabVIEW but investigate every single VI with Call Library Nodes to:

1) use the proper datatypes as they are used in the function declaration

2) provide iniitialized string and array buffers to DLL calls that return some data in those buffers

3) make sure that you pass parameters that use C strings as C string pointer in LabVIEW and not a byte array, so that LabVIEW will make sure that the string buffer is zero terminated

I can guarantee you that the Call Library Node interface does work correctly if you configure it correctly. I have used it alot and absolutely every time it didn't work, it was either a bug in my DLL, or a misconfigured Call Library Node. And more than once it seemd to work very fine, only to break later somehow, and when further investigating there was something wrong in the Call Library Node configuration. That is in fact the most scary part, that it often can appear to work fine while you have in fact a problem in the Call Library Node configuration that will cause memory corruption sooner or later. 

When writing VIs with Call Library Nodes NEVER EVER assume that everything is fine because it doesn't crash! It can crash much later in your program eventhough your Call Library Node was the culprit or cause strange results as memory gets overwritten, or it can also seem to work fine until after you deployed your application to a remote location in the antarctis and have to do a 5 day trip first before you can try to fix it!

[Labview_VCP]

i did triplecheck everyhing.
When it works, it works just as well every time. And by adding simple indicator it will stops working

I only need spi_read function from main to work, rest looks like ok. can any one look it up and see if it's wrong ? ( on different older chip it works on labview first time every time, and i used that as reference for this new dll)
here is where function prototypes could be found:

http://www.ftdichip.com/Support/Documents/AppNotes/AN_111_Programmers_Guide_for_High_Speed_FTCSPI_DL...

SPI_ReadHiSpeedDevice ..................................................................................................... 37

I would be very happy if some one can help me

[rolfk]

Show your code as a snippet or better yet upload your VI backsaved in 2013 or earlier!