LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Losing communication with CAN

Solved!
Go to solution

I am running a program that monitors parts using USB 8473 and using CAN.  Is it necessary to close and then reopen the CAN communication between parts so that I don't get errors related to the CAN message?  The program opens CAN communication but runs continuously with out closing until the program is stopped so parts are unplugged and then replugged in without closing CAN inbetween.  I am thinking I mayneed to write a program to stop the communicatiion between parts but wanted to verify if this is correct?

Thanks!

-ncm
0 Kudos
Message 1 of 5
(3,554 Views)
Solution
Accepted by topic author ncm

If you're just doing read only monitoring, you probably don't need to close the communication.

It might be good practice to do so just so that you can keep distinction between parts.

 

If your monitor does any transmission then you would need to stop the transmission when you detach your listeners to avoid going into a Bus Off state.

Message 2 of 5
(3,535 Views)
Would transmission include ncGetAttr.vi and/or ncWriteNet.vi?
-ncm
0 Kudos
Message 3 of 5
(3,525 Views)

If you're doing ncWriteNet.vi then you'll want to make sure you're not trying to write while the part is disconnected. So in that case, I would recommended either closing the interface or at least pausing any transmission when you expect there not to be a listener on the other end.

0 Kudos
Message 4 of 5
(3,483 Views)

@Taki1999 wrote:

 

If your monitor does any transmission then you would need to stop the transmission when you detach your listeners to avoid going into a Bus Off state.


Or use a single transmission mode (write once?) so the transmission doesn't repeat until acknowledged.  Of course this is only recommended in an environment when you are very sure the message will reach its destination.

 

I had a situation where my tester was blamed for flooding the bus with CAN messages.  The part would fail and looking at the bus traffic you would see the bus at 100% usage (in listen only) and so it was said I was sending too much data causing the UUT to go to sleep.  Or course once the setting was changed to a single transmission and the part went to sleep it was clear it wasn't my fault, but a bad part.

0 Kudos
Message 5 of 5
(3,479 Views)