Example Code

Vector XL Driver - LabVIEW wrappers

Code and Documents

Attachment

Description

VectorHW.pngOverview

Vector provides an API for performing low level control of their hardware.  The code posted here is primarily wrappers around their XL Driver APIs.  These functions come in the form of the vxlapi.dll, and vxlapi64.dll.

 

Description

Vector has some very nice products for testing vehicle communication buses such as CAN, LIN, MOST and FlexRay.

They sell some very expensive software and some reasonably priced hardware to go along with it.

You can buy just the unlicenced hardware and use the freely available driver that comes along with it in your own custom applications.

 

Requirements

Vector XL series hardware or VN series hardware and drivers installed.  This includes the older CANCase and newer VN16xx USB devices.

Windows Device Driver for the Vector hardware. Check if your device is recognized in Windows Device Manager.

LabVIEW 2018 or later for version 3.

Driver dll Download

The required DLLs are included in the version 3 zip.  For those that don't the instructions below are for acquiring these drivers.

 

To get the dll and driver go to the Vector download page and download it. Just be sure to choose the right options when finding the XL Driver Library containing the dll.

 

IGNORE THE LABVIEW DRIVER! It is quite restrictive, and requires a rather expensive license. 

From the download page select: XL Driver Library > Drivers & Firmware > All

Now click the button that says "Show Results...". You should now have a list of drivers available. Again, ignore the LabVIEW one. Download the XL Driver Library X.X.

 

Unfortunately the header file supplied with the driver dll doesn't readily import into LabVIEW. We had to make some significant modifications to it before it worked. Then I had to go through and make quite a number of corrections once it was done.

If you're curious the modified header file is called vxlapi3.h.

 

 

Here I just provide wrappers and an example or two to get you started. Below is one simple example of transmitting a CAN frame.

Version 3 Changes

Hooovahh has made several changes based on user feedback, and released it as Version 3.  The two main improvements to this version is to support CAN-FD reading and writing, and to support 64-bit LabVIEW as well.  A more clean example also allows for simple reading and writing of frames, along with reading analog and digital values on hardware that supports it.  

Version 3 Examples

 

 

Other Examples 

TransmitExample.png

 

The "Basic LIN test.vi" assumes you are using the LIN channel to monitor a running LIN connection. It works as a silent slave node on the network.

To actually receive any LIN frames there must already be a LIN master communicating with another LIN slave.

Basic LIN Test.pngVI in attached zip file.

 

"Simulate LIN network.vi" will transmit from one LIN channel set up as a Master node to other LIN channels set up to respond as Slave nodes.

There is now also a "Simulate LIN network -master transmit.vi" which allows you to transmit data from a Master to Slaves. (Remember that a master node MUST HAVE A PULL-UP!)

SimulateLINnetwork.png

CAN Receive example added due to popular demand (updated with documentation and code tidy):

CANReceiveExample.png

All example VIs and dependencies should now be contained in this latest zip file.

 

If you find any bugs or updates needed feel free to send me a message.

If you have a support request please post it in the LabVIEW Forum, NOT HERE.  I will get a notification and reply in the forum if you add vxlapi as a tag.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument

Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.

Comments
kai_n2
Member
Member
on

I started using this in the meantime, most things are working really great!

But unfortunately I had to switch to Windows 7 64 bit lately. I was able to change all dll calles to vxlap64.dll but the my_vxlapi is unavailable to me because it is 32 bit. Might it be possible to compile a 64 bit version of it?

Thank you very much,

Kai

TroyK
Active Participant
Active Participant
on

I will look into compiling a 64bit version of my_vxlapi.dll but I can't do it right now.

I am using the existing version on W7 64bit now and it works fine. I'm just not using vxlapi64.dll with it.

EDIT: my_vxlapi.dll is redundant. Function is now properly implemented in LabVIEW.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
YogeshShivarudrappa
Member
Member
on

Hi,

I just downloaded and ran the VI , with CAN caseXL connected to my laptop. I get the following error.

ransmit Example.vi<ERR>
vector xl driver error 101 XL_ERR_WRONG_PARAMETER


<b>Complete call chain:</b>
     Transmit Example.vi

Can you please help me with thiss issue. My can caseXL hw is in 2nd position in Vector Hardware.

Thanks,

