vxlapi : Vector Driver Error (Invalid Access)

[westerf]

Hello,

Preface: 

I was looking to tag this question to vxlapi so the original author of the labVIEW wrapper could see it easier, but I did not see an option to add a tag. Could anyone help out with getting this post to the right place?

I am hoping someone can potentially give me insight on the problem I am having with Hooovahh's Vector CAN Labview Wrapper drivers for the XL library. I am currently encountering an error message as soon as my session travels through the "CAN Set Channel Bitrate.vi". The error message tells me: 

<ERR>
vector xl driver error 112XL_ERR_INVALID_ACCESS

<b>Complete call chain:</b>

I have evaluated my Vector hardware manager and it appears that my device is detected and the program is selecting the correct HW index and HW channel; nevertheless, an error is generated. I attached a screenshot of my front panel data output and hardware manager info just in case someone spots something off. 

I also attached my VI below as well if that is easier to take a look at than just pictures. I was just setting up a simple program that can receive CAN data from the hardware. Let me know if anyone has any ideas as to the problem and anything else I can provide to help.

Thanks!

[TroyK · Accepted solution]

I'm guessing from the "VectorDeviceManager" screenshot that there are multiple sessions open or you haven't been closing the port in previous runs.  That's why there is user.1 user.2 user.3 etc.

Only the first application to open a port gets "init" access and can set things like the bitrate.

Any subsequent apps who wish to access a channel have to trust the the first app opened the port using the correct parameters and NOT try to also set the bitrate, otherwise you get the invalid access message.

(Have a look at the flow chart in section 4.2 of the XL Driver Library, it shows the difference of what can and can't be done if you don't have init access. Search for Init access in the doc.)

Physically unplug the hardware (will force old sessions to terminate and reset the hardware), plug it back in, then try again. Make sure your code closes the port handle at the end!

[westerf]

Ah, that would make sense. I was running the code over and over in the highlight execution mode and was force stopping the program to save time. I will wait for program completion from now on. Thanks!