LabVIEW
LabVIEW 2016 crashes when communicating with Newport CCD and or monochromator
The original library definitely was flawed. While it most likely usually would work to pass in an array like this into a Call Library Node to be used in the DLL later on after the Call Library Node returned control to LabVIEW, it is absolutely a disaster waiting to happen. The array is usually kept alive (and not getting relocated to another memory area if wired in the calling diagram in the correct way, but this is the crux of this whole thing. Just add an array manipulation function anywhere on the diagram for this array and be not very very careful to make sure that function can never be called before the Ready polling returns with a true status and everything goes awry. LabVIEW is a managed environment and reserves the right to reallocate memory at anytime. That it doesn't usually do so because that is in most cases counterproductive for the performance, does not mean that it never can happen. An array passed into a Call Library Node is only guaranteed to be valid and non-relocatable during the Call Library Node call itself. After it returns there are just habits of LabVIEW how it handles those arrays, first dictated by making sure code executes right, then by not creating unnecessary performance killers and after that just whatever is easiest to implement for the LabVIEW developers. These variables can change between LabVIEW versions due to new optimizing algorithms being introduced and other necessary code changes for other features. So relieing on a certain non-guaranteed behaviour of LabVIEW is really just creating a time bomb.
Two things about your library:
1) You should configure the pointer you create correctly as pointer sized integer in all Call Library Nodes and as 64 bit integer in the LabVIEW diagram. Otherwise those VIs will quickly bomb when someone tries to use them in a 64 bit version of LabVIEW. Only reason to keep them as 32 bit integer is if you absolutely have to maintain compatibility with pre LabVIEW 2009 versions as the 64 bit version was introduced then.
2) I would wire the array through in the abort case of the Read CCD Area VI and return an extra boolean that indicates if there was a timeout. It shouldn't be the VIs decision to disrupt the passed through array buffer but leave that up to the caller. The alternative would be to have the VI allocate the necessary array on every call if it was successful. As it is now it is way to easy for an inexperienced programmer to create an array pointer that contains for instance 4096 bytes and an array that contains a bigger number, resulting in a bufferoverrun read, which is not as bad as a bufferoverrun write, but still has the potential to crash the program if the area after the end of the buffer happens to fall outside of any valid allcoated heap space for the current process.
@rolfk wrote:
[snip].
Two things about your library:
1) You should configure the pointer you create correctly as pointer sized integer in all Call Library Nodes and as 64 bit integer in the LabVIEW diagram. Otherwise those VIs will quickly bomb when someone tries to use them in a 64 bit version of LabVIEW. Only reason to keep them as 32 bit integer is if you absolutely have to maintain compatibility with pre LabVIEW 2009 versions as the 64 bit version was introduced then.
2) I would wire the array through in the abort case of the Read CCD Area VI and return an extra boolean that indicates if there was a timeout. It shouldn't be the VIs decision to disrupt the passed through array buffer but leave that up to the caller. The alternative would be to have the VI allocate the necessary array on every call if it was successful. As it is now it is way to easy for an inexperienced programmer to create an array pointer that contains for instance 4096 bytes and an array that contains a bigger number, resulting in a bufferoverrun read, which is not as bad as a bufferoverrun write, but still has the potential to crash the program if the area after the end of the buffer happens to fall outside of any valid allcoated heap space for the current process.
Thanks for the tip re: pointer allocation - will make it a rule from now on.
Re: 2,
I _had_ the pointer and array allocation on the (new) CL Read CCD AreaX" diagram - but then where to _dispose_ the pointer? It seemed "asymmetric" to allocate the pointer in the Read VI subVI, and de-allocate in Main/caller, so pointer allocation was moved up, into Main, with the de-allocation. That resulted in pointer allocation in Main, but array allocation in subVI - talk about an opportunity for memory-space discrepancies... So both array and pointer allocation is in Main - leaving CL Read CCD Area much more like it was originally. Also notice that the Data-in is U8, while the Data-out is U16. This allows the two memory allocations - pointer and array - to be clearly identical - at the cost of a cast in CL Read CCD Area.
It is right for CL Read CCD Area to not return any Data if none is acquired.
If I spend any more time on this, I might implement yet another alternative which is to make the CL Read CCD Area a functional global with Init, Close and Read functions - so to keep the memory manipulations safely tucked-away where they belong, while allowing the allocate and de-allocate to occur in the same "scope".
The pointer definitely needs to be somehow managed by the caller. It's nasty and anti-LabVIEW like but sometimes almost unavoidable. The alternative would be to rewrite the DLL to not rely on a buffer being passed into it to be used asynchronously while the function already has returned back to LabVIEW. Dataflow and asynchronous data operation do not go easily together.
An alternative might be to rewrite the whole LabVIEW library to be a class, make the pointer a Data Reference Value in the private data of the class and make sure to allocate at least the DVR if not the pointer inside itself at the "Creation" of the class. Most likely it would even work putting the LabVIEW array in the DVR but that feels brittle. The only guarantee that that array doesn't get reallocated between calls is the fact that it would be performance wise not a good idea to do so for the LabVIEW compiler. But LabVIEW never made hard guarantees about data buffers not being relocatable beyond the duration of Call Library Node calls. The fact that they normally stay put in memory where they were created is a mere performance reason as relocating memory costs time and CPU resources. With a class and a DVR the pointer would be hidden from the user of your library so that it feels more LabVIEW like.
As to your read function returning an empty array, yes it is a valid argument. But depending on the array size I tend to not unnecessarily resize arrays as they are passed through functions even if there is an error and indicate the error sitution in the error cluster or a separate status output. For the array in this case it doesn't really make much of a difference.
All in all the DLL is clearly written by a C programmer to be used in a C program. The idea of passing in a pointer in to be used asynchronously doesn't go very easily in all modern managed programming languages, including .Net and others.