Yogesh

TroyK
Active Participant
Active Participant
on

According to the XL Driver Library documentation Error 101 means "At least one parameter passed to the driver was wrong or invalid."

Did you change the hwType, hwIndex and hwChannel to match your hardware setup?

The example assumes you have 1 CANcaseXL plugged in with a CAN piggy in channel 1. If this does not match your setup then change those values to suit.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
YogeshShivarudrappa
Member
Member
on

Hi TroyK,

Yes, I have only 1 CANcaseXL connected and two can piggies in CH1 and CH2.

Capture.PNG

so,

hwType == CANCASEXL

hwIndex = 1 (shown 2nd in Vector hardware)

hwChannel = 0 ( selecting channel 1)

Are the above configuration correct, if not, please correct me.

Thanks,

Yogesh

TroyK
Active Participant
Active Participant
on

Each hardware type starts at 0.

Even though you have a Virtual CAN Bus that appears first, the CANcaseXL is a different hardware type, so it's hwIndex will be 0.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
YogeshShivarudrappa
Member
Member
on

Hi TroyK,

Thanks for the response.

Now its working fine for me. But, when I try to transmit an extended ID, I getting the invalid parameters error message.

I have set the idRange = XTD while setting the shannel acceptance.

Can you help me with this.

Thanks,

Yogesh

kai_n2
Member
Member
on

Hello again,

I am using LV64bits, which enlarges my problem: It refuses to use 32 bit librarys.

Did you have some time to compile as 64 bit library?

Thank you,

Kai

TroyK
Active Participant
Active Participant
on

Hello Kai, I couldn't find my original code for the wrapper dll so I would have to redo it and test that before I could then compile and test a 64 bit version. I have very lttle experience compiling C dlls and not a lot of spare time to fumble my way through it again.

Apparently there is a way to get it working just in LabVIEW but I could never figure it out. Perhaps someone else would have more luck.

In this thread one developer claims to have done it but did not post his solution.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
kai_n2
Member
Member
on

I played around a bit with this stuff. As soon as I found out the length in bytes of the written data of xlGetDriverConfig Labview was no longer crashing when calling the function. I used a lot of your code, the only change necessary is reversing the byte order for everything larger than 1 byte. Now the code is ugly but works without calling a wrapper.

Thanks for your great work, with this missing function added everything is perfect for me!!!

xlGedDriverConfigSnippet.png

TroyK
Active Participant
Active Participant
on

Kai, that is almost exactly what I was attempting to do but mine wasn't working. I finally realized what I was doing wrong.

