RT XNET Bus Off Recover

[kevin.key]

Hey,

I've got a seemingly inexplicable situation here, and I'm hoping someone knows the answer or has a good tip for how to debug the problem. The problem is recovering from a Bus Off condition in XNET. I'm using this VI:

The crazy thing is this VI only works if I have the Print Debug String in the Bus Off case where I stop and start the interface. If I remove the Print Debug String the XNET interface will not recover from a Bus Off state.

Thanks,

Kevin Key

[T-REX$]

Hi Kevin,

What is happening inside that Print Debug VI? It's not in the XNET palette... Do you know who made it?

[kevin.key]

Not sure who made it, I got it from the NI website though:

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

But I highly doubt it has any XNET api calls in it.

[T-REX$]

Hi Kevin,

Well, I didn't expect the VI to be password locked, so there goes that. Have you tried just putting a wait of a few milliseconds in there instead? Maybe the print debug call is just introducing a delay into the loop. I also see that it is a NI Veristand VI. I'm going to ask around internally and see if any of our Veristand experts know what exactly is inside this VI.

[kevin.key]

I've tried just adding a ms wait to the vi instead of the print debug call, and I couldn't get it to work. It still seems to work reliably with the print debug string.

[T-REX$]

Hi Kevin,

I've got a few more questions for you.

1) Have you tried switching to the RT print debug string? (Found in the RT pallette)

2) What is going on in the other case? Just passing throught the values? Try printing there as well to make sure it is running normally.

3) How did you verify the code works/doesn't work? Are you just killing the bus power and then trying to recover gracefully?

4) Finally, are you actually using NI Veristand?

[kevin.key]

1. I don't think the print debug string should have any effect on whether or not it recovers from bus off. Something else must be going on, somehow it's affecting the recovery. Is the method to recover from Bus Off with XNET to just stop and start the interface? Is there any affect on the recovery if at the same time in another thread an XNET Write vi is being executed on a session? Does it matter if that other session has Auto Start enabled?

2. Nothing just passing through. I've tried printing there as well.

3. I Think the code works. If I create a much simpler RT project with just labview, and fault the bus and executing the stop and start vi's when a bus off state is reached it recovers.

4. Yes, the vi is part of a custom device.

---------

A coworker of mine just let me know that he found with just the simpler version, if you run the recover vi in a loop executing at 1ms it doesn't recover, but if you run the recover vi in a loop at 50ms it does recover. Any ideas?

[T-REX$]

Hi Kevin,

In your case statement, try adding a flat sequence structure. In frame 1, stop the bus. In frame 2, wait 50ms, and in frame 3 restart the bus. Let us know if that affects the behavior at all...

[kevin.key]

I would've expected that to fix it in the same way it fixed the simpler version, but it doesn't recover

[Roryriffic]

Hi Kevin,

I also don't know what's going on inside that Print Debug String VI, but I agree it probably doesn't involve any XNET API calls. And what happens if instead of starting and stopping the interface, you change the scope to Normal or Session? In addition, if it's an option, you may try placing the XNET Flush vi between the Start and Stop VI's.  This would ensure that the queue is emptied when the bus starts again, but this may not be the functionality you intend, especially if you are writing to the queue in another thread somewhere.