LabVIEW
Call Library node is acting . . . Flakey
@jhandy wrote:
Hi all. I recently transitioned a project from labview 2009 to labview 2010 and one very simple VI has started exhibiting very strange behavior. The VI in question (attached) is just a wrapper for a C DLL call. The function prototype looks like this: HANDLE comsyncPortOpen(unsigned char port, DWORD * dwErrCode) and I've defined it in the call library node as follows: uint32_t comsyncPortOpen(uint8_t port, uint16_t *dwErrCode).
So here's the deal. In labview 2009 this worked perfectly well. In labview 2010, the VI itself works perfectly well also. However, when I include it in another VI, the reference returned is always zero despite this VI's front panel indicating otherwise.
I've found a couple of things that will resolve the issue. For example, removing the constant block seems to fix things. Also, if I add another indicator, attach it to the dwErrCode output, and connect the indicator to an output terminal, this will also resolve the issue. Its great that I have a workaround but this smacks of a pointer issue and I'm worried it will rear its uggly head at the slightest change in configuration.
So my question is, what exactly is the correct way to handle pointers with the call library node? How do you properly allocate memory? Does it happen automatically? Do I need to connect something to the dwErrCode input to allocate memory or should I just leave it unconnected?
I've poked around and the examples I have seen are all over the board. Sometimes I see different implementations in the exact same VI. I love labview, and they are great about providing quickstart tutorials, but it seems like their documentation is always lacking when it comes down to these sorts of nitty gritty details.
Just a quick note: The DWORD WinAPI type corresponds really to an uInt32 in LabVIEW. So here LabVIEW allocates a 16 bit memory area for the function to write into but the function then writes 32 bit into memory. Before LabVIEW 2010 this may have accidentially worked (as it does now in standalone mode) because LabVIEW may have reserved a 32 bit value anyhow. Now LabVIEW seems to be much more following the CLN configuration to the letter, and this causes the function to overwrite 16 bits LabVIEW likely has used for something else.
I still have to see a case where LabVIEW 2010 really does something wrong with CLNs rather than just following more to the letter whatever the CLN configuration specifies. It seems someone took the CLN under hand and made it more strictly follow the rules that the configuration implies which is a good thing from a C programmer viewpoint but may be not so wise in the LabVIEW case. On the other hand these changes may have been necessary to allow support for some new upcoming platform release or whatever.
