| View previous topic :: View next topic |
| Author |
Message |
notbad
Joined: 10 Jan 2013
Posts: 68
|
| CANopen |
 Posted: Wed Nov 13, 2013 4:05 am |
 |
|
Hi
There is an industrial motor drive with a CANopen port which i want to control using a PIC with a built-in CAN.
Is this possible? Where do I get stated? |
|
 |
notbad
Joined: 10 Jan 2013
Posts: 68
|
|
| Posted: Sat Nov 16, 2013 6:34 am |
|
|
Does the CAN controller inside the pic automatically Re-transmit the messages that didn't get acknowledged?
Can we be sure that when a send command is issued, the message is delivered unless there is a connection problem?
Thanks |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Sun Nov 17, 2013 2:59 am |
|
|
| notbad wrote: | Does the CAN controller inside the pic automatically Re-transmit the messages that didn't get acknowledged?
Can we be sure that when a send command is issued, the message is delivered unless there is a connection problem?
Thanks |
Some CAN gotchas:
CAN is a broadcast message passing bus. It is not a point to point comms link. It is not addressable. This has possibly unexpected consquences:
Any CAN device running at the right speed and correctly connected will acknowledge CAN messages. The CAN interface will retransmit any message that are not correctly acknowledged. The buffering in the CAN interface means that it is not possible to ensure any message has been transmitted, nor that it is sent in any particular order in relation to other messages.
The buffering means that when a CAN node locks up and refuses to transmit it is not the message on which the lock-up appears to happen, rather it is two messages prior to the lock up that the node is trying to transmit. I.e. message A fails to transmit and continually resends. Then software tries to send message B, which the CAN interface accepts and buffers, despite message A not having been successfully transmitted. Then software tries to send message C, which also is buffered. However, when the software tries to send message D, it fails as there is no transmit buffer space, BUT message A is still being re-sent, and B and C haven't been sent at all.
As ANY and all active CAN nodes can acknowledge, an acknowledgement does not mean the message has been received correctly by the intended node: all messages are broadcast to all nodes and they are not addressed to specific nodes. One point that sometimes catches developers out is that CAN monitors are just another CAN node, and they generally will acknowledge all messages on the bus, though some may have a setting where they will not acknowledge.
All good fun :-) |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
