PXI-8512/2 XNET CAN stops when bus errors occur on RT system

[h_yong]

Hello, I am using the PXI-8512/2 in an electrically noisy environment so I often get errors on the CAN bus. I notice that often the 8512 stops communicating as a result. In my dual port 8512/2, LED #4 which normally blinks ends up turning off. However, I do have other devices listening on the same bus; they report errors but continue to stay alive. Is there anyway I can have the 8512 continue working in the presence of errors? I'm using the XNET custom device for VeriStand 2009 and don't see any error handling options. In fact, I don't get any notification of errors at all. I just notice that my incoming CAN signals stop and my outgoing ones have no effect. Thanks.

[DiscoBall]

Hi Hyog,

Can you give more detail about the environment you are operating in? What is the CAN bus speed that you are operating at? Usually lowering the CAN bus speed can less the amount of errors occurring. Have you attempted to lessen the interference to the PXI-8512/2 by shielding the cables, or moving them away from noise sources?

If you have a monitor connected to the PXI controllers screen VeriStand should report errors of Custom Devices that cause them to fail. Do you see any such notification on the screen of the PXI?

You can check the state of the network using the NI XNET Read (CAN State Comm).vi (see logging errors section of NI Developer Zone Tutorial: Migrating NI-CAN Applications to NI-XNET and the attached screenshot. If you add this VI to the XNET RT VI in the Read State you can then add logic to judge if the XNET device is erroring out inappropriately (display data to screen, log to file, create channels for viewing with VeriStand). Can you let us know what the state of the bus is over time (error active to error passive to bus off)? Are the other devices on your network reporting the same state for the bus, or different states?

[O_Proulx]

Hi Hyog,

I would suggest trying the latest version of the custom device (fresh from today).  It has a new feature that you can enable that should automatically recover from bus off conditions.

Let me know if that resolves your issue.

[h_yong]

Hi O_Proulx, thanks for the updated XNET custom device. It looks like there have been many good changes. Does this mean, however, that I will have to, in System Explorer, delete my original XNET custom device, re-add this as a new custom device and then reselect all of my CAN channels and mappings? Or can I just put the two configuration and engine .llb's into the appropriate folder and benefit from the new features? I have multiple system definitions using this custom device, each with a lot of CAN channels, so I'd like to understand the amount of rework that this new version might require. Thanks.

[O_Proulx · Accepted solution]

Hello,

You should not have to delete your devices.  Just update the configuration and engine llbs and restart system explorer, save your configuration and redeploy.  Let me know if you see any problems.

(There are new files also copied to the custom device directory if you want to use the bus monitor feature...so you can overwrite the entire NI-XNET folder if that's easier).

[h_yong]

Hi,

Yes, this updated XNET driver allows me to contniue testing despite the CAN error frames that occur in my environment. I also did not have to delete and reinstall my XNET custom devices. I am looking forward to trying the new bus monitor as well. Thank you!

[h_yong]

Hi O_Proulx,

When I run in PC simulation mode, I get the following error:

Error -1074384758 occurred at _RT Engine v6.vi >> HP Loop.lvlib:HP Loop Main.vi >> HP Loop.lvlib:Initialize HP Loop.vi >> Custom Devices Storage.lvlib:Start Device (HW Interface).vi >> Custom Devices Storage.lvlib:Call Device by Reference (HW Interface).vi:5

Possible reason(s):

NI-XNET:  (Hex 0xBFF6308A) The interface name given does not specify a valid and existing interface. Solution: use a valid and existing interface. These can be obtained using the XNET Interface IO name, or using the interface properties of the XNET System property node.

For version the XNET custom device version 1.2 that I worked with earlier, I inserted a conditional disable to the error message as recommended by Joshua Buck. I did the same with version 1.5 but the same conditional disable did not seem to fix it. Are there any other locations where I need to conditionally disable to run in PC simulation mode?

Thanks.

[O_Proulx]

Hmmm...

Did you rebuild the engine after making the change in the source?  Are you sure it was rebuilt at the correct location?

I don't really see why you would want to ignore this error though.  If you do not have a valid CAN interface, the custom device is not very useful...

I'm guessing you still want to run the rest of your system definition on your PC, ignoring the XNET part.  Its easier to ignore this error than to delete the custom device and re-add it.  Am I seeing this correctly?

The only other location I can think of is in the TCP Stream to Host.vi.  This VI is launched asynchronisly if the streaming flag is set and could be throwing this error, but I don't think the custom device would stop.  

I hope this helps.

[h_yong]

Hi, I did rebuild the engine and placed it in the correct location. The reason why I'd like to ignore it in PC simulation mode is so that I can do workspace and stimulus profile type of development offline since my RT box is actually in a different city right now. Yes, it's easier for me to be able to ignore the error which I was hoping I would be able to do by placing the rebuilt engine and not touch the system explorer configuration. I do not have TCP streaming enabled for my XNET device. If you have any other ideas on what might be letting this error through, please let me know. Thanks.

[DiscoBall]

Hi hyog,

When do you see this error? Is it when you launch the Workspace or when you launch the bus monitor? Can you post a screenshot please? The conditional disable is to suppress errors when the custom device attempts to run on non-RT systems (i.e. PCs). It could be possible that the tag is misconfigured in the diagram disable...