V20 F72 Fault

Hello, 

Recently I faced with F72 error on my 5 V20 VFDs 

I'm using USS protocol to control machine VFDs, I already used the same method in several machines and never had a problem, I following Siemens  recommendation and samples for my parameterization and programming. There's already decent amount of machine currently working with now problem 

Im using "USS port scan" FB in cyclic interrupt and the " USS Drive Control" FB for each VFD in use  (it use the same DB, Same like in Siemens example) 

Here are the following parameters i setup for the USS:

P0700 = 5 

P1000 = 5

P2023 = 1

P2010 = 6

P2011  = 1,2,3,4,5 (depends on the VFD position, 5 VFDs in total) 

P2012 = 2 

P2013 = 4

P2014 = 2000

So here is the problem, the VFDs 1,2,4,5 working fine, receiving the speed reference and reacting on start/stop commands via USS without any problem. Also VFD 3 receiving the speed setpoint OK but I found out that this VFD USS Drive block is Inhibited, once I reset the block and trying to run it again, the VFD seems to trying go up to the setpoint seed for around 2 seconds then I receive F72 in all 5 VFDs, and immediately the block become inhibited again . As long as I'm not starting that VFD no.3 all the rest are acting normal. I re-parameterized this VFD several times already but no success so far. 

Im attaching the drive XML file from Smart access for the reference, please take a look

if you find something suspicious please let me know, appreciate it very much thanks

I would check the wiring on VFD #3, or the wires leaving #2 or arriving at #4, or all the above.

If you temporarily change the order in the wiring from 1-2-3-4-5 to 1-3-2-4-5, does the problem stick with #3 or does it move to #2? 

Vadimcougar

Hello, 

Recently I faced with F72 error on my 5 V20 VFDs 

I'm using USS protocol to control machine VFDs, I already used the same method in several machines and never had a problem, I following Siemens  recommendation and samples for my parameterization and programming. There's already decent amount of machine currently working with now problem 

Im using "USS port scan" FB in cyclic interrupt and the " USS Drive Control" FB for each VFD in use  (it use the same DB, Same like in Siemens example) 

Here are the following parameters i setup for the USS:

P0700 = 5 

P1000 = 5

P2023 = 1

P2010 = 6

P2011  = 1,2,3,4,5 (depends on the VFD position, 5 VFDs in total) 

P2012 = 2 

P2013 = 4

P2014 = 2000

So here is the problem, the VFDs 1,2,4,5 working fine, receiving the speed reference and reacting on start/stop commands via USS without any problem. Also VFD 3 receiving the speed setpoint OK but I found out that this VFD USS Drive block is Inhibited, once I reset the block and trying to run it again, the VFD seems to trying go up to the setpoint seed for around 2 seconds then I receive F72 in all 5 VFDs, and immediately the block become inhibited again . As long as I'm not starting that VFD no.3 all the rest are acting normal. I re-parameterized this VFD several times already but no success so far. 

Im attaching the drive XML file from Smart access for the reference, please take a look

if you find something suspicious please let me know, appreciate it very much thanks

Hello Gents, 

Thank you for your support on this, I checked the wiring, everything looks fine, but seems the fault is not stays with specific VFD.

also referred to the USS timeout calculation, regarding the P2014. tried to calculate the most accurate time gap but no luck so far. I set up the P2014 to "0" in all of the VFDs so I cancelled that watchdog fault. what I found out that when I changing the speed references, it transferring immediately, the only problem when i do the run command, the VFDs are not starting right away, some of them pretty immediately but for some it takes like more than 5 sec to start, same with the stop, and its absolutely randomly. For now, my solution is P2014=0, keep speed reference command via USS, but the run stop signals im running with digital I/Os. The subject still open but machine works fine :))

I've had this issue a couple times and each time it has come down to parameter 2014. The time always end up needing to be greater than the initial expectation / calculation. The default setting for p2014 when reset to factory settings is 500. For running 8 drives in series, I had to set p2014 to 2000. For 13 drives in series, I had to set it to 4500. With this many drives, the cycle time for control is kind of out the window. So generally the serial communication is only used for status and setting drive speed. All ctrl is transitioned to DI terminals.