Re: [foxboro] WP51 Keyboard lockups


Well, this is interesting.  I had this exact thing happen when I was trying
to set up Foxview/Foxdraw on an AW a couple months back.  We were thinking
about converting, and I wanted it on one station so that new graphics could
be built.  After I got in and out of Foxdraw a few times, the GUI would
lock up as you described -- no keyboard or mouse input was accepted.  I
could kill the Foxdraw process from another station, but the box was still
flaky and required a reboot.  I attributed it to problems in Foxdraw
(rightly, maybe) and decided to postpone our conversion.  BTW, the box was
an AW51E.

Corey Clingo
Sr. Engineer
BASF Corp.



|---------+----------------------------->
|         |           tom.vandewater@dow|
|         |           corning.com       |
|         |           Sent by:          |
|         |           foxboro-bounce@fre|
|         |           elists.org        |
|         |                             |
|         |                             |
|         |           07/18/2002 09:15  |
|         |           AM                |
|         |           Please respond to |
|         |           foxboro           |
|         |                             |
|---------+----------------------------->
  
>-------------------------------------------------------------------------------------------------------------------------------|
  |                                                                             
                                                  |
  |               To:  foxboro                                                  
                                                  |
  |        cc:                                                                  
                                                  |
  |        Subject: [foxboro] WP51 Keyboard lockups                             
                                                  |
  
>-------------------------------------------------------------------------------------------------------------------------------|





List,
 I have been watching all of the dialog fly about the WP51 keyboard
and mouse lockups with a measure of disbelief.  When the new and improved
Alarm Manager and Foxview were introduced so was this problem and is not
specific to "B" style boxes.  It happens on "D" boxes also.
"The problem is related to Motif applications such as Foxdraw, Foxview,
Alarm Manager, and Alarm Configuration Tools on Solaris."
 The thing that amazes me is just like all of you other users out
there, we had to find the problem ourselves and absolutely describe it to
Foxboro before they told us that they already knew about it and had
developed a workaround.  We chased our tails thinking that we had bad
keyboard cables, keyboards or other hardware problems and when I hear all
of
you going through the same pain it really ticks me off.  The symptoms are
so
intermittent and unpredictable that it is difficult for anyone to describe.
It leads most people to believe that it is a physical problem with the
keyboard bus.
 The problem was known by Foxboro at the time of the release of the
above mentioned applications or shortly thereafter.  They blame the problem
on Solaris but they have provided both Solaris and Motif window
applications
as a solution and should be held accountable for that.  The problem has
never been fixed and the workarounds described below in Helpful Hint 864
only mask the real problem.   I know that there are many Foxboro people
that
subscribe to this list and have a hard time believing that none of them
know
about this VERY COMMON problem.  I was waiting to see if any of them would
step up to the plate and pass the information on to struggling users and am
greatly disappointed to see that it hasn't happened. There have been many
CAR's written on this problem and the workaround below is the best that
Foxboro has provided and is unnacceptable to us.  Although it does reduce
the frequency of the lock-ups it doesn't fix the problem and thus reboots
are still required!!!  The "Follow Mouse" window focus has caused much
frustration among users that use more than a single window.
 So fellow users, quit spending time looking for faulty keyboard
cable connections and start sending CAR's to Foxboro to voice your concerns
about this ongoing problem.  It is our only recourse.  Don't accept the:
"This CAR is now closed. " answer that we have been programmed to think is
the "final answer"!

Tom VandeWater
Dow Corning Corp.
Carrollton, KY USA

HH#:  HH864
                                    IA INFO:  kjb9703a
                                       File:  System
                                    Release:  All
                                       Date:  Dec. 18, 1997
Subject:  Cursor Lockup
 Source:  SD&E
                             CURSOR LOCKUP
There are two workarounds that solve the cursor lockup issue.  One is to vi
the .Xdefaults file and the other to change the workspace property for
cursor input.

It is recommended that the .Xdefaults be done first. This has either
resolved or has greatly reduced the occurrence of the cursor lockup
problem.

If the .Xdefaults did not solve the problem entirely than do the workspace
properties workaround. Be sure to verify that the .Xdefaults was done
correctly.  We have had cases were the upper and lower case letters and
underscores were not done correctly.

                             CURSOR LOCKUP
Two problem have been discovered which can cause the OpenLook window
manager to " hang" .  When the window manager is hung,  all mouse clicks
and keyboard inputs are ignored until the offending application is killed
or the machine is rebooted.

The problem is related to Motif applications such as Foxdraw,  Foxview
,Alarm Manager, and  Alarm Configuration Tools on Solaris.

  Problem #1 workaround

The workaround for this problem is to edit the file " /.Xdefaults

1. Open a VT100 window.
2. Change directory to the root directory .       cd /
3. Edit the /.Xdefaults file to include (or modify) the following two lines
   exactly as they appear here (be careful about the underscores and
   upper/lower case letters).  (Note: the "." character makes this file
   invisible to an "ls" command ).
4. vi  .Xdefaults
5. Make edits such that the following lines appear exactly as they do
   below:
      olwm.Modifier.WMGrab:
      olwm.Modifier.Ignore:   mod5,Alt,Num_Lock,Mode_switch,Lock
6. After completing the edits, reboot  the workstation.

  Problem #2 workaround

The second defect is related to handling of rapid mouse clicks by
the window manager and can be avoided entirely by setting the window focus
property to "move pointer" as follows:

1.  From the Workspace menu (click the right mouse button with the mouse
cursor on the blue "background" screen), and  select "properties...".

2.  On the resulting "Workspace Properties" dialog, click on the
"Category"
icon and select "Miscellaneous" from the drop-down menu.

3.  On the "Miscellaneous" page, under "Set Active Window" , click the
"Move Pointer" button.

4.  Select the "Apply" button at the bottom of the dialog box to apply
the change.

5.  Click on the "pushpin" in the upper left corner of the dialog to
dismiss the dialog.

This will put the workstation in the "follow mouse" mode. In this
mode,keyboard focus belongs to the window which contains the mouse
cursor.

Note that if the mouse cursor is accidentally moved,keyboard input can
inadvertently go to another window.




 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: