Hi, I have a CANOpen product, the custome is saying the sensor response time usually within 0.8mS, but some response time is over 1.2~1.5msec. They are using 1-to-1 communication between PC and my unit. No other unit presents in their system. They are sending sync command (0x80) and expecting reply with 2 information in one reply command. Can anybody suggest what could go wrong? Or, is it an error at all I am using AT89C51CC01 micro with opto isolated (HCPL 710) output.

If it is an issue where should I look at to solve this .

 

Is either unit generating Error Frames?
How long is the cable?
What is the baudrate?
What are the bit timing parameters?

 

Hi, I have a CANOpen product, the custome is saying the sensor response time usually within 0.8mS, but some response time is over 1.2~1.5msec. They are using 1-to-1 communication between PC and my unit. No other unit presents in their system. They are sending sync command (0x80) and expecting reply with 2 information in one reply command. Can anybody suggest what could go wrong? Or, is it an error at all I am using AT89C51CC01 micro with opto isolated (HCPL 710) output.

If it is an issue where should I look at to solve this .

Any chance that you could post a schematic?

hgmjr

 

Hi Papabravo,
There is no report of error messages,
cable is short,
speed 500 kbps and
70% sample point have been used {0x06,0x05,0x05,0x03} for prs, phs1 phs2, sjw respectively.

The customer is in other side of the world so there are some kind of communication gap exist. I already told them that CAN open msg response time can be varied. But they are saying the competitor product have consistant response time.

Hi Hgmjr, unfortunately all the drawings are strictly controlled, so I can't send schematics, sorry.

 

Don't worry about the schematic. It's not likely to be helpful in this case because the hardware hookups for CAN are straightforward, and what may be more important is the nature of the cable system and any terminators you might be using. Can you at least describe the transceivers, cable, and terminators for us?

For a short piece of cable like a couple of feet a single 61 Ohm terminator works well. Think about a trunkline/dropline system with 120 ohm terminators at each end and a single short dropline. Now shrink the trunkline to a single point and the two 120 ohm terminators in parallel become 60 Ohms. What you are left with is a zero length trunkline, a short dropline and a 60 Ohm terminator.

I would not expect "Error Messages" I am speaking of Error Frames. This is a low level CAN signaling technique where an Error Active Node sends 7 dominant bits in order to create a bit-stuffing violation. After the error counters in the node have incremented to a certain level the node goes Error Passive, and finally Bus Off. If this situation occurs it would explain variations in response time. At least it has in the past.

500 Kbps with optos and a "short" cable ( < 100 Meters ) is doable. We put the sample point for such a system as late in the bit cell as possible, at 87.5 % or thereabouts with an SJW of 1 or 2 at most. A 2 is used only with 18 or 20 MHz. crystals.

If you are not seeing error frames then my next guess is to experiment with allowing the CAN and timer interrupts to nest instead of processing them serially when they occur in close time proximity.

Last suggestion is to move as much processing out of the interrupt routine as possible, and implement a software interrupt using a Timer/Counter that expires after 1 tick. Set the counter to 0xFF and make an SWI macro that sets the TR1 or TR0 bit to a 1. That will allow you to switch back to the interrupt level for dispatching responses.

I may have some CC01 code lying around that might be useful to you, but it is for DeviceNet instead of CAN Open.

Good Luck