Showing results for 
Search instead for 
Did you mean: 

NI-XNet Problems


Hello. I've been fiddling with this for some time now and can't seem to get this resolved. I'm quite new to LabView and completely new to CAN networks as well. Basically, I'm trying to get thermocouple data that is being carried on the CAN network into LabView for processing purposes. As of now, I'm just trying to get the signal into LabView, so the VI I attached is quite simple and therefore I'm hoping that my solution is very straightforward. Any help would be greatly appreciated. Hopefully once the signal is being read properly it won't be too difficult to get the necessary information from it. Also, I have checked my baud rate, CAN card, drivers, etc and I know the CAN is communicating because I can view the data I want real-time in another program on the computer, so I'm sure the problem sits somewhere between my computer and my seat. Thanks again!



0 Kudos
Message 1 of 22

Are you sure the problem is with CAN?  I suspect that if you replace your graph with a chart and move it inside the while loop, it might work.  If you don't understand why you need a chart, inside the while loop, consult the help and try running with execution highlighting (the light bulb icon") enabled.  If that doesn't fix it, start probing your code.  Do you ever get an error on any of the error wires?  Have you put a probe on the data output from X-Net Read?


Also there should be a wait of some sort inside the while loop, otherwise it will spin as fast as possible, consuming all your CPU time.  Since the CAN card will buffer a large number of packets and you're reading all available packets, there's no need to run that loop really fast.


It might also be helpful to use the CAN bus monitor in NI's Measurement and Automation Explorer, if you have that available, to see if your computer is properly receiving CAN packets from the remote device.

0 Kudos
Message 2 of 22

Thanks, I made your suggested changes and found that the only probe that is returning anything now is the error probe. It states that I'm using 'an empty name for an XNET database object' (Error-1074384541). I don't quite understand this because I can see the same signal coming through with our other software under the same database name and the reading can be read in real-time from that program.


I am able to run a program that uses the 'Frame in Stream' function and pull the frames from the CAN in that manner (similar to the CAN Frame Input Stream example). Correct me if I'm wrong, it seems to me like I could read the necessary frame from the CAN then unpack the information from there to get the signals and data that I need, but that would take a better understanding of what information is contained in the frames as well as figuring out how to get it out. Anyway, where I was going with this is that it appears like the computer is communicating properly with the CAN system, so I'm confused as to why I'm receiving this error.

0 Kudos
Message 3 of 22

This isn't a communication problem - your computer is receiving CAN packets properly, it just doesn't know what to do with them because it can't read the database for some reason.  How did you determine the name "EngExhaustGasPort1Temp J1939_2p0_gas_techjet"?  Did you set up an XNET database with that name?  That database determines how the CAN packets should be converted to actual data.

0 Kudos
Message 4 of 22

The name was pulled from our CAN database which we saved as an XNET database. 

0 Kudos
Message 5 of 22

By the way, thanks for helping me out with this problem.

0 Kudos
Message 6 of 22

Unfortunately I'm not sure I can do much more to help.  I use CAN frequently but am still using the older NI-CAN devices which do not support XNET, so I have limited experience with XNET, especially loading channels from a database.


One thing I would suggest:

Can you use the CAN Bus Monitor in Measurement and Automation Explorer (MAX) to see your CAN packets?  If you can see your raw packets, can you get the actual data out of them by using your database, still within MAX?  Once that works, it should be no problem to duplicate it in LabVIEW.  If that isn't working, then at least you can eliminate your LabVIEW code as the problem, and try to determine the issue with your database.

0 Kudos
Message 7 of 22

Ok, so I pulled up the NI-XNET CAN Bus monitor and did a data capture for just the thermocouple channels that we're after. The data column is populated, but I have never tried using any CAN communications of any sort before, so I don't know what it's supposed to look like. I attached a txt file to this if you would like to take a look at it. I'm searching for some information online to see if I can make sense of it. 

0 Kudos
Message 8 of 22

All I can tell you about your data is it looks like a bunch of CAN packets.  Have you read some background information about CAN?  If not, that would be a good start.  The quick summary is that a CAN packet has two pieces of information you care about: an Arbitration ID, and a payload.  The Arbitration ID is either 11 or 29 bits and is often used to specify the type of data contained in the packet, or as an address for the sender or intended receiver.  The payload is up to 8 bytes of data.  The CAN database defines how the payload should be converted to useful values.  For each arbitration ID you define the layout of real data within the 8 byte payload.


As far as I can tell, the error you're getting in your LabVIEW code is that for some reason it can't find the right information in the database to map the CAN data to actual values.


In the XNET Bus Monitor, under Settings -> Interface and Database..., if you assign the database name to your database, does it then correctly identify the frame name when you receive packets?

0 Kudos
Message 9 of 22

Could you attach the database you are using.


After going though some of the exsamples that is ship with LabVIEW, it seems that you are doing something wrong with the signals.

Try take a look at the exsample "CAN Signal Input Single Point".


What is your CAN device ?

0 Kudos
Message 10 of 22