Anybus B40 - EtherCAT/Profinet

Hi experts,

is it possible to set the minimum bus cycle time in general at ABCC modules? I don’t use SYNC mechanisms and my host system is limited in managing large data amounts and fast bus cycles. E.g., if bus cycle would be faster than 500µs I expect data Ioss at my application. I know that there are specific setups for EtherCAT (DC) and Profinet (IRT) with cycle time limits, but I am looking for a general way. The network protocol manuals as well as the SW Design documentation didn’t show such a possibility.

Best Regards,

Hi Thomas,

Unfortunately there is no possibility to slow down the bus cycle in our module, because this will be defined from the master device (PLC) and not from our module. The module will communicate with your application over your used hardware interface (SPI, Paralle or UART). You can think about using e the interrupt pins/register to let your application handle the process data in high priority task, when it arrives from the module.

Best regards

While @TareQ_hms is correct with there not being a way to set the cycle time from a slave device, the device does have the ability to NAK the request and thus indicate to the master of an issue thus preventing the device from being set to an operational state. You can do this via the Sync object and since as you mention you are not targeting synchronous modes, you would only indicate that you support/use non synchronous mode in the sync object. Then you can use the minimum cycle time attribute to reject requests for using cycle times that are shorter that what the device supports.

On EtherCAT, this means that the device will support only Free Run (which is the same as what is indicated when not enabling the sync object) and if the master attempts to set the cycle time explicitly in the Sync Communication Parameter objects the request will be aborted if it is less than this minimum otherwise the cycle time attribute will be updated with this new value. Keep in mind with Free Run the cycle time in this parameter object represents the application cycle not the network cycle (like it does with Sync SM and DC Sync); so the EtherCAT cycle time might still be set to a faster cycle time even if your application indicates does not permit faster cycle times (i.e. Free Run decouples the EtherCAT network cycle from the application cycle). So technically, a reason you might want to utilize this functionality is if you want to adapt your application cycle to something the user explicitly configured (this generally requires the user to add an InitCmd to the network configuration during, say, a state change from PREOP–>OP).

While there are technical differences between the two networks the same approach should support this use-case. Effectively you are supporting operation on an IRT network but not utilizing the synchronous functionality in your application.

The related attributes that need to be considered in the Sync object for this are:

  • Attribute 1: Cycle time
  • Attribute 6: Min cycle time
  • Attribute 7: Sync mode
  • Attribute 8: Supported sync modes