Discussion Groups

7535 Lock-h problem

This question is answered

Hi,

We have been using 7535 terminals with SAP for some time now. Recently, while using the handheld the message LOCK-H is showing on the screen.

Several times a day the terminal hangs with the LOCK-H message showing and a restart is necessary.

The handhelds are connected via WIFI connection with strong signal all the time.

Can anyone tell me what could be the cause of the problem and if there is anything specific that can be done to debug the problem.

Any help would be appreciated.

Daniele

 

Verified Answer
  • Thank you for the replies Lana and Blake. We are using 7535 G2 terminals.

    I think that we have now fixed the problem :). It was difficult to debug and understand as the LOCK-H problem was not consistent, in that:

    1.it only presented itself four or five times a day, for the rest of the transactions there were no problems. 2.ping from the terminals to the server seemed to work fine, without packetloss

    However a number of different things had happened simultaneously, which made the problem hard to debug:

    1.The handhelds are on a remote site and communicate with the server across the internet using a tunnel. At about that time we changed service provider and we unsure if there were communication problems.

    2.Our wireless router packed in and had to be changed adding another variable.

    3.A new terminal had been added to the network.

    For others that might experience a similar problem here is what the problem seems to have been:

    The terminal that had been added to the network, had its configuration copied from one of the terminals already present. The "terminal id" was also copied without modifying it.

    The problem seems to have disappeared since we have given the terminal a new id. I thus assume that the problem arose only when both terminals tried to communicate with the server simultaneously, and thus the randomness of the problem.

    thanks again for the suggestions and help.

    Daniele

All Replies
  • Hi Daniele ,

    I assume that you are  MIS/ tekconsole.Can you recall when this issue started?

    Did you have any network configuration changes?

    Does it happen in certain transactions , certain time of the day , or it follows some terminals?

    Can you describe your network back bone and provide software version on your teklogix equipment?

     

    Lana

     

    Help Desk

     

  • If everything was working fine previously, then your problem is not with the handheld or the wireless connection most likely.  Probably something changed in the wired network (switches, firewall, etc.) so that now your wireless packets are getting dropped or delayed.  If you can determine when the problem began and then corelate that to a change in the network, you can probably determine the root cause.  A continuous ping from the handheld can also help reveal a network problem.

  • Thank you for the replies Lana and Blake. We are using 7535 G2 terminals.

    I think that we have now fixed the problem :). It was difficult to debug and understand as the LOCK-H problem was not consistent, in that:

    1.it only presented itself four or five times a day, for the rest of the transactions there were no problems. 2.ping from the terminals to the server seemed to work fine, without packetloss

    However a number of different things had happened simultaneously, which made the problem hard to debug:

    1.The handhelds are on a remote site and communicate with the server across the internet using a tunnel. At about that time we changed service provider and we unsure if there were communication problems.

    2.Our wireless router packed in and had to be changed adding another variable.

    3.A new terminal had been added to the network.

    For others that might experience a similar problem here is what the problem seems to have been:

    The terminal that had been added to the network, had its configuration copied from one of the terminals already present. The "terminal id" was also copied without modifying it.

    The problem seems to have disappeared since we have given the terminal a new id. I thus assume that the problem arose only when both terminals tried to communicate with the server simultaneously, and thus the randomness of the problem.

    thanks again for the suggestions and help.

    Daniele

  • Hi Daniele,

    Welcome to our community!

    We are all glad to know that the issue has now been resolved.

    About the Open Tekterm (OTT) terminal-emulation software Terminal Number, per the user manual, For every application session you create, the Terminal Number assigned must be non-zero and unique. This parameter defines the number for the ANSI or TESS session and uniquely identifies all transmissions to and from the session. Other OTT sessions running in the computer, another ANSI or TESS session, must each have a different number. In addition, each device using the radio link must have a unique number.

     

    Cheers,

    Luke - Help Desk

     

    Americas Help Desk

       

    This posting is provided "AS IS". No Warranty. No Guarantee. Maybe updated or changed without notice at any time. You can use the information provided at your own risk.