From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

VeriStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Sharing CAN module between host and RT

I have a PXI-8513 2-port CAN module that is currently completely owned and operated by Veristand. I have a Diagnostics Custom Device that's a highly modified version of the one available from the GitHub repository, and things are working well using the CAN port through Veristand. For a variety of reasons, I do a lot of testing and debugging with a host-layer diagnostics interface that I've written, and I'd like to abandon the use of the Custom Device altogether. 

My problem is that I'm not sure if I can have one port of the 8513 remain dedicated for Veristand's use (which is an absolute must) and have the other available for use by the host-layer diagnostics interface.

 

Can anyone tell me if this is possible? If so, how to I go about allocating each port?

 

Thanks!

 

Wraith

0 Kudos
Message 1 of 7
(3,613 Views)

Accessing ports remotely (from your PC to an RT target) is possible with the newer bus monitor tool. 

http://digital.ni.com/public.nsf/allkb/92F10284E8061FB68625793600484D79

 

So that leads me to believe access ports remotely is possible. However... I don't know whether the monitoring tool is using LV functions or special functions that are not exposed in LV. I'm assuming your host-layer diagnostic tool is LV based?

 

Also... I don't know if there is a problem sharing ports on the same card between two systems. 

 

If you run your VeriStand app that uses the one port and leaves the other one open, can you use the Bus Monitor tool successfully on the other port? 

 

What about running a basic XNET CAN example VI that uses the other port while VeriStand is running? Does that work? 

 

Unfortunately I don't have the hardware to test this out myself but hopefully this is helpful 🙂

Tim A.
0 Kudos
Message 2 of 7
(3,587 Views)

I actually did this yesterday from MAX. I had a VS project deployed and running and was still able to open and use the Bus Monitor from MAX. The one concern I had was that it didn't appear that I could access/utilize all of the functions of the Bus Monitor, but I wrote that off to my inexperience with the tool itself.

Yes, my host-layer diagnostics application is written in LV, I'm using Network Streams to communicate with the VS Diagnostics Custom Device. I looked into a couple of XNET examples but had no success because I either couldn't select the CAN resource I wanted or the VI threw an error about the selected port not being a valid CAN interface.

 

I've opened a TSR about this issue and hopefully I'll get a positive answer. Whether the news is good or bad, I'll make every effort to post the results here.

0 Kudos
Message 3 of 7
(3,583 Views)

Unfortunately the remote CAN feature in the Bus Monitor is actually a network layer and only lies into the Bus Monitor library, and isn't currently public. The workaround of the network stream (or any other protocol)+custom device is amongst the best options, if not the best. I've also seen a CAN "gateway" being implemented using LV and deployed inside a web service running on the target. That allowed some LabVIEW code to run in parallel of VeriStand. The gateway job was to convert the local CAN data to network-enabled data.

Eric M. - Senior Software Engineer
Certified LabVIEW Architect - Certified LabVIEW Embedded Systems Developer - Certified LabWindows™/CVI Developer
Neosoft Technologies inc.

Message 4 of 7
(3,487 Views)

Eric - I didn't get into that level of detail as to why going the Bus Monitor route wouldn't work during my recent discussions with NI, but I did get that it wasn't going to work.

 

So, to sum up, using either the spare port on the 8513 or either port on an entirely separate 8513 I install in the PXIe chassis won't work. Since the Veristand RT exe is the only thing that can be running on the controller, it controls everything and I'm stuck using the method I've got right now. This isn't a bad thing, just inconvenient.

 

In all honesty, if I could just figure out how (or even IF) I can change the TX & RX IDs on the fly so I can access more than one ECU in a given VS project, I'd be just fine. I'd even be OK with having to use multiple instances of the Diagnostics CD in a project. I often have the need to utilize the diagnostic capabilities on multiple ECUs, but right now that means I have to stop, undeploy, select a different VS project, deploy and run it, perform the diagnostic action required, then repeat the whole process to go back to the original ECU. This is obviously not an ideal situation.

0 Kudos
Message 5 of 7
(3,476 Views)

Can you just throw a 1 slot cdaq with a 9862 on the bus and connect it via Ethernet to the same network switch as the PXI?

Stephen B
0 Kudos
Message 6 of 7
(3,465 Views)

I could, but since I have four essentially identical HIL systems I was hoping to be able to make the most of the existing hardware and not add any. Your suggestion (which is one I've considered previously), means obtaining four cDAQs and four 9862s, which isn't out of the question, but difficult given the way budgeting/purchasing works around here.

 

Any thoughts on changing the TX & RX IDs on the fly?

0 Kudos
Message 7 of 7
(3,455 Views)