FactoryLink ECS 6.X.0

R

Thread Starter

Ranjan Acharya

I would appreciate any input from the List regarding stability issues with large FactoryLink ECS 6.6.0 applications (Win32) -- similar problems likely exist with 6.5.0 too. The multi-platform save back-up file is approximately 60 MB. There are two issues we are dealing with right now (sending the file under a CSS agreement to the tier 1 support and USData has been of no help, since the application was deemed "too large to support): - Lost click event with PowerVB -- after some use, the graph application starts ignoring certain or all click events to objects on the screen. Perhaps some sort of memory leak. Reducing the number of Critical ... End Critical blocks (never nesting Critical blocks either) seems to reduce but not eliminate the problem. This is apparently a known issue, probably solved in version 7 -- an upgrade is out of the question at the current time. - Sudden shut-down of the graph application in WebClient. We are looking into as many FactoryLink logs as possible but have not noticed any data that is relevant. This problem only needs to ever happen once to raise the ire of the customer. Needless to say it happened on the night shift of a week-end and the graph application via WebClient was re-started. Note that the IE version of WebClient is not being used, but the graph.exe that comes with WebClient. Other applications I have seen use Terminal Server and not WebClient, perhaps this is why. Details are sketchy, but the copy on the server that runs the regular graph.exe also may have shut down once too. Thanks, RJ
 
J
Ranjan, > I would appreciate any input from the List regarding stability issues with > large FactoryLink ECS 6.6.0 applications (Win32) -- similar problems likely > exist with 6.5.0 too. The multi-platform save back-up file is approximately > 60 MB. I have applications of similar size. They are as amout as stable as any other Windows app. I don't think the MPS file size is much of a measure of the application's size though. Most of the MPS file is filled with your graphics. How many tags do have and how much memory do you have ? I run large Flink apps on servers with 512 megs memory, raid 5 drives, and dual processors. > > There are two issues we are dealing with right now (sending the file under a > CSS agreement to the tier 1 support and USData has been of no help, since > the application was deemed "too large to support): "too large to support" ???? This is nonsense. The whole purpose of FactoryLink's design is to allow large applications to be built. USData's support policy is for the tier 1 provider to try and solve your support problem, if they cannot they are supposed to hand over to USData. It still may be in your best interest from a maintenance point of view to break the app into smaller apps and connect the apps through PowerNet. > - Lost click event with PowerVB -- after some use, the graph application > starts ignoring certain or all click events to objects on the screen. > Perhaps some sort of memory leak. Reducing the number of Critical ... End > Critical blocks (never nesting Critical blocks either) seems to reduce but > not eliminate the problem. This is apparently a known issue, probably > solved in version 7 -- an upgrade is out of the question at the current > time. Have you downloaded and applied the 6.6 service pack on the USData web site ? Are you running the right OS ? Flink 6.6 is certified to run on WinNT service pack 4. > - Sudden shut-down of the graph application in WebClient. We are looking > into as many FactoryLink logs as possible but have not noticed any data that > is relevant. This problem only needs to ever happen once to raise the ire > of the customer. Needless to say it happened on the night shift of a > week-end and the graph application via WebClient was re-started. Note that > the IE version of WebClient is not being used, but the graph.exe that comes > with WebClient. Other applications I have seen use Terminal Server and not > WebClient, perhaps this is why. Details are sketchy, but the copy on the > server that runs the regular graph.exe also may have shut down once too. I have had the WebCleints disappear too. The cause of this was the network though. Are your router's and firewalls allowing the Webclient services to pass through. Jay
 
R

Robert Nickel

I cannot address all of your problems, but I believe that I have some idea of what your PowerVB issue might be in conjunction with the WebClient. I had similar trouble with USData's lack of support and found that although quite willing to help, the tier 1 support folks weren't able to address my problem since it was a "bug" in the code. Anyway, if in PowerVB you use the lockRTDB and unlockRTDB functions, you will most certainly cause your shutdown of WebClient and quite frequently seize up the server as well. It usually takes about 2-3 client deaths to equal one server death. When I was talking to the author of the WebClient software via email (Dean Forsyth at the time of my problem). If you would like more information, including the text of my exchange with USData, please email me off-list. Robert Nickel Telemetry/Distributed Control Specialist City of Fresno, Water
 
R

Ranjan Acharya

In answer to some questions posed by responses on the list: - FL ECS 6.6.0 with Service Pack 1. - Windows NT 4.0 Server with Service Pack 5 (IE 5.0 with SP1, but that is [hopefully] irrelevant). - Compaq ML370 with 1GB RAM and a monster of a RAID 5 drive whose size I do not recall. - I do not have a tag count at hand (to be honest, I never really count them), but I should note that the we do not feel that the application is really not that heavy with DB activity, PLC activity, PowerVB activity or IML activity -- when compared with other SCADA applications we have produced. There really are not that many tags -- only two PLCs. As far as data polling from the PLCs, only about five to six thousand words are required per "scan". The PLCs in question are SIMATIC TI505 TI555s via the third-party Dastec Ethernet driver. - USData just sent us a patch (post SP1) to improve the performance of PowerVB this morning. We will install it on site next week. - The network should not be interfering with WebClient. The entire system runs on a dedicated network -- one (Cisco) switch, only three WebClient OSs (WebClient running on WinNT 4.0 Workstation with SP5 Plain Vanilla -- no other applications whatsoever), one server and three PLCs. The server has to NICs -- one subnet for two PLCs and the other subnet for one PLC and the OSs. There is no connection to the MIS network or the plant router and so on at the current time. The only time we have any transaction problems is when we are naughty and make the MPS file while FactoryLink is running (not encouraged behaviour, but sometimes some of the guys do it). - As far as PowerNet or other approaches, the system is on site with the customer and any extensive modifications or an alternative approach to design are not feasible. Thanks for the responses so far, RJ
 
R

Ranjan Acharya

More information for those who are interested: ================================================== The bug with PowerVB is still outstanding. A patch provided by the Tier 1 support is pre-SP1 (FL ECS 6.6.0 SP1) and of no use. Note that the bug occurs after GRAPH.EXE has been loaded for some time (remote WebClient sessions or local session on the server) and manifests itself as: error 32767 in script user:file.pls LIBRARY at line -168 running event CLICK for user:file.g #XXX Description: Invalid PowerVB tag extension object Note the error number and negative line number. This bug makes the system less than useful. Has anyone else seen this bug? ================================================== Another bug is the lost click event. This one seems to be curable by re-writing PowerVB to include as few Critical Blocks as possible. However, this may have not entirely eliminated the problem. Any hints? ================================================== Another error we are chasing is the occasional shut down of either the WebClient or the server -- this is not acceptable for a continuous operation. Apparently other list people have seen this bug. ================================================== Regards, RJ
 
T

Tony R. Gunderman

We also use the FactoryLink HMI with Simatic 505 controllers. Our primary system design is Simatic 555-1106 with H1 Ethernet comm modules and the DeltaLink RAPD S5/S7 (with 505 support)driver on FactoryLink. We are also experiencing the WebClient disconnect. We use the WebClient control embedded in an in-house VB app that allows us to monitor for errors on the control so that we can automatically switch to a backup server if needed. It also lets us manage settings files for easily connecting to different systems simultaneously from the same client machine. The error message associated with our disconnects is "Failure to send packet". The system layout is two entirely separate FactoryLink systems connected to 4 Simatic 555-1106 PLCs with two H1 Comm modules in each PLC. The PLCs have no local base I/O other than the comm modules. The number of attached remote I/O racks varies between the PLCs from 7 to 11 racks. The FactoryLink servers connect to the H1 modules using a separate NIC and a 10Base2 network. Each of the servers is then connected via another NIC to a 100 MB Ethernet switch. This switch has 6 WebClient PCs attached directly to it using 100BaseT Ethernet. It also has an uplink to our plant network at 10 MB so that we can attach with additional clients from anywhere. This is a fairly large application and receives quite a bit of operator interaction. However, the switch indicates no collision activity. The transaction error occurs whether connected to the primary or backup server and is seemingly random on the individual clients. Our Tier 1 contact has said that we have a network problem and should attack if from that perspective. However, we have experienced the problem with the network isolated to a local workgroup and with different hardware components, so we are having a hard time believing that. However, we are not Ethernet experts, so we have not entirely ruled that out either. We seemed to have slowed the problem by pre-populating the NT HOSTS file on the servers and clients to avoid issues with name resolution. We went for an extended period of time without any errors. However, we experienced one today, so I suspect the problem is not completely solved. I am interested in hearing of the details if you have any success. Maybe the HOSTS file tack will help in your case. If you have additional information, feel free to contact me off-list. Tony R. Gunderman Arkansas Eastman Division Eastman Chemical Company mailto::[email protected] or mailto::[email protected]
 
Top