CAN Communication: Integrated Interface versus X20 I/O

Ask Questions
1

Most of the CAN communication I’ve done has been with the integrated Master interfaces (e.g. on the X90). However, I’ll soon be working with an X20CS1070 which will be connected to an APC3100 via X2X/PLK. It looks like this module has more settings and I’m not sure if that makes it more flexible, more complicated, or both. I have a few questions about the X20 slice that I was curious if anyone has any thoughts on:

  1. Is it possible to add a third-party device to the hardware tree in order to map I/O data to the module? The Help says there are four different communication modes possible (flat, stream, cyclic stream, and flat stream) and I’m not sure how a third-party device file would fit into these options.
  2. How do you get around the 32 byte X2X limit? Is this something you have to be aware of or does the card do multiplexing for you?
  3. Are there any major differences between the two methods, and do you prefer one over the other?
2

1. Is it possible to add a third-party device to the hardware tree in order to map I/O data to the module? The Help says there are four different communication modes possible (flat, stream, cyclic stream, and flat stream) and I’m not sure how a third-party device file would fit into these options.

  • There are no device definition files (ex. EDS, XDD) for standard CAN (not CANopen). It’s all about the COB-IDs from there. Therefore, there is no standard file type to provide Automation Studio for configuration. You will need to use the ArCAN library to implement the CAN communication.

2. How do you get around the 32 byte X2X limit? Is this something you have to be aware of or does the card do multiplexing for you?

  • The function models of Electronics Modules (Serial/CAN) are built to work around the X2X data-per-module limitation. Each doing so in a different way.
    • Stream - uses acyclic X2X packets to transfer data to the X20/X67 module. Useful if you are pushing a lot of data, infrequently.
    • Cyclic Stream - uses cyclic X2X communication behind the scenes to package the data for the X20/X67 module. Useful if you are pushing data consistently.
    • Flatstream - uses existing I/O registers to generate packets of information for the X20/X67 module. Useful when you don’t have access to the other methods (non-B&R PLC, or on a non-native fieldbus).

3. Are there any major differences between the two methods, and do you prefer one over the other?

  • Since you are using a B&R PLC (APC3100 running ARemb or ARemb+Hypervisor), the ArCAN library with the X20CS1070 module in Cyclic Stream would be my default go-to. Cyclic stream provides the most consistent update rates without using Flatstream which requires additional application work.
2 Likes
3

Thanks Austin! That is really helpful.

4

But regarding 2.: You can’t really get around it right? If you cyclically have a certain amount of data, you’ll have to consider an IF card or an APC IF.

5

Right! That’s a limitation by system design, you can’t get around.

In most cases, if the PLC is fast enough, fast(er) X2X cycle times together with cyclic transfer model like cyclic stream can avoid getting buffer overflows, because the amount of the isocronous data (= cyclic data) is independent of the X2X cycle time.

When using a IF, you’re directly connected to the PLC’s / APC’s internal bus (PCI) where incoming data is directly handled and buffered by the driver’s interrupt service routines without the need to transfer it via fieldbus.