The strict answer to "Why?" is because we only implemented the special initialization code for the Initialize function. "autoConnectToFirst" is optional in VPP 3.2, and we chose not to implement it as a special case.
You'll just need to fix the Call Library Node in your VI wrapper to use the proper prototype. I'm not sure how best to handle the "IVI New Session" call; it really expects both a name and viSession, and "autoConnectToFirst" doesn't seem to return the name of the resource it chose. The "IVI New Session" function is what tells LabVIEW how to connect the VISA (or IVI) resource names with your viSession. You could call "VISA Find Resource" to get the first name and see if it's a supported device; this is supposed to match what "autoConnectToFirst" does. Along those lines, you might be better off implementing "autoConnectToFirst" yourself in LabVIEW. I.e., call "VISA Find Resource", and loop through the results calling your "Initialize" function until you don't get an error. Let me pull up a soapbox for a moment... There's a common misconception that "Import CVI Instrument Driver" creates a perfect LabVIEW wrapper around a VXIpnp WIN or IVI-C driver with no manual intervention. The reality is that you will almost always have to do some manual fixups of the converted driver. In LabVIEW 7, we improved the converter somewhat, and converting an IVI-C driver is now a three-step process: pre-processing the IVI-C driver, importing into LabVIEW, and then doing some programmatic fixups of the results. The resulting wrapper is better than earlier versions of LabVIEW, but it's not uncommon that you will still have to manually fix something up to make it a good, usable wrapper. That's why we consider "Import CVI Instrument Driver" to be a tool for instrument driver developers. If a vendor creates an instrument driver for an instrument in C, it doesn't make sense for each end user to have to create the LabVIEW wrapper, including all the manual fixups. Of course, if a vendor wants the best LabVIEW connectivity, they should write a LabVIEW-based driver. But if they're going to only write C- or COM-based drivers, they should create and distribute high-quality LabVIEW wrappers and not force end users to figure out how to do it on their own. My two cents. Brian
