From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Labview libtiff implementation
You need to use the DLL with the correct bitness (32 or 64) for your LabVIEW version. A 32-bt application only can load DLLs compiled for 32-bit, and the 64-bit application only can load DLLs compiled for 64-bit.
Why would be reading custom tags harder? Of course you can’t provide ready made VIs that provide the user with the fully parsed data type for tags you don’t know but you certainly must have a low level function that actually locates tags in the binary stream to pass the offset and length to the actual parse function that returns then the converted data. Create a “conversion” VI that looks for the tag in the stream and returns the content as binary stream (personally I think a byte array is the most logical choice here but that requires the user to convert to string if he wants to use Unflatten or Typecast. So wish NI had made the Unflatten and Typecast accept byte arrays as an alternative to string inputs many versions ago! It would be a no brainer to do and cost zero time in terms of development time. Bonus points for allowing the Flatten to have a popup selection to choose between generating either of the two and default to byte arrays!)
The user then has to parse this custom tag data himself but that’s the nature of custom tags. 😀
Your problem is likely that you try to use this with 64-bit LabVIEW. At the time this library was created, the first 64-bit version of LabVIEW was less than 2 years old (2009), and almost nobody saw any reason to install it, since most Toolkits and other 3rd party libraries would only be available as 32-bit anyways.
Accordingly nobody even bothered to consider 64-bit issues when developing new libraries to interface to external code. The problem is most likely not in the DLL but in the VIs interfacing to the DLL. There are a lot of things that might need to be reviewed, revisited, modified and fixed to make those VIs compatible to the 64-bit interface of that DLL. Most can be usually done in a way that it works for both 32-bit and 64-bit, but only LabVIEW 2009 and later provides those features, and before around 2015 almost nobody even bothered about learning what those things are.
There is also the chance that libtiff changed some datatypes and function signatures over time and that your version from 2015 is also incompatible because of such reasons. I know for a fact that they did some changes to the library to add support for BigTIFF 64-bit files, but am not sure if that had any incompatible ABI changes as result.
So to answer your last question. Yes it is possible for sure. Yes, it is going to be a lot of work to review and modify the entire VI library properly. No, it is almost certainly not about regenerating the DLL, but modifying the VIs accessing the DLL functions. And yes, there is likely nobody going to do this for you, so are you willing to pull up your sleeves and get your hands dirty yourself?
rolfk，
Many Thanks for your patience.
I need to clearify that the libtiff3.lvlib I was found in Sciscan on Git, and the Labview version is 12.0, and the libtiff3.dll was generated in 2015. Can I infer that the problem comes from the change of Labview Versions.
And I have a second question about modifying the VIs accessing the DLL functions, since Labview provides a Tool to import Shared Libraries(.dll) to generate VI library and the Call Libraries Functions Node,which were used to generate the VI library and call the .dll we configured(specifiy the path where the .dll's location). Whether the only work I can do is to figure out the datatypes during regenerating VI libraries with Labview's import Shared Libraries(.dll) Tool, is there any other aspects I need to aware.
Please advice.
No it’s not that simple. Interfacing to external code is one of the more taunting exercises in any language out there. In C# it’s Interop, for Python it’s ctypes and for some other languages it’s FFI and LabVIEW calls it Call Library Node. The internet is filled with posts about borked attempts to use one of these to interface to some shared library.
And the reason is simple. Shared libraries where build according to what a C compiler could do and this means two things in order to interface to one:
1) You need to understand how to call the functions in the first place of course.That includes what parameters to pass, in which order to call the various functions, etc.
2) You need to understand and be able to do it in C perfectly in order to be able to do it safely in any other of the above mentioned.
Using the right datatypes is the first and by far easiest challenge here. This is what the Import Library Wizard can do for you.
But each of the mentioned languages is managed in some way. It means it has a specific way to manage how memory buffers are kept track off, how they should be passed between caller and callee, and several more related issues. C has none of this. C was originally designed to be as close to the bare metal of the CPU as possible without using assembly language. The result is that there are none such rules. There are conventions after 50 years of C programming but every C programmer has his own ideas about how to handle this. Many prefer to do it easy and simple and accept that there can be performance issues because buffers are frequently reallocated and copied between. This is the most common case, buffers ALWAYS need to be managed by the caller, and yes this means in LabVIEW you, the writer of the function around the Call Library Node. No machine intelligence can do this for you as much of the necessary information for that is simply not expressible in C syntax but needs to be taken from the hopefully available function documentation or C code samples! Others develop their own more or less involved and library specific management contract to sidestep some of these performance problems. None of these things can be described in the C syntax alone. It’s intrinsic knowledge that the user of the library needs to have by reading the library documentation very carefully, sometimes these things are not even clearly documented but have to be guessed based on name conventions and a deep understanding of C together with painful trial and error.
Basically if you can’t correctly configure the Call Library Node manually in a perfect way, using the Import Library Wizard is not a shortcut but a disservice to yourself. Every single function created by the Import Library Wizard needs to be carefully reviewed afterwards. In any reasonably complex library about 50% of the VIs need to be adjusted to not be a potential memory corruption device and almost all should be modified in some way to not burden the VI library user with C interface specific issues such as a separate numeric parameter indicating to the function the size of an array or string. LabVIEW strings an arrays carry their size with them and the VI containing the Call Library Node should do this translation for the user. But the Import Library Wizard can’t as fheir is no C syntax in the header file that could tell it that these two parameters belong together.
All potential memory corruptions WILL at some point occur according to Murphy, and are translated by LabVIEW into that famous 1097 error (if the corruption wasn’t dramatic enough to destroy major LabViEW internal data structures that make LabVIEW itself go belly up.
