12-26-2005 09:04 AM
12-26-2005 09:14 AM
12-27-2005 07:52 AM
12-27-2005 07:56 AM
12-27-2005 12:04 PM
12-27-2005 12:35 PM
12-27-2005 01:00 PM
As I said, that shouldn't be the cause of the crash because the CLF node coerces the U16 values to U8s (the small gray dot).
@smercurio_fc wrote:
Well, right off the bat, the DLL is expecting an array of U8 and you're passing an array of U16 so that's not wise.
12-27-2005 01:10 PM
12-27-2005 02:03 PM
@smercurio_fc wrote:
It's quite possible the DLL is getting garbage values from the implicit coercion and it's not smart enough to check the values for "good values" before operating with them, and that's what's causing the crash. I've seen instances where this happens, hence my recommendation to change the datatype to U8.
Can you reproduce this? This definitely shouldn't be happening. A LabVIEW coercion should happen purely inside LV and not affect the DLL in any way.
That is an option, although it will not necessarily help because the problem doesn't occur when calling the DLL, but only when closing the VI. Due to this, another suggestion would be to call the VI as a subVI. It was obviously designed to be called as such and that might cause the problem to stop happening. This is obviously not a real solution, because if there is memory corruption, it's best to find it near the source than at some later time, but it might work.
Of course, an alternative test is to call the DLL from a C program in exactly the same way as is done in the LabVIEW code and see what happens.
12-28-2005 08:26 AM