My new customer is saying that the unit is sometimes not responding to the sync command (0x80). The unit supposed to replay with 2 informations where ever the master issue sync (0x80) command. But sometime the master need to issue 2/3 sync command to get a reply. They are using 1-to-1 communication. The unit uses AT89C51CC01 micro with opto-isolate HCPL 710) output. Anybody could suggest where to start in my firmware, or, is this could be a hardware issue?
missing CANOpen responses
- Thread starter Shan70
- Start date
Hi Shan,
In your other post you mentioned times such as 0.8ms and 1.5ms. Does this mean that your messages are transmitted every 0.8ms, or is this simply the delay you expect between request and reply? How often do you transmit the sync command?
Working with CAN and the PC-environment, I have noticed that you can't accept the time stamps of CAN messages as being entirely accurate. It depends on how the CAN bus connects to the PC. I'm using USB dongles and they are limited by how fast the PC is able to service the USB bus. Although you can send/receive enormous volumes of data over USB, it becomes far less efficient when you're sending and receiving thousands of very small packets.
Also, you need to look at your micro. At what clock speed does it run? If you periodically service your CANopen stack, what percentage of execution time is used for this? What other tasks does your micro perform?
I've also implemented CANopen stacks into Atmel micro's, but using the AVR-family. I've opted to use polling and making sure that the CAN module is set up in such a way that it can receive as many messages as there could physically be between two polling events. An Interrupt-driven method is not wrong, but less predictable - and when messages go missing, you need predictability.
I hope this gives you some things to think about!
In your other post you mentioned times such as 0.8ms and 1.5ms. Does this mean that your messages are transmitted every 0.8ms, or is this simply the delay you expect between request and reply? How often do you transmit the sync command?
Working with CAN and the PC-environment, I have noticed that you can't accept the time stamps of CAN messages as being entirely accurate. It depends on how the CAN bus connects to the PC. I'm using USB dongles and they are limited by how fast the PC is able to service the USB bus. Although you can send/receive enormous volumes of data over USB, it becomes far less efficient when you're sending and receiving thousands of very small packets.
Also, you need to look at your micro. At what clock speed does it run? If you periodically service your CANopen stack, what percentage of execution time is used for this? What other tasks does your micro perform?
I've also implemented CANopen stacks into Atmel micro's, but using the AVR-family. I've opted to use polling and making sure that the CAN module is set up in such a way that it can receive as many messages as there could physically be between two polling events. An Interrupt-driven method is not wrong, but less predictable - and when messages go missing, you need predictability.
I hope this gives you some things to think about!
Many Thanks for you reply.
This customer is sending SYNC command every 20ms and said worst case response time is 1.5ms and nominally 0.8ms. I reviewed some more information it seems to me it's normal for CAN messages.
About missing responses I need to start looking at the code. The system uses 20MHz crystal. The customer requested few specialized command which I implemented, also because they are asking for more tighter spec with T ramp up/down I added some extra compensation in Temp and Pressure calculation. These extra codes might over burden the resources. I will look at making code more effiecient. My software do use interrupt routine.
This customer is sending SYNC command every 20ms and said worst case response time is 1.5ms and nominally 0.8ms. I reviewed some more information it seems to me it's normal for CAN messages.
About missing responses I need to start looking at the code. The system uses 20MHz crystal. The customer requested few specialized command which I implemented, also because they are asking for more tighter spec with T ramp up/down I added some extra compensation in Temp and Pressure calculation. These extra codes might over burden the resources. I will look at making code more effiecient. My software do use interrupt routine.
Attachments
Your images are not very clear.
As I said, it's not wrong to use interrupts, it's just less predictable. If you only have say two normal interrupts (CAN and a timer) then it should be fine (it's fine to have external interrupts which trigger in emergencies - they don't occupy the system during normal operation). Just make sure that your interrupt service routines are very short - for example the CAN service routine should only copy the received CAN message to a buffer in RAM and set a flag to indicate that the CANopen stack must be called by the main program.
As I said, it's not wrong to use interrupts, it's just less predictable. If you only have say two normal interrupts (CAN and a timer) then it should be fine (it's fine to have external interrupts which trigger in emergencies - they don't occupy the system during normal operation). Just make sure that your interrupt service routines are very short - for example the CAN service routine should only copy the received CAN message to a buffer in RAM and set a flag to indicate that the CANopen stack must be called by the main program.
The lack of responses is likely due to the non-reception of the incoming message. When using opto-isolators you need to be very careful with your delay budget. You also need to rexamine your bit timing parameters. 20 MHz is faster than the 16 MHz. crystals that were used on the 82C200 and 82527, the original CAN controllers.
If you are trying to run a 1Mbit/sec with optos I can almost guarantee that it will fail.
The CC01 is a very reliable part but it does have some tricky aspects. We actually arranged for the CAN and timer interrupts to be nested since the 8051 architecture has the possibility to do this.
If you are trying to run a 1Mbit/sec with optos I can almost guarantee that it will fail.
The CC01 is a very reliable part but it does have some tricky aspects. We actually arranged for the CAN and timer interrupts to be nested since the 8051 architecture has the possibility to do this.
Last edited:
