Skip to Content

Register Login

Industry Online Support

Technical Forum

Navigation

WinCC V6.0 SP4 Server/Client Freeze

Created by: henno2000 at: 9/4/2007 2:50 PM (10 Replies)

Rating (0)

Thanks 0

Result pages:: |; 1 | 2; |

11 Entries

Entries per page: 10 | all

9/4/2007 2:50 PM	Rate (0)
henno2000 Posts: 177 Rating: (0)	Hi, I have read many an article relating to the random freezing WinCC projects in runtime etc. My scenario is as follows: The 'main' client randonly freezes and runtime has to be exited and close WinCC explorer to restart successfully. The server appears to freeze, but after about a minute, returns to normal (in the meantime the client is fine). IE - counters increment, but screens fail to load immediately. The other client machine is fine for the whole of this. To try to eliminate the main client problem I have ordered some PS2 extensions as currently the peripherals of the machine are connected viaa USB hub. I am not sure about the server problem, but believe it may be down to scripting (but cannot see why the client machines are not affected) I have attached the Diagnose folder, if someone could interpret the data? Regards, henno2000 Attachment diagnose.zip (241 Downloads)
henno2000 Posts: 177 Rating: (0)
Suggestion To thank Quote Answer

9/4/2007 4:48 PM	Rate (0)
Ikkezelf Posts: 1084 Rating: (72)	Freeze problems normally are lead back to network related problems. Your sure your network connections between server and clients and PLC ahrdware is fine? ikkezelf
Ikkezelf Posts: 1084 Rating: (72)
Suggestion To thank Quote Answer

9/4/2007 5:17 PM	Rate (0)
henno2000 Posts: 177 Rating: (0)	What is the best way of checking the integrity of a network? Regards, henno2000
henno2000 Posts: 177 Rating: (0)
Suggestion To thank Quote Answer

9/4/2007 5:29 PM	Rate (0)
Ikkezelf Posts: 1084 Rating: (72)	The best way is expensive, but there are some software tools on the internet that can check for free even. But to start: You could check with 'ping' from one machine to another and to the plc's to see if you have any packa losses at all. Als the response time can be a pointer in finding the cause. 'tracert' lets you see all nodes that it going through. with regards, Ikkezelf
Ikkezelf Posts: 1084 Rating: (72)
Suggestion To thank Quote Answer

9/4/2007 6:19 PM	Rate (0)
Darius Platinum Member Joined: 9/28/2005 Last visit: 12/3/2024 Posts: 2957 Rating: (243)	Hello, I have had the same problem. The cause of problem was broken ethernet wire. You schould check cable with special hardware tools or if you haven't one of them (as I do), you can allways try to replace this client's cable with the new one and see what happens. My problem was that all clients freezs, so I replaces cable from main server to switch and all became normal. Whish you look in your findings. Best regards,
	Best regards, Darius
Suggestion To thank Quote Answer

9/4/2007 6:34 PM	Rate (0)
Danielle Posts: 1275 Rating: (123)	Hi henno, About your diagnose, there are some things you should look at: 2007-09-03 08:10:18,859 ERROR Illegal tag address "C-210_YA_1200A.Value"! 255,03.09.2007,05:37:05:328,1007007,4,,AIMM-WINCC-S001,SCRIPT,Deactivation : Action was stopped by script 255,03.09.2007,05:37:10:328,1007001,4,,AIMM-WINCC-S001,SCRIPT,UnLoadFctAll nCount 359 255,03.09.2007,08:04:47:234,1007000,4,,AIMM-WINCC-S001,SCRIPT,ActionOverflow:more than 5000 Actions to work Best regards, Danielle
Danielle Posts: 1275 Rating: (123)
Suggestion To thank Quote Answer

9/5/2007 9:02 AM	Rate (0)
henno2000 Posts: 177 Rating: (0)	Thanks, for the SCRIPT actions, would this indicate that there is a script that is a constant loop? Is there any way to determine which script is cause this? Regards, henno2000
henno2000 Posts: 177 Rating: (0)
Suggestion To thank Quote Answer

9/5/2007 2:35 PM	Rate (0)
Danielle Posts: 1275 Rating: (123)	Hi henno, The "over 5000 actions" could mean one of your scripts is in loop, or it's taking too long to be executed for some reason, so all scripts which are called while it's still running start forming a queue. This queue sometimes gets too big. Here's an FAQ which may help. Best regards, Danielle
Danielle Posts: 1275 Rating: (123)
Suggestion To thank Quote Answer

9/6/2007 11:28 AM	Rate (0)
henno2000 Posts: 177 Rating: (0)	Ikkezelf The best way is expensive, but there are some software tools on the internet that can check for free even. But to start: You could check with 'ping' from one machine to another and to the plc's to see if you have any packa losses at all. Als the response time can be a pointer in finding the cause. 'tracert' lets you see all nodes that it going through. with regards, Ikkezelf Thanks for the advice, I have managed to sucessfully ping all PLC, switches and HMI on the network with the response times all under 5ms. I am not sure how to use the tracert function. I have typed the command in the command prompt and the server IP, but all I get is the one trace. For a full trace of all nodes on the network, which address should I use (I have tried various ones, but they all return only a single trace). Danielle Hi henno, The "over 5000 actions" could mean one of your scripts is in loop, or it's taking too long to be executed for some reason, so all scripts which are called while it's still running start forming a queue. This queue sometimes gets too big. Here's an FAQ which may help. Best regards, Danielle I have reduced all tag logging achiving times to lower one to see if this also helps. Regards, henno2000
henno2000 Posts: 177 Rating: (0)
Suggestion To thank Quote Answer

9/6/2007 12:09 PM	Rate (0)
Ikkezelf Posts: 1084 Rating: (72)	Hi, the tracert is used to see over how many hops/nodes it travels before reaching it's destination. If yours is in the same subnet, you could end up with only one result. That ping result looks good enough. Development department is investigating something that has to do with 'slinkysearch'. If I get a result I will let you know. (this has somehting to do with freezes as well). with regards, Ikkezelf
Ikkezelf Posts: 1084 Rating: (72)
Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Follow us on