small dll problem

[Setu]

I have a DLL problem…

I am trying to create VI drivers for Texas Instruments dasport PCI-20450P-24. TI provides a bunch of C files drivers, which can be used in API. I am using the DLL that came with these Portlink (32-bit) drivers to create the VI’s using Call Library Function. I also have the dasport’s manual.

Working on the initialization routine, I only want to create a simple VI to initialize the software using the “pSWInit” function (the manual stated the software needs to be initialized first before the dasport can be initialized and configured). But to my surprise I could not find the pSWInit in the drop down functions list in labview 6i.

Does anyone know why this could be so? The function is certai
nly present because I can see it in the C header files with the function prototypes. I have also emailed TI, but they are taking their time in replying. Has anyone worked with these drivers or dasport before? I will also be interested in the older version of the drivers if at all.

I have attached the manual and portlink drivers if someone wants to check it out. As you must imagine I am very (very) new to labview and I will very much appreciate some help / advise / direction.

Thanks,
Setu

Portlink (32-bit)
http://www.instrument.com/pci/download/portlink.zip

DASport manual:
http://www.instrument.com/pci/manuals/855M393.zip

[Dennis_Knutson]

The function pInitSW is available. There is no pSWInit.

[Setu]

Thanks for replying. But then I try using pInitSW with the same parameters as pSWInit, Labview crashes with an invlaid page fault. The paramaters I used were no inputs and a 16-bit integer output which corresponds to "int pascal far" in C (I have no idea what int pascal far is, so i assume its an integer).
The calling convenction is set to "C"
thanks,
setu.

[Greg_McKaskle2]

> Thanks for replying. But then I try using pInitSW with the same
> parameters as pSWInit, Labview crashes with an invlaid page fault.
> The paramaters I used were no inputs and a 16-bit integer output which
> corresponds to "int pascal far" in C (I have no idea what int pascal
> far is, so i assume its an integer).
> The calling convenction is set to "C"


Actually, I think that the return value should be marked at I32 rather
than I16. I'm not in front of a PC, but Pascal indicates that the
parameters are expected to be pushed in order rather than backwards and
it expects the caller to clean up the stack rather than the callee. If
there is a pascal choice under calling conventions, use that instead.
If not, look up the other in the ma
nual or online help and see which
corresponds to Pascal.

Greg McKaskle