WT4070/4090 How does one notify user that scanner is non-functional or disconnected programmatically?

Customer would like a screen to pop up whenever the scanner is not functional (breaks or is disconnected from the unit).

Juliet Chon
Per the lead SW engineer:

Per the lead SW engineer: "You really have to wait for the timeout to occur. There's probably a registry setting to reduce the timeout but it's been set this way to allow the scanner to go through all of the baud rates in case somehow the engine communication was reset without the driver knowing about it. In this case, the driver could possibly re-establish communications with the engine without removing power."

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Juliet Chon
More detail on this: The best

More detail on this:

The best way to tell if the scanner is connected:

Perform a SCAN_Enable (in the API set) and it will return a value of E_SCN_DEVICEFAILURE (which = A000000B) if the scanner is not there.  

If the scanner is there, it returns E_SCN_SUCCESS (=0) if the scanner is there.

Also, there are some other API functions that should return similar errors when the scanner isn't connected, and the lead SW engineer thinks that they're not right now.  He is looking into this.  Stay tuned...

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Anonymous (not verified)
Unlike other Symbol devices

Unlike other Symbol devices that have embedded scanners that don't go away, applications on the WT need to be aware that the scanner may not always be there when expected.  I ran into this recently on the WT with ESP's Stay-Linked emulator.  We found a couple conditions where the application failed to enable the scanner:

Condition #1

  1. User starts Stay-Linked which puts the scanner in the read state (i.e. trigger fires the laser)
  2. User disconnects the scanner from the WT (why?...because they can)
  3. User Suspends and then Resumes the unit
  4. The trigger will no longer fire the laser


If the user doesn't Suspend and Resume the unit, then everything works okay.  I'm not sure why this is the case.

Condition #2

  1. User starts Stay-Linked with the scanner disconnected.
  2. If the scanner is then connected to the unit, the trigger will fail to fire the laser.

ESP has added additional logic in Stay-Linked to resolve these issues now.  For Condition #1, after a Resume they will re-initialize the scanner.  For Condition #2, if they fail to get a handle from the scan driver at start up, they will re-attempt to find the scanner every X seconds.  I think the default is set to 10 seconds.  There is a parameter that can be set to adjust this timer value.

I should mention that Stay-Linked is not the only application I have seen these issues on.  A customer's C# application that was originally written for the MC9000 also exhibits the same behavior under the conditions listed above.  I haven't tested the above conditions with Wavelink TE.  Maybe someone else has and can post their results.

It may help if someone from the Engineering team can publish some modified scanner sample code for C and .NET to show best practices on how to handle these conditions on the WT.  I would imagine that whatever additional code we need to add to support these conditions would also work on other devices (i.e. MC9000, MC3000, etc.).

Thanks,

Ken

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Anonymous (not verified)
I just did a quick test with

I just did a quick test with Wavelink TE version 5.11-22 (included with Rev A OS image).  It has the same problem with the two conditions.  I've opened up case #1285231 with the CIC.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Topic locked