LabVIEW
labview development system needs to close error in calling dll
Can't really say without seeing the VI. Your description is kind of confusing.
The problem is most likely happening inside the dll. My understanding is that when LabVIEW calls a dll, it gives control to the dll so the dll can cause LabVIEW to crash without anything other than a system message like you have there.
Why did you write a dll to read from the instrument? It would be a lot simpler if you wrote it in LabVIEW native code, especially since you appear to be using VISA to communicate. I think it would clear up your errors, too.
Bill
Bill is right here. Little real information, big question about if the DLL is even necessary. Basically what happens here is that the DLL causes either directly or indirectly some access violation. Possible reasons are:
Your Call Library Node setup for one or more of the DLL functions is wrong. This could be a wrong datatype but another quite common error most LabVIEW programmers do is to not reserve enough space for return buffers, where the DLL wants to write something in. In LabVIEW if you call a subVI that subVI will simply allocate as much memory is necessary for its strings and arrays and returns whatever it finds correct to return.
When using DLLs this does not work the same. Lets say you have a function that returns some string information in a function parameter. Here before calling the function you have to explicitedly allocate that memory in the LabVIEW diagram, pass the string to the Call Library Node which passes the C pointer to the DLL and the DLL then can write into that memory. If you simply connect an empty string to the Call Library Node LabVIEW will basically pass a pointer to the DLL and that pointer points to a memory location containing one single NULL byte. The memory directly after that NULL byte is likely used by something else in LabVIEW. Now the DLL decides to write some nice string into that pointer and with that it overwrites more or less important information for LabVIEW. This can crash almost immediately if that overwriting destroyed some pointers that LabVIEW is going to access after the DLL function returns, or it can crash later, or only after you close the application, or only in the executable or only in the development environment, or it overwrites some variables used elsewhere and you get suddenly very strange results in your calculations, etc. etc. So if your DLL wants to return string or array information, you do need to allocate that memory before the Call Library Node and you do need to know the maximum size the DLL function will return (often this is not well documented and sometimes not at all, which is a bug in the DLL documentation). Because even if you allocate some memory but it happens to be to small for a particular call, it still will overwrite some data somewhere that it is not supposed to overwrite.
The other option is of course that the DLL itself has a bug. These things happen and me writing DLLs myself sometimes can tell you that it is much easier to create a DLL that does sometimes crash due to an wrong pointer, than creating one that crashes always 
and this is again a lot easier than creating a DLL that really does never dereference an invalid pointer or similar.
Rolf Kalbermatter
John Samuel wrote:
Thanks for your kind suggestions. It is working properly
Don't forget to dispense kudos and mark a post as the solution. 😄
John Samuel wrote:
Thanks for your kind suggestions. It is working properly
Also in addition to what Bill said, it is a nice treat to explain shortly how you made it work. That can help other sometimes with similar problems who go and search the forum for such issues.
Rolf Kalbermatter
rolfk wrote:
John Samuel wrote:
Thanks for your kind suggestions. It is working properlyAlso in addition to what Bill said, it is a nice treat to explain shortly how you made it work. That can help other sometimes with similar problems who go and search the forum for such issues.
Rolf Kalbermatter
Thanks, Rolf. This is even more important than what I added. 😄
