I manage 42 Windows 7 R5500 DeltaV operator workstations (v11.3.1) and have noticed that they tend to perform better if the Windows environment is restarted on occasion. Most of the time, the workstations will just run 24/7 until something crashes. Then they get restarted.
I am working on writing 2 scripts: One that will restart the operator station when a button is clicked on a graphic and one that will kill Workspace.exe and start it again. I have some .bat files and .vbs files that will do both, but so far have failed to successfully implement the code to execute these programs from DeltaV Operate.
Here's what I have written so far:
<code>
Private Sub bmpRestart_Click() On Error GoTo ErrHandler FrsRunTask “d:\Scripts\Restart.bat”, , True End Sub
</code>
On running the script, I get a compile error.
Has anyone successfully run a .bat or .vbs file from the DeltaV Operate environment? If so, how did your code look?
James Suisse
Windows batch/command files and vbs or other scripts are not executables and can't be run by frsRuntask. You must specify the appropriate command intepreter with the script file as an argument. for instance:
cmd /c filename.bat
or
wscript filename.vbs
You may need quotes in the script filename if the full path has spaces. Refer to the cmd and wscript instructions on properly passing the arguments.
Now, to the issue of why you have to reboot....
what type of investigation into the nature of the workstation failures have been conducted? Are you exhausting memory, is the DeltaV service throwing errors, etc? Are your workstations installed with all the latest patches?
I once had a client who had workstations become unresponsive after a few months of uptime. Turned out they would invoke the OSK.exe automatically with every operator input, but never closed it. The workstation would exhaust all resources after several thousand OSK.exe's were running behind the graphics.
In addition to Youssefs comments.
I note you have a Goto ErrHandler line but no ErrHandler: label
That would likely be the reason for your compile error.
Before the End Sub line, insert the following three lines of code
Exit Sub
ErrHandler:
frsHandleError
In reply to IntuitiveNeil:
yeah, turns out I was mistaken; I can launch a .bat file without the command interpreter specified first using frsruntask. Neil's got the compile error covered, it seems.
In reply to Youssef.El-Bahtimy:
Shell "cmd.exe /C shutdown /r /t 0 /f",vbHide
But I would call Emerson Customer support to understand what is causing performance issues...
In reply to Lun.Raznik:
IntuitiveNeil,
You are very right in that I had failed to put in the error handler routine. Once added, it worked swimmingly. I was also able to use the Shell command that Lun suggested.
For anyone who is interested, here's my story on my apparent need to restart:
The amin reason for a script within DeltaV Operate is not to restart Windows, but restart Operate. The reason for this if anything happens to the Windows resolution even for a split second, the DeltaV Operate environment rescales itself and all 2-4 screens end up as a small window on the upper left corner of the left-most monitor. This can be caused by something as simple as bumping one of the DVI cables or our Avocent HMX receivers rebooting. Reset Layout will not resolve this. I need something more powerful than this. Hence, I created a vbs script to kill Workspace.exe and restart it. I just needed to link it to a "button" on the left side of my top-most toolbar so it would still be visible when graphics rescale.
While I was at it, I figured I would create a routine that would pop up a "restart request" graphic every few weeks. I was raised on Windows 95, 98, and ME. I found it was always best to restart Windows on a regular basis to clear any memory or program glitches. Windows was rife with "memory leaks" and instabilities related to prolonged run times. I haven't found anything definite stating the same for Windows 7, but our operators have noticed that over time, the workstation response tends to slow down until a restart. Also, our workstations occasionally get a few random errors like "Network Transaction in Progress" and fail to respond. Multiple calls to the GSC and 2 months with a resident Emerson engineer haven't totally solved our problems.
There you have it. Thanks everyone for your input.
In reply to James Suisse:
James,
The batch commands you are testing may very well help alleviate the symptoms of your workstations becoming sluggish. But, I would very much heed the suggestion to call the GSC to understand what is causing the issue.
I have worked on several different DeltaV systems for several years each (not v11 though). I never had to reboot often or restart Operate (or kill workspace) unless there was an underlying problem. We certainly didn't face issues of the system crashing over time.
Good luck,
Michael
In reply to Michael Moody:
With regards to restarting Operate, you always have the ability (no matter who is logged in) to use ALT+F4 to terminate operate. The user can then restart Operate after 20 seconds (about) using the Flexlock button.
I do have quite a bit of experience with DeltaV workstations (or the DeltaV services) needing to be restarted due to memory exhaustion, and other intermittent errors. Typically this is before the identification and remediation of a problem associated with a release, and patches are soon to follow.
The problem is that the nuisance of restarting periodically is often less trouble than fully chasing down the technical solution through GSC. It sounds like James has dilligently acted by reporting and following through on the issue, but has hit an impass.
If it hasn't already been suggested to you by Emerson, I suggest
1.rebuilding a small subset of workstations and comparing them against the others for performance tracking
2.keep an eye on the memory consumption of Workspace.exe. If this becomes high, then there may be a leak in some of your graphics.
Good luck.
Youssef,
I had never even thought of the <alt>+<F4> option. For the most part, the operators would either hard reboot the workstation (less desirable solution) or call me (better solution) and I would talk them through hitting <alt>+<tab> until the FlexLock is on top, clicking on the menu in the upper left-hand corner, then selecting "logoff Windows". You can imagine how difficult it is to explain <alt>+<tab> feature over the phone then talking them through logging in again.
I'll investigate the feasibility of this option. Thanks.