Showing results for 
Search instead for 
Did you mean: 

vector xl driver: labview wrapper

So...if I open and run the Transmit Example leaving everything default, it goes through with no errors. However, if I change the ID to 14FF0021 (which is the message I need-if I send it through Canalyzer it works like it should) I get the following error:


vector xl driver error 101 XL_ERR_WRONG_PARAMETER


I'm really new to CAN so I'm guessing/hoping it's something pretty obvious that someone with a little more experience can help me with.


Appreciate any help!



0 Kudos
Message 1 of 29

It errors out when it goes through the xl Can Transmit vi if that helps at all...also, I'm using CANCaseXl, index and channel =0, baud is 125k

0 Kudos
Message 2 of 29

You may want to post issues with this DLL wrapper either here:


Where it is discussed, or even here:


Which specifically talks about CAN.


That being said one issue you might be having is the fact that your ID is an exteneded on (using more than 11 bits) so you may need to tell the transmit that the message uses extended message type.  I believe there is a boolean that needs to be true.

0 Kudos
Message 3 of 29

Oh and if you are looking for an overview of CAN and XNET in LabVIEW checkout this presentation I did.  Might not be as useful as someone talking throught the points but still might get your feet wet.

0 Kudos
Message 4 of 29

Thanks for the reply, I get the same error with extended selected as well...sorry, forgot to mention that. I will definitely check out the presentation!

0 Kudos
Message 5 of 29

still trying to dig into the problem...would it matter to the code that I'm using a 64 bit OS?

0 Kudos
Message 6 of 29

You said it worked with the default values, so I'm guessing this isn't a wrapper or DLL problem, but a how you are using it problem.

0 Kudos
Message 7 of 29

Ha yes, of two of trying to get LabView to talk with this CANcaseXL and everything is starting to run together. Still think this is my best option right now but I'm running short on new ideas.



0 Kudos
Message 8 of 29

When I transmit 14FF0021x through CANalyzer I get the response I want (I found that message through CAN captures in the field as well)...when I use the CAN Receive Example I'm finding that the messages I get back through the vi are exactly the same as what I was getting from the CAN captures except that the first digit is a 9 instead of a 1 (so say instead of 14FF0021 I actually get 94FF0021)...I'm starting to think my lack of CAN knowledge is at the heart of my problem, but why would the ID's be different? I tried to transmit my original message with a leading 9 instead of a 1 with no luck

0 Kudos
Message 9 of 29

(Answer copied from here)


Standard IDs are 11bit.

0xxxxx111 11111111

0x7FF (max possible standard ID according to the CAN protocol.)


Extended IDs are 29bit.

0bxxx11111 11111111 11111111 11111111

0x1FFFFFFF (max possible extended ID according to the CAN protocol.)


The vxlapi driver uses the 32nd bit in the U32 for the ID to indicate that the CAN message is extended.

0b1xx00000 00000000 00000000 00000000



So to send a valid extended ID out of the xvlapi.dll you need to bitwise OR your ID with 0x80000000.


0x8000000 (OR) 0x14FF0021 = 0x94FF0021


If you like this can be masked out upon reception by ANDing the ID with 0x1FFFFFFF.


Trying to send 0x14FF0021 gives an error because the Extended flag bit is not set but the ID is outside the Standard ID range.



Just to make things more confusing, if you're using the old NI-CAN hardware, they use the 30th bit to indicate an extended CAN message. (I'm not sure about the new XNET series hardware.)

So for the older NI-CAN hardware you would need to bitwise OR the extended ID with 0x20000000

The ID for NI-CAN would then be:

0x2000000 (OR) 0x08FF8201 = 0x28FF8201

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