* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project
CAN configuration guide for ifm product using CoDeSys 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Insure that the network variable COB-ID usage does not conflict with any CANopen device IDs in the PLC configuration or the IDs associated with any function blocks of type CAN Tx and Rx. When selecting the option to Pack variables, be aware of potential for ID conflicts with data types exceeding 8 bytes. Network variables do not support the transfer of string type variables. Network variables can be transferred on event (other variable), on change, and cyclically. Interval time denotes the period between transmissions when using cyclic mode, while minimum gap indicates the elapsed time necessary before a transmission occurs, if the variable changes too often. Although both CAN Rx and CAN Tx can be called more than once per cycle, it is generally not recommended. Note that each call to CAN Tx and Rx only reads or writes a single message (8 bytes). To reduce peak bus load, transmissions using CAN Tx and Network variables can be parsed over several cycles using event driven communications. In the PLC configuration the CANopen master settings should be as follows: Com Cycle Period and Sync Window Length should be set to the same value. This value must be greater than the PLC cycle time. Note that setting the Communication cycle period in the slave causes the slave to monitor the network for a synch object from the master in that time period, so if using this mechanism; it must be longer than the master synch time. We recommend that slaves be set as optional and the network be set to automatic startup. This reduces unnecessary bus traffic and will allow a momentarily lost slave to re-establish connection to the network. Since we do not have an inhibit timer, it is recommended that analog inputs be set to synchronous communication to prevent overloading the bus. For binary inputs, especially those that occur infrequently, it is best to set asynchronous communication with an event timer. Use caution when monitoring slave status as there is a delay at boot up before the slaves are operational. Also be aware when shutting down the system that the slaves may lose power earlier than the master due to supply capacitance in the master and the master may see a change in slave status at this time. Where possible use heartbeat instead of node guarding as it is a newer more efficient mechanism.