vector xl driver: labview wrapper

[lbounds]

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!

[lbounds]

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

[Hooovahh]

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

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

Where it is discussed, or even here:

http://forums.ni.com/t5/Automotive-and-Embedded-Networks/bd-p/30

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.

[Hooovahh]

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.

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

[lbounds]

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!

[lbounds]

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

[Hooovahh]

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.

[lbounds]

Ha yes, of course...day 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.

Thanks!

[lbounds]

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

[TroyK]

(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

0x80000000

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.

- NI-CAN ONLY -

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