In CANopen specification there is an object called Communication Cycle Priod [1006h]. This is the time interval between two consecutive SYNC objects. There is also another object called Synchronous Window Length [1007h]. I cannot get these two parameters real-world interpretations. This synchronous window length is for a synchronization interval between nodes? After receving a SYNC object, all nodes are used it as an trigger for update their output values and accept new input from bus? For example, if my control loop wait updated values in each 1 mS, then what should I set my 1006h and 1007h values? Is there a rule for 1006h and 1007h values?

  • \$\begingroup\$ From what I remember, window length is used together with high resolution time stamp (1013h). You set a window expressed (in microseconds I believe?) in which the sync must appear at the consumer. Similar to watchdog windows on microcontrollers. \$\endgroup\$ – Lundin Mar 11 at 14:19
  • \$\begingroup\$ @Lundin, Sure, you are correct. It is written in microsecond. I try to obtain that maximum number of axes at the 1 mS update time on the CANopen bus. i.e : at most how many axes can I control at 1 mS update time by using CANopen? \$\endgroup\$ – doner_t Mar 11 at 19:04
  • \$\begingroup\$ @Lundin, In CANbus layer [physical], one frame is about 128-bit. Add interframe spacing and some possible stuffing-bits, let say one frame is 146-bit length. Even for 1Mbps baud-rate, 6850 frame/second. In 1 mS, it would give ~6 frame. This teoretical maximum value. Assume %50 bus-loading, this gives only 3 frame within 1 mS. This is realy slow for a tightly-synchronous motion-control task, isnt it? \$\endgroup\$ – doner_t Mar 12 at 15:34
  • \$\begingroup\$ Your calculations seem roughly accurate for the worst case with 29 bit id, 8 bytes payload, max stuffing (see this: electronics.stackexchange.com/a/423413/6102). "Slow" is highly subjective, depends on what you are trying to control. If you must have better than 1ms response time for the device, I'd say that's quite a special case. Most motion control systems work with 10ms periods. And slow humans can only start to spot latencies around roughly 150-200ms. \$\endgroup\$ – Lundin Mar 12 at 15:49
  • \$\begingroup\$ Btw if your bus is correctly designed, then the real-time critical data would take precedence with its low CAN identifier. Then at x% bus load you would still have the very same frame rate as you would at 0% bus load. CAN is CSMA/CA, it doesn't have packet loss due to collisions. \$\endgroup\$ – Lundin Mar 12 at 15:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.