I had the call library function set to 'C' calling convention instead of 'stdcall'. Now it works! (Don't I feel silly.)

Thanks for your help!

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
kai_n2
Member
Member
on

This is even better, this way I do not need to change anything if you update this great tool!

TroyK
Active Participant
Active Participant
on

It's been updated. Vector XL LV2011 v2.zip

v2 = includes fixed xlGetDriverConfig function

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
Azby
Member
Member
on

Well done!!! Two years ago, I made my best to make my HW_CAN work and it worked, but I always felt that my VIs were not enough good to anyone. Early this year I saw your comment in my post and i got curius, but had no time, but now there is a new project and I have to develop some SW/HW for it so...

I've just looked your VIs and they seems to be nice. I'll try it. specially because I'd need the DriverConfiguration VI, which I never develop, maybe I could now automate the process I left before and make them more reliable.

 

Well, thanks again for this sharing and keep doing nice things!!

Regards.

Hooovahh
Proven Zealot Proven Zealot
Proven Zealot
on

Very cool awesome work.  I couldn't help but notice I can transmit but not receive?  Is the DLL capable of doing a receive on CAN?  And regarding the transmit is it possible to have a hardware timed transmit?  Say if we wanted to transmit every 10ms is our only option with the API be to call the transmit every 10ms?  Or does the DLL support a retransmit of a message?  Thanks.

EDIT: Never mind about the receive I'm an idiot.  It isn't under the CAN section because it isn't CAN specific it is under VIs called xl Receive

TroyK
Active Participant
Active Participant
on

Thanks Hooovahh, yes you can receive (as you have discovered).

I don't think there is a hardware timed re-transmit, although this would be very handy for cyclic messages.

I believe Vector does make some hardware capable of doing this but I haven't seen it exposed in the vxlapi api.

I must admit that I haven't looked too deeply into it. If I'm wrong I'm happy to be corrected.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
Hooovahh
Proven Zealot Proven Zealot
Proven Zealot
on

Okay I found 2 bugs both quite minor and I'm not sure one is even your fault. 

First, in the xlOpenPort command you tell it the size of the rxQueue.  I set this to 100, then wrote on the bus over 150 messages.  As expected I only got 100 and the other 50 were lost because the queue was too small.  But what was strange is the XL Status returned Success, instead of XL_ERR_QUEUE_IS_FULL.  I added some code to detect if the number of messages read were equal to the buffer size and if so to set that error.

Second, using your CAN Transmit there is no way to write a message that is in the extended format, but be 0x7FF or less.  If the ArbID is greater then 0x7FF it must be extended, but if it is less then that it can be extended or not.  To fix this I added code to set the appropriate bit inside the Data 3 byte to tell the transceiver to write it as extended or not.

I also was not able to find any information on retransmitting CAN messages using this library.  Maybe that is what you get when you pay for the LabVIEW API Vector has developed.

TroyK
Active Participant
Active Participant
on
"     .. size of the rxQueue..set this to 100, then wrote on the bus over 150 messages... the XL Status returned Success, instead of XL_ERR_QUEUE_IS_FULL."

Yep, that sounds like a bug with the driver. Not much I can do about that with the wrapper VIs.

"     there is no way to write a message that is in the extended format, but be 0x7FF or less."

The arbitration ID is a U32, the CAN protocol uses 11 for standard ID or 29 bits for ectended, BUT the vector CAN vxlapi driver uses bit 32 of the arbitration ID value to determine if the message is extended. So, 0x000007FF will be standard ID, 0x800007FF will be 0x7FF as an extended ID message.

NOTE: NI CAN uses bit 30 to indicate an extended ID message.


"      retransmitting CAN messages using this library...  Maybe that is what you get when you pay for the LabVIEW API Vector has developed."

I've downloaded Vector's LabVIEW API. It was extremely basic. It didn't work because I didn't have a license, but there were very few functions exposed. If someone has used it I would love to hear about it.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
nibo
Member
Member
on

Hello TroyK

I create period message seding mode, your structure is very perfect.

Do you have some examples for receive module?

pengine1
Member
Member
on

Hello TroyK,

is it possible to safe the VIs for an older LabView Version? Or does the wrapper require LabView 2011. I only have LabView 2010.

http://zone.ni.com/reference/de-XX/help/371361H-0113/lvupgrade/upgrading_from_previous_version/

Regards

Markus

TroyK
Active Participant
Active Participant
on

Hi Markus,

I don't think there's any reason the wrapper VIs shouldn't work.

The example VIs may have an issue, I'm not sure.

Vector XL 2010.zip

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
TroyK
Active Participant
Active Participant
on

nibo wrote: Do you have some examples for receive module?


                   

The "Simulate LIN network.vi" shows how you can receive LIN type XL Events. It is almost identical for receiving CAN type XL Events.

It should be noted that there is a bug in the vxlapi.dll for receiving LIN type XL Events.

For CAN XL events you can read multiple XL Events from the buffer in a single read.

However for LIN XL events you can only read one at a time.

Consult the "XL Driver Library - Description.pdf" api document for instructions.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
pengine1
Member
Member
on

Thank you very much for your fast reply.

Works fine for me now with LabView 2010 SP 1.

Ricky282
Member
Member
on

Hi ToryK:

I tried you provided VI on CAN communication, Most of them are working fine. Just having one question on CAN receive message function. In original Vector manual , the receive function should use Set Notification to create thread for trig messgae ready. Then received message.

But I thought this kind of method can't work in LV. So I just tried use XL Receive.VI to get message and it seems work. But the problem is message feed to Get Event String.VI will trsnalste as wrong data. But the raw tag data is correct. Do you have anu idea on this kind of issue ?

1.PNG2.PNG

TroyK
Active Participant
Active Participant
on

The receive function can use Set Notification but it doesn't have to.

You can use Kernel32.dll WaitForSingleObject() to get the notification.

I have used it for CCP and UDS when I only want to receive a response, not monitor all messages.

Otherwise you can just poll for messages in the receive buffer (similar to what you are doing).

The method you are using to get messages will fail if less than 2 messages are available in the buffer. If only one xlEvent is present the function will output an error and you will discard the xlEvent. If you are going to poll for messages you should use the xlGetReceiveQueueLevel function to check if messages are available before reading them from the buffer.

Tag Data: I never use the xlGetEventString function. Maybe it has a problem?

I use "VXLAPI-Convert_Data_To-s_xl_can_msg.vi" which I wrote to extract CAN tag data.

You are also assuming that all xlEvents received will actually be CAN type events. xlReceive will also receive error frames, chipstate events etc etc. Perhaps the message you are receiving is not a CAN event but contains old (seemingly valid) data. But maybe the string would reflect that? I don't know.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
Ricky282
Member
Member
on

HI TroyK:

Thanks for your replied ! Maybe the GetEventString had problem. I will try to find the root cause.

Your message is useful to me.

Ozfarmboy
Active Participant Active Participant
Active Participant
on

Ricky282,

If you use xl CAN Set Receive Mode.vi when you are initialising the port, you can suppress the Chip State and Error Frame events.

Cheers

Chris

Christopher Farmer

Certified LabVIEW Architect
DQMH Trusted Advisor
http://wiredinsoftware.com.au

I'm Speaking at the GLA Summit!

Ozfarmboy
Active Participant Active Participant
Active Participant
on

TroyK,

Yes - this is Chris Farmer - formerly CPE Systems!  Long time no speak!

Appreciate your effort with this library - I have downloaded it and trying to apply it for some applications here at SWSA. We have a very crude driver here to communicate with VXLAPI, but it's buggy and limited.  I am in the process of re-writing it, and using your library as a basis. 

It's ambitious, but I am integrating the Automotive Diagnostic Command Set with it too.

Cheers

Chris

Christopher Farmer

Certified LabVIEW Architect
DQMH Trusted Advisor
http://wiredinsoftware.com.au

I'm Speaking at the GLA Summit!

TroyK
Active Participant
Active Participant
on

Hi Chris, I recognized you from your skiing photo.

Congrats on getting the job at SWSA, say Hi to Vince T. for me.

Which Automotive Diagnostic Command Set are you implementing?

I've already done UDS on CAN (ISO 14229) with candela file import. It works well.

I don't think you'll have any problems.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
Ozfarmboy
Active Participant Active Participant
Active Participant
on

Hi Troy,

Vince says hi!

Yes, I have tried out your Candela File Import application too!

For the past few year, I created a CAN driver for our applications here that sat above the NI-CAN driver (using Frame API, but also utilising a bit of the Channel API and Frame to Channel Conversion libs to make good use of the NI CAN DBs).

A few things I've found that the Vector XL Driver Library DLL lacks that the NI CAN driver has built in:

  1. Setting the Receive Queues to "0", which means you always just get the latest CAN message for the given object (message).
  2. Setting up periodic transmissions is as simple as calling CAN Write.vi once, with data and period, and then the driver takes care of the periodic transmissions.
  3. Setting up an object to be either receive or transmit, so basically you can create an object for every message ID.

Not major things, just more programming for us to have these features in our applications.

Thanks again!

Chris

Christopher Farmer

Certified LabVIEW Architect
DQMH Trusted Advisor
http://wiredinsoftware.com.au

I'm Speaking at the GLA Summit!

Ozfarmboy
Active Participant Active Participant
Active Participant
on

Oh and I'm just using the ISO-TP Normal Mode in the ADCS, but with modifications - some service numbers have changed since the version of ADCS we have was made.

Christopher Farmer

Certified LabVIEW Architect
DQMH Trusted Advisor
http://wiredinsoftware.com.au

I'm Speaking at the GLA Summit!

TroyK
Active Participant
Active Participant
on

We've only ever needed to use Normal Mode so far too. I've allowed provision for other modes but not tested them.

That candela parser version is now quite old. I've since removed a bug or two, added compatibility for newer candela file versions and upgraded it to use libxml.

Libxml made it at least 30x faster.

I don't think i'll keep updating the candela example though. I'm probably already giving too much away to competitors!

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
Ricky282
Member
Member
on

Hi Chris:

I am not sure the problem is caused by error frame or chip state. Because I checked 32 raw data (tagData) are correct, like ID (extended ID) , DLC and received data. But translate the data from XLReceive.vi by GetEventString, the ID , DLC and received data are wrong.

But anyway, I tried Troy mentioned VI still can get correct data. Just GetEventString is not.

TroyK
Active Participant
Active Participant
on

Hi Ricky282,

There was a bug in the way the data is passed to the dll for the GetEventString.

The dll needs the cluster to be flattened before it will process it correctly.

I've fixed it and uploaded the updated libraries. Should work now.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
sallesa
Member
Member
on

Hello,

Thank you for this tuto. It is very helpful.

On my side, I am working on LIN bus through a VN1611 USB device.

.NET DLL is also working fine with .NET palette.


I have a major concern about transmitting data.

I cannot find a function able to send data (not only a request) from VN1611 to a given slave.

Am I wrong ?

TroyK
Active Participant
Active Participant
on

Hello sallesa,

I have not used LIN as master to  send data to slaves, only to get data from them.

The xlLinSetSlave function description in the XL Driver Library document states:

"This function is also used to setup a slave task within a master node."

Vector's "LIN protocol reference chart" also states that a response can be sent by a slave or a master.

So I guess you set the master node to respond to it's own request header. Then any slave nodes listening will be able to get the data when you use xlLinSendRequest.

So try this:

1. Use xlLinSetSlave on the master node to set a  slave task to fill in the data you wish to send,

2. After the channel is activated, use xlLinSendRequest with the ID you wish to transmit,

The slave task in the master node will fill in the data after the request ID header comes out, effectively transmitting data to slaves.

The data can then be changed the same way it would be for any other slave task.

Please let me know if this works.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
solutions
Member
Member
on

Hi,

I am using the transmit example with some modification for CAN transmit and receive in LabVIEW 2013 using vector CAN CaseXL. I need that vi in LV 7.1 so that i have convert it to 7.1

But I got some wire loose ends which is connected with call library function. I have remove and delete that loose ends. while i save that vi, i got the error message as complier error.  May i know what is the reason for that error comes,

Can you please help me to resolve the error.

Also i have attached the snap of that errors.

compiler error.png

TroyK
Active Participant
Active Participant
on

The problem you're having seems to be related to the down conversion to LabVIEW 7.1.

It appears to have broken at least some of the call library function nodes.

The earliest version I can save back to is 8.0 and even when I fixed the broken wires it resulted in a memory corruption error.

[Edit] The down-conversion seems to modify the array type parameter definitions in the Call Library Function Nodes. It seems to be ticking all the 'constant' checkboxes in function prototype parameters for array types. This causes the memory corruption.

To get it to work after saving to LabVIEW version 8 or earlier you will need to:

(A) Reconnect all the broken wires and

(B) Open all the CLFNs and untick the 'constant' checkboxes set on any parameters.

     You will be able to see quickly if any of the parameters have been set to 'constant' by observing the function prototype definition.

E.g. int16_t _xlReceive@12(int32_t portHandle, uint32_t *pEventCount, const void *pEvents);

Notice const in the function prototype, it needs to be changed.


Please ask support questions in the LabVIEW forum, not here in document comments.

Add vxlapi as a tag and I automatically get a notification. (This instruction is in big bold red letters above.)

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
solutions
Member
Member
on

Hi,

Thanks for your reply. I have close the issue by reconfigure all call library nodes. But i'm getting the errors which mentioned below when i execute the example in LV 7.1 in windows xp system. kindly help me to resolve this error.

2014-07-03_17.34.25.jpg execute

Munna232
Active Participant
Active Participant
on

Dear TroyK,

Thanks for your great work . It is very helpful.

I need small help. Please help me.

I want to monitor all CAN messages & display it one LabVIEW (like ur LIN example).

LIN.png

I saw XL Receive.vi. It seems OK but I don’t know about “pEventCount” value.

How to set this Value. I want to display all message on Front panel.

https://decibel.ni.com/content/servlet/JiveServlet/showImage/105-35225-175461/2.PNG

Could please suggest me any idea/snippet about this.

BR,

Munna

Munna
Antonino27
Member
Member
on

Hi thanks for your job but i cannot start because when i tryed to make the library from the two files vxlapi.dll and vxlapi.h i'm not able to recover all the vi.

Can you please help me?

Can you send to me the right files or better the library vith the vi .

Thanks

Immagine.png

TroyK
Active Participant
Active Participant
on

Hi Antonino,

As I stated in my document:

Unfortunately the header file supplied with the driver dll doesn't readily import into LabVIEW. We had to make some significant modifications to it before it worked. Then I had to go through and make quite a number of corrections once it was done. ..

If you're curious the modified header file is called vxlapi3.h.


                   

That's why you're having trouble trying to do the import yourself.

All these wrappers that you're trying to recreate are already in the "Vector XL LV2011 v2.zip" file attached above. The work is done for you.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
rdolson
Member
Member
on

I have been struggling to get the J1708 bustype to work with your CAN recieve example. I do not see any documentation unique to 1708 on vector's website. Have you done any work on this? I do see in your example the option for 1708, a baud rate control (which i have set to 9600 bit/s), changed the rxQueuesize, etc. but was unable to get it to work. I was able to get CAN 1939 piggi to work with your code. Any direction you could give towards this problem would be appreciated.

Thank you.

TroyK
Active Participant
Active Participant
on

Other than it being selectable as a bus type, I don't know anything about J1708. I have used J1939, but that is basically CAN. J1708 seems to be more like a RS232 style physical layers so the CAN functions in the API likely will not work.  As you have noted, there are no examples or even a mention of J1708 in the API documentation, only in the header file. I think you may need to contact Vector with your enquiry via their support portal.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
rdolson
Member
Member
on

Troy,

Unfortunately vector is telling me ...they will provide support to their purchased software. They are not as forthcoming with the 1708 hardware commands as they were with API. After more research it looks like Dearborn Group provides a command interface to one of their adaptors(DPA 3 industrial). Thanks for the confirmation.

michi1988
Member
Member
on

Hi,

i have a problem with the can_transmitter.vi.

I always get the vector xl drive error 101. For CAN-communication is the Vector VN 1610 interface used.

At the pictures you can see my vector configuration an the can_transmitter.vi configuration.

It will be very great if somebody can help me to find the error.

Thank you!

fehler_ni.jpgvector_config.jpg

kurtus_h
Member
Member
on

Hi,

We are using the example vi to read and write data on the CAN bus, but the identifiers that we have are for extended CAN.  When we try to use the example vi, it reads the data normally when in "STD" mode but when we change to the "EXT" extended mode it does not work.  It gives an error: CAN Receive example.vi,ERR> vector xl driver error 255 XL_ERROR.  (Code d 6255).  Has anyone seen this issue or know what the problem is?

Thank you!

TroyK
Active Participant
Active Participant
on

michi1988

That error code text says "At least one parameter passed to the driver was wrong or invalid."

Do you have 3 VN1610 devices plugged in and you are trying to address the third one?

You are selecting hwIndex 2. If you only have one VN1610 plugged in it is hwIndex 0.

I believe the answer to your problem was already posted 18 months ago here.

kurtus_h

I believe there is something else wrong than just changing to extended ID. 255 XL_ERROR means the driver doesn't know what went wrong. When this error appears (mostly during development) I unplug the hardware and plug it back in again to fully reinitialize the driver. I can assure you that both STD and EXT CAN settings work properly. If you have modified the code and there is something wrong with it you will have to attach it.

I would appreciate it if support requests were posted to the LabVIEW Forum rather than here in the document comments section. As I state in the document above:

If you have a support request please post it in the LabVIEW Forum, NOT HERE.  I will get a notification and reply in the forum if you add vxlapi as a tag.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
kurtus_h
Member
Member
on

Hello TroyK,

I will give that a try- thank you for the reply / sorry for posting in the wrong location!

michi1988
Member
Member
on

TroyK

Thank you for your answer, i solved this problem and it works very fine.

But i had a new problem.

I would like to combine the receive.vi and the transmitt.vi in one single .vi.

This .vi should be able to receive and transmitt can message in parallel. I dont't know how i can

combine this because the vxlapi can transmitt make a lot of problemes if i implement this in the

receive.vi.

Can sombody please help me with this problem or had somebody a complete .vi with this

features? I think it should be possible to receive and send in one .vi. OR not?

Best regards!

Mike

Contributors