Communication with vector Hardware VN 5640 via ethernet using vxlapi.dll

[Aliza24102002]

I want to communicate with VN 5640 Hardware directly using vxlapi.dll, sending the Ethernet signal to VN 5640 using LabVIEW using dll method please share any knowledge article which I can use as reference.

[ZYOng]

Vector XL Driver - LabVIEW wrappers

Might not have support for Ethernet, but it is a good starting point.

[Tarunakgec1]

I am also looking for same, I have tried it for CAN ,LIN.  i was able to do, but couldn't succeeded for Ethernet It will be a great help if someone can provide some solution ..

[TroyK]

For anyone looking to do this, Vector has changed the access method for their ethernet devices.
They are calling the old method "channel based access", still used for CAN etc.

The new method is called "network based access" and their ethernet hardware will now only use this access method.

(Older Vector ethernet hardware may support channel based access, but developing libraries and applications around these deprecated functions has limited future usefulness.) 

The major problem with this new "Network Based Access" method is how poorly it is supported in the vxlapi.dll functions.

The only way to access the data in a network device config object is through C++ function pointers, which can't be called by LabVIEW. It is necessary to create an intermediate C++ dll to execute the functions that can only be accessed through function pointers.

I wrote to Vector last year and asked them to update the API to allow better access.  They said no.  I guess on top of paying for their hardware they want you to buy CANoe licenses too. Not use the free API dll.

[rolfk]

---

@TroyK wrote:

The major problem with this new "Network Based Access" method is how poorly it is supported in the vxlapi.dll functions.

The only way to access the data in a network device config object is through C++ function pointers, which can't be called by LabVIEW. It is necessary to create an intermediate C++ dll to execute the functions that can only be accessed through function pointers.

I wrote to Vector last year and asked them to update the API to allow better access.  They said no.  I guess on top of paying for their hardware they want you to buy CANoe licenses too. Not use the free API dll.

---

It could be accessed from LabVIEW through the use of https://www.vipm.io/package/easlib_memory_manager/ but I will give you, that this requires in fact more knowledge about C pointers and how C compilers put things in memory, than if you write a wrapper DLL in C.

[TroyK]

I admit that my knowledge of calling C++ functions from LabVIEW is limited. Perhaps I am missing something.

I am able to get the structures out once they are created. But following the example given in the API documentation I run into a roadblock...

1. I can execute the function xlCreateDriverConfig which returns a pointer.
   In the example that function is used to create an object named "config", which is a struct that contains a handle and seven function pointers. I can get all these pointers out, but they are useless.
2. The example then executes a function using one of the contained function pointers E.g.
   config.fctGetDeviceConfig(config.configHandle,&devices);

The function "fctGetDeviceConfig" is not exposed as an entry-point in the dll. It isn't listed in the CLFN in LabVIEW.

So how would I call those functions from LabVIEW?

[rolfk]

Ahh, object pointers with dispatch pointer tables is a very nasty beast to tackle. It's even so bad that you can not rely on a specific memory layout between different compilers and sometimes even different versions of the same compiler!

So no, sorry. For C++ objects you have to use a C++ compiler and generally the same that created the according import libraries.

Even if those function pointers were declared as elements in a standard C struct, my library does not support calling function pointers, only accessing data elements in structures. Trying to do that would require quite a bit more work with a dynamic FFI (Foreign Function Interface). That's pretty tricky to handle without some assembly code.

[TroyK]

Thank you for confirming Rolf.  I’m glad it’s not just due to my limited understanding.

[seoulcorea]

Hello. I am currently trying to use the VN5614 with LabVIEW. It seems that this model can only be programmed in network access mode. Should I understand that vxlapi.dll cannot be used in LabVIEW in network access mode?

[rolfk]

---

@seoulcorea wrote:

Hello. I am currently trying to use the VN5614 with LabVIEW. It seems that this model can only be programmed in network access mode. Should I understand that vxlapi.dll cannot be used in LabVIEW in network access mode?

---

It depends what you mean by this. If you try to use the old channel based API for which there are existing LabVIEW driver wrappers already, it seems that this indeed would not work since the channel based API does not seem to support the newest hardware.

It's of course possible to interface to vxlapi.dll from LabVIEW but for the network based API not through pure Call Library Node interfacing. Someone will need to create a wrapper DLL that translates the function pointer based network API into standard functions that can be called through the Call Library Node. I have never looked at the vxlapi.dll myself and can not judge how much work that would be. But even if it is straight forward, I would expect it to be quite a few days to get something fairly clean and proper working.

And even if it would be possible to interface to that API through Call Library Nodes alone, it would be generally more troublesome and error prone to do so than it would be to create that wrapper library.