Difficulty with 3rd-party .dll

[marshaul]

---

---

That's a bold statement. Python is not EVERY other programming language. 😁

---

Dude, they literally have a functioning example for AutoIT. Not to mention all the other usual suspects. 

[rolfk]

---

@marshaul wrote:

---

---

That's a bold statement. Python is not EVERY other programming language. 😁

---

Dude, they literally have a functioning example for AutoIT. Not to mention all the other usual suspects. 

---

AutoIt? That would mean they just remote automate their own application?

Well, how about Lua? 😁

[marshaul]

@banksey255 wrote:

I've attached a modified version of your VI. Give it a run and see how you go.

When you tested adding the plDID parameter, did you ensure to pass it as a pointer to value?

---

Your version at least doesn't immediately crash LabVIEW, but evidently 0 is not a useful parameter, insofar as I don't get any actual data out of the function. Running the "--enumerate" command from their example reveals a VID, a PID, and a LUID (whatever those are) associated with my device, but so far none of those seem to be the necessary parameter to pass the USBConnect function. Of course none of this is documented, since they helpfully provided the usbConnect function which I can't use. 

Oh well. Thanks for your help, guys. I don't think I can justify any more time on this dead end. 

[banksey255]

Do you mean it still crashed, but just not immedietly when you ran the VI? If so, it would be interesting to know precisely when the crash occurred.

The value that LabVIEW initialises the memory location to of a parameter passed as a pointer doesn't typically matter (when it does, then it should be documented). In the VI that I attached, I used a value of zero just to give the memory location a known value so you can see if it changes, and I suspect that sample code included with the library would similarly initialise it to a set value before calling USBConnect. Pointers to values are commonly passed as a way for a function to output values beyond the function's return value by the function assigning the value at the memory location pointed to. This is why I suspect your original crash was caused by not passing a pointer to a memory location because when the function moved data into whatever memory location it used, bad things can happen that cause a crash.

[marshaul]

---

@banksey255 wrote:

Do you mean it still crashed, but just not immedietly when you ran the VI? If so, it would be interesting to know precisely when the crash occurred.

The value that LabVIEW initialises the memory location to of a parameter passed as a pointer doesn't typically matter (when it does, then it should be documented). In the VI that I attached, I used a value of zero just to give the memory location a known value so you can see if it changes, and I suspect that sample code included with the library would similarly initialise it to a set value before calling USBConnect. Pointers to values are commonly passed as a way for a function to output values beyond the function's return value by the function assigning the value at the memory location pointed to. This is why I suspect your original crash was caused by not passing a pointer to a memory location because when the function moved data into whatever memory location it used, bad things can happen that cause a crash.

---

No, it didn't crash. LabVIEW completed the .vi without complaint or error, but that array indicator stays all zeroes, instead of returning the ID of the card sitting on it.