FactoryTalk View Studio SE的问题 点击:9909 | 回复:2



yql19880721

    
  • 精华:0帖
  • 求助:1帖
  • 帖子:1帖 | 2回
  • 年度积分:0
  • 历史总积分:35
  • 注册:2010年11月23日
发表于:2012-09-23 09:20:28
楼主

FactoryTalk View Studio SE  网络类型  打开应用程序 无法加载HMI服务器。

本地类型时   显示  失去服务。计算机SFJN(我计算机名字)上的服务器RNA://$local/sfjn001(项目名字):sfjn未加载。




841455969ai

  • 精华:0帖
  • 求助:0帖
  • 帖子:0帖 | 6回
  • 年度积分:0
  • 历史总积分:26
  • 注册:2012年9月29日
发表于:2012-09-30 15:09:19
1楼

Problem

One of the following error messages appears when trying to open an application in FactoryTalk View Studio:

  • Failed to load HMI Server service
  • Cannot connect to addin object, Name: Application Handler, Cause: 80042089
  • Server verification has failed,
  • Studio may hang on opening (while loading services)
  • Failed to instantiate service
  • Failed to load data server rshmi.tag server

The following error mesage appears when creating new local (standalone) or network (distributed) application

  • Failed to instantiate HMI Server

Alternately, Studio may hang on opening (at around 70%) without any error message.

This behavior is observed on a busy system, typically a laptop, that is simultaneously running services associated with various software applications ranging from:

  • Third party VPN services
  • iPod services
  • CAD software
  • a variety of third party HMI software, such as:
    • iFix
    • Siemens
    • Wonderware, and etc.

In addition, the following error message has also been seen in association with the root cause described below:

Cannot connect to addin object
Name: Application Handler
Cause: 80042089

Enviroment

  • Microsoft Windows XP Professional
  • Microsoft Windows Server 2003 Standard Edition
  • FactoryTalk View SE 5.x
  • FactoryTalk View ME 5.x

Solution

The behavior is caused by the system running out of so-called desktop heap. Aside from a visible desktop that hosts windows, menus, hooks strings, etc. there are also invisible desktops running under non-interactive Windows stations. These can be thought of as a collection of desktops associated with different processes.

All Rockwell services, and there are a number of them, run under LocalSystem account and that the checkbox Allow Service to Interact with the Desktop is not checked.

As such, Rockwell services require desktop memory from the special section of the desktop heap memory which is limited to 48Mb. The memory from this pool is assigned to the requesting non-interactive services in 512Kb portions by default.

However, the system-wide buffer of 48Mb is also serving other types of third party services:

  • Some services may also be running under LocalSystem.
  • Some may be running under different user account context and with services being allowed to Interact with the Desktop.

On a busy machines, the total desktop heap might be exhausted prematurely, before Rockwell (non-interactive services) has a chance to allocate required desktop heap for their own needs.

Desktop Heap Allocation in the Registry

The size of each desktop heap allocation is controlled by the following registry value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

Default Registry Value

The default data for this registry value will look something like the following (all on one line):

%SystemRoot%\system32\csrss.exe
ObjectDirectory=\WindowsSharedSection=1024,3072,512
Windows=On SubSystemType=WindowsServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=OffMaxRequestThreads=16

The solution is to modify the SharedSection value (highlighted in the registry key above) by increasing its third value (highlighted in blue) from 512 to 1024. The modification has been already included in the attached registry key. After the registry is applied, a reboot is mandatory.


bangwanle

  • 精华:0帖
  • 求助:0帖
  • 帖子:2帖 | 4回
  • 年度积分:0
  • 历史总积分:98
  • 注册:2017年12月04日
发表于:2019-02-26 11:14:36
2楼

未加载这个问题怎么解决的啊


热门招聘
相关主题

官方公众号

智造工程师