I am sending this information on behalf Of kurtus_h who originally discussed this issue with You. Your response to him was:
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.
Kurtus has asked me to forward this information to you.
As you can see the “Receive” VI seems to be working correctly even though the idRange is “STD” If I switch To “EXT”, I get an error which is shown in the next example. The code has not been modified in either example.
See Images 1-3
With regard to the transmit example:
As you can see by the next two images, I modified the Baudrate from 250 to 500 K and I changed the id and message to something that is valid for my device. Everything else remained unchanged.
See Images 4-5
I then switched from “STD” to “EXT” with the following results: As you can see the error code is different. I am including the diagram to show that the only thing changed was “STD” to “EXT” along with the baud rate.
See Images 6-7
At this point I switched back to run the “receive” example and as you can see the “receive” no longer works.
See Image 8
After cycling of the power to the CANcaseXL it functions correctly.
See Image 9
Any assistance you can provide would be graeatly appreciated.
Solved! Go to Solution.
What version of the CANcaseXL driver and vxlapi.dll are you using? This behaviour looks like what you get with old drivers.
You can check the driver version in the Vector Hardware Config. A link to it will have been placed in your control panel during installation.
Vector Hardware Config > General Information > Support > Vector Hardware Config: Version ?.?.??
If your driver version is less than 8.3 then you need to update it.
Download and install the latest hardware drivers from here: https://vector.com/vi_downloadcenter_en.html
Select: Categories: Drivers & Firmware
Then click : "Show results". You should see the latest hardware driver in the list which is currently "Vector Driver Setup 9.0.1".
When you install or update the drivers you MUST run the Setup.exe supplied.
gmichaud wrote: At this point I switched back to run the “receive” example and as you can see the “receive” no longer works.
Once the hardware falls over you it won't recover until you reset it as you have noted "After cycling of the power to the CANcaseXL it functions correctly."
Updating hardware the drivers should fix it.
I have Vector Hardware config version 9.0.20 installed however there are multiple versions vxlapi.dll. This may be the problem. There are multiple copies of 2 different versions. do I need to delete them all and where should the latest version be installed?
See the attachment.
The vxlapi.dll being used is whichever one you copied into the wrapper top level directory. It should be the newest one you have.
CANcaseXL hardware also has a bootloader update for hardware purchased before 2011. Do you need to flash that update to the hardware?
I don't know what I am doing wrong. I made sure the dll is in the folder and I flashed the CANcaseXL. I powered the CANcaseXL down and back up again as instructed and I am still having the same issue. I noticed that your zip file lists LabView 2011 v2. I am actually using LabView 2013 with service pack 1 version 13.0.1f5 (32 bit). Is this posiibly an issue? I'm not sure where to go from here.
Please see the attachment.
Thanks for your assistance.
If you're trying to transmit an EXT ID CAN message then you're missing an 8 at the start.
8FF8201 should be...
88FF8201. Bit 31 tells the driver that it is an extended CAN message.
The LabVIEW version doesn't matter. As soon as you open it in 2013 it recompiles all the VIs to 2013.
I have used it in LabVIEW 2013 & 2014 with no problems.
I just tried to transmit the exact ID you are using in the picture, IT FAILS!
The ID is the problem. What you have as an ID is neither a valid STD or EXT ID.
Attached is a slightly more simplified version of the Transmit example VI.
Try try transmitting with either ID=0x201 or 0x88FF8201. They both work.
Thanks for helping.
I added an 8 at the beginning like you suggested and the error is gone. I'm not sure why but the documentation I have for the device I am testing lists the identifier as 0x08FF8201 and of course the leading 0 is dropped. Maybe there is a documentation error. In any case thankyou again.
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 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) 0x08FF8201 = 0x88FF8201
Your documentation is correct, it just doesn't account for the vxlapi requirement for extended ID.
- 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
I guess I am still not understanding something here. I will briefly try to explain what I am seeing and I will include another set of images and a pdf file that shows the commands that I can send. I also discussed this with Kurt who originally contacted you and I will include what he told me in response to the following email
I have been corresponding with TroyK on the vxlapi forum trying to resolve the issues with the LabView wrapper and the receive and transmit example Vis. I don’t know if you have had time to follow the thread or not but he told me that I was using an invalid id to communicate with our device. I was sending an 0x08FF8201 as the id. His software appears to strip off the leading 0 and sends 0x8FF8201. He states that this is neither valid for “EXT” or “STD”. He stated that we need to send an id of 0x88FF8201. His vi accepts this without error and everything seems happy LabView wise.
What I find odd is that his receive vi shows that the device is responding with an id of 0x88FF1082.
(This by the way appears to be a constant status that the device sends out)
See image 1
If I run the CANalyzer it shows that the device is responding with an id of 0x8FF1082.
See image 2
The device documentation says that an id of 0x08FF1082 is a valid actuator status. If I leave the CANalyzer running and use his transmit VI to transmit an id of 0x88FF8201. His VI then has an error.
See image 3
I assumed that the CANalyzer is passive and runs in the background but for some reason when it is running, it affects his transmit VI. There has to be something I am not understanding about how this is supposed to work.
I do not know if I fully can cover the issue, but it seems like it works fine with the maximum that it can handle which is 29 bits. If you go over that it should error out. 28 bits would be 7 hex digits. Thus a 29 bit number could at most be: $18FF1082. The highest character can only be a ‘1’. If you go even to a ‘2’ it is then a 30-bit number. That is invalid, so when you use $88FF1082 (a 32-bit number) this definitely would be invalid and should cause some error. I sure that you have seen many times the error presented does not correctly describe the actual error. The CAN driver software may strip extra bits away that are above what it can accept or maybe it inverts the order of the bits- if the number $8 (1000b) is inverted it would be $1 (0001b) which is a valid address. Troy would definitely be the best person to answer that, but it would be good to ask how it handles the device id if it is over 29-bits. The number he is using should not be valid, since it is over 29-bits. The addresses that we have are all 28 or 29-bits long.
I am also attaching the pdf containing the commands that the device recognizes
Thanks in advance for any and all help
I think my last post answers your question. I may have posted my answer while you were composing your last question.
If you transmit a CAN message with ID 0x88FF8201 from the vxlapi it will appear on the bus as an extended CAN message with an ID of 0x8FF8201.
If you transmit a CAN message with ID 0x80000001 from the vxlapi it will appear on the bus as an extended CAN message with an ID of 0x1.