Industry Online Support
Technical Forum
Navigation
Rating 
Thanks 2
5 Entries
| 3/20/2013 2:22 PM | |
Joined: 9/27/2006 Last visit: 9/10/2024 Posts: 12282 Rating:
|
Hello veer; Whenever you control a drive over a fieldbus, whatever brand of drive you are controlling, reaction to a communication loss must be controlled by the drive parameters. Here is a description of parameter 30.18 of the ACS800, "Comm Flt Func" and the parameter values that determine whether the drive will trip on communication loss, change to another selected safe speed or continue on last speed setting: ACS800 Programming Manual 30.18 COMM FLT FUNC Selects how the drive reacts in a fieldbus communication break, i.e. when the drive fails to receive the Main Reference Data Set or the Auxiliary Reference Data Set. The time delays are given by parameters 30.19 and 30.21. FAULT Protection is active. The drive trips on a fault and stops the motor as defined by parameter 21.03.(Value=1) NO Protection is inactive. (Value=2) CONST SP 15 Protection is active. The drive generates a warning and sets the speed to the value defined by parameter 12.16. WARNING! Make sure that it is safe to continue operation in case of a communication break.(Valure=3) LAST SPEED Protection is active. The drive generates a warning and freezes the speed to the level the drive was operating at. The speed is determined by the average speed over the previous 10 seconds. WARNING! Make sure that it is safe to continue operation in case of a communication break.(Valure=4) Now I am not a ABB drive specialist, and I cannot tell you all the detailed functions o an ACS800 drive. So first check what the parameter 30.18 contains at this time, and please study the interactions of the different parameter sets (or discuss them with an ABB specialist) to determine how the overall functions of the drive could be affected by a change in parameter 30.18, befoire you attempt such a change on the plant floor (or setup a test system you can try out and learrn from). Hope this helps, Daniel Chartier |
Last edited by: dchartier at: 3/20/2013 2:25 PM |
|
| 3/21/2013 9:03 AM | |
Joined: 10/7/2005 Last visit: 9/11/2024 Posts: 3020 Rating:
|
Hello veer Daniel is correct as far as "real" communication breaks are concernend. If I understand you scenario correctly though,you do NOT have aProfibus DP communication failure between the PLC and the drive, but instead an S7 PLC that (for whatever reasons) goes into STOP mode. If this is indeed the case,the following must be noted: -The DP Master of an an S7 PLC is set to so called "Clear" state when your CPUgoes intoSTOP mode. Profibus DP communication between the DP master and the DP Slaves is howevestill active. - If the DP Slave has the entry "Failsafe = 0" in its GSD file, the DP Slavewill still receive its outputs from the DP Master butall outputs will be send as a "0" value (i.e. all Slave outputs will be switched OFF). - If the DP Slave has however the entry "Failsafe = 1" in its GSD file, the DP Slavewill NOT receive any output information from the DP Master at all anymore (i.e. the lenght of output data is zero). The DP Slave behaviour now depends entirely on its configuration (this mode allows you to for example retain the last output OR to go to pre-defined failsafe state as a reaction to a PLC stop). I had a look at the RPBA-01's GSD file which has either thename "ABB_0812.gsd" (DP-V0 compliant) or "ABB10812.gsd" (DP-V1 compliant). Can you confirm that these are the GSD files that you use? If so, please check in the properties of the DP Slave to what mode you have set the failsafe state(i.e. "Stop" or "Last Speed" or "use failsafe values", see attached pic for where to find this setting). One thing that worries me is that the GSD files thatI downloaded contain the following entry: Fail_Safe= 1 ; state CLEAR not accepted Should your DP Slave failsafe state already be configured for lets say"Stop", the comment "state CLEAR not accepted" could also explain the problem (and is hopefully a comment mistakein the GSD file as this comment does not make sense to me to tell you the truth.As mentioned above, CLEAR state is exactly the statethe DP Master of an S7 enters when the CPU goes into stop mode and a DP slave should support this). I hope this helps |
|
Cheers |
|
This contribution was helpful to
|
|
| 3/22/2013 1:34 PM | |
|
Posts: 103 Rating:
|
dear fritz thank for your reply , problem is ssame as you thinking when plc goes in stop mode comm does not break(rpba module left below green led starts blinking) here is i attaching snapshots of dp slave properties plz have a look on it and tell me where i am wrong.
Attachmentdp_slave.zip (279 Downloads) |
| 3/22/2013 2:35 PM | |
|
Joined: 10/7/2005 Last visit: 9/11/2024 Posts: 3020 Rating:
|
Hello veer your DP Slave config looks ok to me, but I'd encourage you to consult the manual for more info (I haven't used this DP Slave yet and can't offer any hands on experience). You can also try the setting "use failsafe values" and then specify 0 values for these. Having said the above, here comes the "hot potato": I am still concerned about the entry "Fail_Safe = 1" followed by the comment"state CLEAR not accepted" in the GSD file. This simply does not make sense and hints at a non certified DP Slave (DP Slave certification is unfortunately not mandatory). The whole point of a GSD entry "Fail_Safe = 1" is that the DP Master does not need to send any outputs anymore to the DP Slave when the DP Master goes into "CLEAR" state (i.e. CPU stop) and the official definition of this parameter is: "Here it is specified whether the DP slave accepts a data message without data instead of a data message with data = 0 in the CLEAR mode of the DP master (Class 1)." |
|
Cheers |
|
Follow us on