XNET Clear bug?

[Madottati]

I use XNET CAN to communicate on 8 CAN interfaces parallel. 

Once I call the XNET Clear.vi on an interface, some other interfaces loose communication and I see error frames. 

Has anyone experienced this kind of behavior? 

I tried to remove XNET Clear.vi from my code, now the sessions will only be stopped by XNET Stop.vi (normal mode), but I still have issues. 

If I run my code on only one CAN interface at a time, there is no failure. 

My version is XNET 20.5. 

[Hooovahh]

I have experienced a bug similar to this, and last I knew it was still there.  For me the issue was seen on setups where I was using CAN-FD, and multiple interfaces in parallel, using reentrant VIs to do some work in parallel.  Somehow the compiler would get confused and would try using the wrong reference to the wrong instance of a VI, and it would result in an Access Violation on Windows, and a hard crash on RT.

For me the temporary solution (which has been in place for over a year now) was to wrap the XNet function into a non reentrant VI, and call that instead of the XNet one.  This forced the function to happen one at a time.  My issue was seen on the XNet Read, which I didn't want to be serialized, so I ended up making like 20 non reentrant VIs, and then call each one depending on the interface used (CAN 1 would always use the first copy, CAN 2 would always use the second, etc).

I'm not sure this is the same issue as you are seeing, but as a test I would put the Clear function in a subVI that is non-reentrant, then replace all the calls to the clear, with your VI and see if it works better.  My issue was attached to service request 3301015, giving a bug report number of 988852.

[ahovhann]

Hi.

Can you share the error code part?