10/22/2010 2:53 PM | |
Posts: 9 Rating:
|
I am trying to connect redundant analog outputs to a S7-400H system. The hardware connection is made as described in the S7-400H system manual gage 396. I use two 6ES7332-5RD00-0AB0 modules two 1N4007 diodes and a resistor from 250 ohm 1W. Each module gives half of the signal 7.2 mA , together 14.4 mA what is correct. When I disconnect one channel nothing changes in the other module still 7.2 mA instate of 14.4 mA. When I look at the modules via FB453 (RED_STATUS) nothing is pacified. In the attachment I give the hardware settings from the AO module and from the 414CPU.... AttachmentAO3.zip (323 Downloads) |
This contribution was helpful to
1 thankful Users |
10/26/2010 10:47 AM | |
Joined: 7/2/2008 Last visit: 8/26/2024 Posts: 928 Rating:
|
Hello bosspeleo, I think your configuration is partially working. It just lacks something that we are going to discover. I say partially working since your analog signal (14.4 mA) comes from two 7.2 mA. Now it seems that CPU does not detect your action (disconnecting channel) and consequently your modules (channels) are not passivated. This can be caused by some reasons: 1- You didn't enable module diagnostics (Your pic. says you did but you should make sure that you have loaded this configuration on CPU). 2- Your module detects wire break but the correct error OB (OB82) is not loaded in CPU (make sure you have loaded OB82 and any other error OB). 3- OB82 is there but you didn't call FB452. If you are sureof all above, then you should tell us the return value and extended info. of FB452 in OB82. Could you please make another test by taking one of the 2 modules out of rack? In this case OB83 should be called and if FB452 is called there correctly then the out module should be passivated and the other module will produce 14.4 mA.
Every time you call FB452, you should assign a unique instance data block. You should assign unique address for both return value and extended info. so you can go back to these values in case of error and for sure you will be able to understand where the problem is (OB72, OB82, OB83 or OB85). Best regards. H-H |
This contribution was helpful to
4 thankful Users |
10/26/2010 6:26 PM | |
Posts: 9 Rating:
|
H-H, I think mi application is working now. But I still want you to take a look to mi screenshots. I made mi PI-image larger because I use analog IN/OUT-puts. See screenshot AO4.bmp. This was the reason for errors by every call from FB452 "RED_DIAG". So I made the memory in priority classes 28 and 25 larger to 600 byte the same as my PI-image. I made the memory from the priority classes 9 and 26 smaller because I did not want to change the total memory from the priority classes. When I made these changes the systemgave me some problems when I performed a cold start. The Redf led's lid and the CPU in rack1 would not start. Whit mi current settingsas you can see in mi screenshots every thing is running OK.Best regards Bruno AttachmentCPUaanpassingen .zip (314 Downloads) |
This contribution was helpful to
1 thankful Users |
11/5/2010 12:04 AM | |
Joined: 7/2/2008 Last visit: 8/26/2024 Posts: 928 Rating:
|
Hello bosspeleo, I'm glad your system is working now. However it's little bit confusing why it was not working. I think you are using blocks from RED_IO library that is used for channel redundancy not module redundancy. These blocks require more allocation of local data than what isrequiredby the same blocks in module redundancy library. The local data requirementsusually exceed the default values of both 412-H and 414-H. You can check that by right clicking on each block and going for the general part 2 tab in object properties. You will see that 1- FB450 requires 238 bytes of local data which means that any OB (OB1 or OB3x) that's calling FB450 must haveat least258 bytes of local data. 2- FB452 requires 416 bytes of local data which means that OB72 (Priority class 28), OB82,OB83 and OB85 (Priority class 25) must have at least 436 bytes of local data. Normally the default value of local data for priority class 25 & 28 is 256 which must be changed. The strange thing is that you didn't mention that any of the CPUs has gone in STOP mode when you simulated your fault because ifFB452 was called inany error OB without modifying default allocation of local data, the CPU must have gone into STOP. All Siemens CPUs can't toleratewrong allocation of local data. There might have been other things that caused your problem but anyhow it's now solved. I always recommend to monitor all returnvalues of RED_IO blocks to know where the problem is. It helps me a lot with aid of diagnostic buffer for sure. Best regards. H-H |
This contribution was helpful to
1 thankful Users |
Follow us on