Call Library Function node with Vector's CANcaseXL and vxlapi.dll

[Automan]

I'm trying to access some functions from Vector's vxlapi.dll but I'm failing miserably as the data structures is too complex for me. Would you please give me directions (or provide a simple VI) in order to call the following function by using a Call Library Function node? I'm stucked mostly on how to create the controls to implement the structures below. The file attached is the API description. Thanks a lot.

The function I want to call:

XLstatus xlGetDriverConfig(XLdriverConfig *pDriverConfig)

XLstatus is an unsigned char and XLdriverConfig type is as follows:

typedef struct s_xl_driver_config {

unsigned int dllVersion;

unsigned int channelCount;

unsigned int reserved[10];

XLchannelConfig channel[XL_CONFIG_MAX_CHANNELS];

} XLdriverConfig;

typedef struct s_xl_channel_config {

char name [XL_MAX_LENGTH + 1];

unsigned char hwType;

unsigned char hwIndex;

unsigned char hwChannel;

unsigned short transceiverType;

unsigned int transceiverState;

unsigned char channelIndex;

XLuint64 channelMask;

unsigned int channelCapabilities;

unsigned int channelBusCapabilities;

unsigned char isOnBus;

unsigned int connectedBusType;

XLbusParams busParams;

unsigned int driverVersion;

unsigned int interfaceVersion;

unsigned int raw_data[10];

unsigned int serialNumber;

unsigned int articleNumber;

char transceiverName [XL_MAX_LENGTH + 1];

unsigned int specialCabFlags;

unsigned int dominantTimeout;

unsigned int reserved[8];

} XLchannelConfig;

typedef struct {

unsigned int busType;

union {

struct {

unsigned int bitRate;

unsigned char sjw;

unsigned char tseg1;

unsigned char tseg2;

unsigned char sam;

unsigned char outputMode;

}can;

unsigned char raw[32];

}data;

};

//defines for xlGetDriverConfig structures

#define XL_MAX_LENGTH 31

#define XL_CONFIG_MAX_CHANNELS 64

XL Driver Library - Description.pdf

Edited November 25, 2009 by Automan

[Troy K]

Sorry to resurrect an ancient thread, but in case anyone is searching for a solution to this it can be found here.

I cheated and used an intermediate dll.

 

https://decibel.ni.com/content/docs/DOC-30180

[Rolf Kalbermatter]

Sorry to resurrect an ancient thread, but in case anyone is searching for a solution to this it can be found here.

I cheated and used an intermediate dll.

 

https://decibel.ni.com/content/docs/DOC-30180

 

That is not cheating but the proper course of action unless you enjoy playing C compiler yourself and create a badly maintainable VI.

[ShaunR]

That is not cheating but the proper course of action unless you enjoy playing C compiler yourself and create a badly maintainable VI.

 

As opposed to a dynamic library that you cannot use on other platforms, you mean (e.g.LV x64),. I don't mind this approach as long as people distribute the C source for the intermediary, which seems to never happen  

[Rolf Kalbermatter]

As opposed to a dynamic library that you cannot use on other platforms, you mean (e.g.LV x64),. I don't mind this approach as long as people distribute the C source for the intermediary, which seems to never happen

 

"Never" would seem a very strong statement to me. See the OpenG LabPython, LVZIP and Pipe library just to name a few.

 

It seems the person having done the vxcan API wrapper did indeed "forget" to add the C code to the download, especially since that wrapper doesn't really consist of any magic at all, but simply some C to LabVIEW parameter mapping. I fully understand that providing multiple platform wrappers can be a real pain in the ass, which would make it a good idea to add the C source of those wrappers, so others can recompile for new platforms, but doing everything on the LabVIEW level is not a maintainable solution in the long run at all.

 

Usually APIs are anyhow different enough between platforms that a pure LabVIEW wrapper gets a real pain to do, such that it works on multiple platforms, unless the API developer kept in mind to keep the API binary consistent between platforms.

[ShaunR]

See the OpenG LabPython, LVZIP and Pipe library just to name a few.

Don't know about LabPython but the intermediary DLL source for the openG zip and pipe libs definitely isn't distributed with the packages as I would have recompiled them for x64 by now ;P Are they elsewhere? Link perhaps?

[Rolf Kalbermatter]

Don't know about LabPython but the intermediary DLL source for the openG zip and pipe libs definitely isn't distributed with the packages as I would have recompiled them for x64 by now ;P Are they elsewhere? Link perhaps?

 

As with all OpenG sources, they are on the OpenG Toolkit project page on sourceforge. All of them!

[ShaunR]

Seeing as your link button isn't working
 

As with all OpenG sources, they are on the OpenG Toolkit project page on sourceforge. All of them!

I didn't see the Pipes anywhere on there. But I did find a build of lvzip for x64 which everyone has been asking for  Did you really create that a year ago?

[Rolf Kalbermatter]

Seeing as your link button isn't working

 

I didn't see the Pipes anywhere on there. But I did find a build of lvzip for x64 which everyone has been asking for  Did you really create that a year ago?

 

I compiled a version but that crashed, so left it at that for the time being. No use in releasing something that does not work. Should get some better test setups soon so that debugging will work more easily.

 

And the Pipes library was never officially released, so we never ported it over from the CVS repository to the SVN one. It's still in the CVS only.

[Troy K]

OK so I worked out what I was doing wrong and now dont need the intermediate dll any more.

So now the C source code isn't needed any more (in fact I had lost it)... Not that the debate it triggered wasn't interseting.  

 

 

Turns out I had the call library function node set to use 'C' calling conventions when it should have been set to 'stdcall'.

 

Still the same link but the content there is now updated.