Product FAQs

Ask a Question

Drive does not go in operational state after CANopen initialization

Goal and symptoms:
On drive with CANopen, sometimes, the "operational" command is send by PLC, but the drive does not react to this command and stay in pre-operataional.
Why drive does not go in operational state after CANopen initilaisation?

Cause and fixes:
Drives (ATV71, ATV32/320, ATV312 ...) could not go in operational on CANopen network initialization. This is link to the way of NMT frame sending by the PLC.
After Drives power OFF/ON, the PLC will send the configuration frame for each slave.
But on some PLC, each slaves are configure simultaneously, or send NMT command simultaneously.
 
To configure slave, PLC send reset frame to manage NMT state chart. To simplify the PLC send a reset frame to a slave and the slave answer by a “bootup” frame means that slave can be configured by PLC.
Then PLC configures the slave via SDO request, and sends again NMT command to start the slave (operational state).
 
But the point is that each NMT frame (reset node, reset communication, pre-operational…) use the COB-ID 0. The node dedicated to the command is located inside the NMT frame.
The consequence is that each NMT frame is visible for each slave present on the network (like broadcast frame)

Example:
                2 slaves are on CANopen Network, Address 2 and address 3
The master send a reset node for the slave 2 (frame: 81 02)
                - The slave 2 will receive the command and send the boot-up
                - The slave 3 will receive the command but will do nothing because this command is dedicated for the slave 2.
 
In the drive ATV32 (and also our other drive), the CANopen frame reception is done in a memory area. In function of COB-ID, we define an area where the drive will register the frame.
--> This can be considered as a step 1
Then in function of drive application task, the drive checks the area zone and will treat this frame.
--> This can be considered as a step 2  
On ATV32, the application task is 2ms, it means that drive will manage the frame in buffer only each 2ms. So in case of fast CANopen NMT command on step 1, those command could be overwrite before that the drive have time to manage it in step 2.

Conclusion
In function of PLC management, the ATV32 (and our other drives) could not start or could take time to start, because the PLC send too fast, several NMT command to different slaves.
 
Our drive respects the CANopen management frame and reacts correctly according to NMT state command. But here the point is because PLC sends too fast several NMT command. Those too fast sending, overwrite data internally in our drives before that the drive reacts to those frame.
 
To avoid this behavior:
Solution 1
When the PLC is in configuration phase, if after a reset node no boot up is received, or start command not take into account by a slave, the PLC should  re-send the NMT command.
Solution 2
To have more time between the NMT commands coming from the PLC. Like that each drive will have the time to treat their NMT command before that this command is overwrite by another one.
 
Was this helpful?
What can we do to improve the information ?