Re: I connect my device to a truck's can port (J1939) , the truck present an error .

"Kees Zagers" <[email protected]>
Newsgroups gmane.comp.hardware.bus.can
Organization SI-Kwadraat
Message-ID <[email protected]>
The only way to prevent your CAN controller to send error frames, is to set it to listen-only, but:

- You cannot send any messages on the bus in this case.
- You cannot see the messages which would produce the error frames when you were in normal mode, because internally in the CAN-controller they are still seen as errors.

The error mechanism is not in the CPU or in the driver, it is in the CAN-controller hardware itself. In your case the CAN-controller is integrated in the CPU itself, but still you can not influence it further than switching it between normal or listen-only. In listen-only mode it does not send errorframes, acknowledges and any CANframes of its own. On the other hand it receives exactly the same information from the bus as it does in the normal mode. So maybe it receives messages from 10 nodes correctly, but from two other nodes not.

Kees

  ----- Original Message ----- 
  From: c yl 
  To: [email protected] ; [email protected] 
  Sent: Tuesday, January 20, 2015 10:53 AM
  Subject: Re: [CANLIST] I connect my device to a truck's can port (J1939) , the truck present an error .


  Thanks,I will try it a few days later when the truck is available. Is it possible to stop my can controller to send error frames? Is it the behavior of the cpu itself or I can reprocess the driver to stop it?



  On Tuesday, January 20, 2015 3:58 PM, "[email protected]" <[email protected]> wrote:




  Hi,

  It is not the ACK-bit, because if yr node sends that, it has received 
  the message correctly. If this is sent or not sent it is not relevant 
  for the sending node in the truck; it receives the ACK anyway from the 
  other local nodes.

  I have the impression that your cabling to your node is not correctly. 
  Either too long or it picks up too much noise or maybe you set some 
  extra termination. E.g. when one or more specific nodes in the truck are 
  sending their messages, your node does not receive them correctly and 
  sends an errorframe. The sending node increments its tx errorcounter and 
  tries again. If it does that for a couple of times, it will go to an 
  error passive state and almost directly after that to the bus off state. 
  Your truck will now show the error.

  If you are in the listen-only mode, your node does not send the error 
  messages, so the truck is not disturbed. However you also will not see 
  the messages of those specific nodes which cause the error messages.

  So try to connect your CAN node to the truck CANbus with a stub as short 
  as possible.

  Kees Zagers
  SI-Kwadraat B.V.


  c yl schreef op 20.01.2015 03:12:
  > I think its because my device set the ACK bit , and the truck can not
  > receive the messages . Is that possible ?
  > 
  >  On Monday, January 19, 2015 6:54 PM, Heinz-Jürgen Oertel
  > <[email protected]> wrote:
  > 
  > Am Montag, 19. Januar 2015, 09:56:14 schrieb c yl:
  >> Hi Everyone:
  >> I'm connecting my can port of an arm7 board (lpc2478 with ecos which
  > works all OK) to a truck's can port, and the truck presents an error:
  > I think its communication error or something. And at the same time my
  > board can receive can packages right. If I set my can port to listen
  > only mode , the truck tells no error, and I can receive can packages
  > but I can't send then . Can anyone tell me why the truck tells error
  > when my can port works at a normal mode? Should I work only in a
  > listen only mode?
  > 
  > Hi,
  > 
  > can you read out your devices error counters, especially the transmit
  > error counter of the lpc2478 when you connect and you are not in
  > listen only mode.
  > 
  > --
  > mit freundlichen Grüßen
  >  Heinz-Jürgen Oertel
  >  emtas GmbH


  --
  Archives and useful links: http://groups.yahoo.com/group/CANbus
  Subscribe and unsubscribe at www.vector.com/canlist/
  Report any problems to <[email protected]
  >
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.