Compiler/TM4C123AE6PM: CAN bus 2 way communication

Djedjica said:

I have a question regarding CAN communication. I have two boards with TM4C123AE6PM and in both of them PA0 and PA1 are used for CAN and connected to CAN transceiver and I have set up communication in one direction. Now I want to have board 2 also send information back to board 1. Do I manage to do that by creating another message object ( tCANMsgObject ) with type MSG_OBJ_TYPE_TX and have board send it back?

Yes. Make sure the arbitration values (usually called IDs) are different though.

Although I have a feeling you may have go a hold of the wrong end of the stick. Although you can set up CAN as a reply/response you miss most of its utility when you do so.

CAN is fundamentally a control network. It does not fit neatly into the ISO network stack model although several of the HLPs (Higher Level Protocols) shoehorn it in.

Close analogies to CANs fundamental nature would be publish/subscribe or reflective memory. The idea is each node sends out information/commands and other nodes 'listen' to only those that they are concerned with. For example you could have a motor control setup where there are two mechanical connected motors controlled from a speed control with a separate HMI and a separate interlock controller.

• The speed control sends out speed commands
  • In the case of receiving a fault it will set the speed output to zero.
• The primary motor/controller controls the speed
  • It reports the motor and controller temperature
    
    • It will reduce speed in the case of overtemperature
    • If the temperature reaches a limit point it will declare a fault, shutdown and send a fault message
  • It reports its current operating torque
    
    • It will declare a fault, shutdown and send a fault message in case of an overtorque
  • It reports its voltage and current
    
    • An overcurrent will cause the controller to declare a fault, shutdown and send a fault message
  • In case of a fault being received it will shutdown
• The secondary motor/controller regulates its torque to some fraction of the primary

• It reports the motor and controller temperature
  
  • It will reduce torque in the case of overtemperature
  • If the temperature reaches a limit point it will declare a fault, shutdown and send a fault message
• It reports its current operating torque
  
  • It will declare a fault, shutdown and send a fault message in case of an overtorque
• It reports its voltage and current
  
  • An overcurrent will cause the controller to declare a fault, shutdown and send a fault message
• In case of a fault being received it will shutdown

• The HMI display status and fault information
  • Status and fault information will be gathered from the data on the bus
• The interlock controller monitors interlock switches (The pattern should be obvious now)

• If the interlocks are not satisfied then the controller will declare a fault and send a fault message

Obviously, this is simplified presentation but think it gives you the idea. Note that none of these involve a query/response setup. You would do something like RMA (Rate Monotonic Analysis, don't let the name intimidate you it's really quite simple) to set up the schedule for these messages and ensure you don't overload the network. Once you have done the work to set it up you end up with something that is fairly easy to extend and performs well.

Robert

Djedjica said:

I want to set it up just if one chip gives fault, than this listening system can send to controller to reset some peripheral.

This is something where reply/response is not the best form. It is something for which CAN is well suited.

What you are really looking for is a set of watchdog signals. Each board sends an ongoing watchdog message. If that message is not received periodically then the receiving parties know something has gone wrong and can attempt to recover or shut down. Note that this also captures network faults which the query response will not do.

You might set up each message in a format something like

• Byte 0: an ongoing counter. Updated each time the message is sent
• Byte 1: Status flags indicating the status of the board, including perhaps fault flags or state information

You might send these messages every 10mS and declare a fault if the count on a received message does not change within 30mS. You timing will vary depending on your system.

Djedjica said:

but there we need query/response communication among multiple nodes so I suppose something other should be used.

You misunderstand. The issue is not that query/response cannot be used with CAN but that query/response should not be used for a control protocol. Your fault response is one example of a control message. You do need query/response for items like retrieving fault history or details and you can do this on CAN. Just don't build up a query/response protocol and then use itfor regular control, the base CAN protocol is better suited to that.

Robert