none
WEC7 USB Printer Reconnect Issue RRS feed

  • Question

  • On Windows Embedded Compact 7, when a printer's (Zebra TTP2130) USB cable is unplugged and then plugged back in the virtual LPT port becomes available again but it comes back write-only, even though we are opening with the same call:

    CreateFile("LPT1:", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);

    This is an issue with the standard usbprn class driver with Windows Embedded Compact 7 Update Dec 2016. 

    The printer itself isn't in a bad state, as a unplug, reboot, plug cycle with the printer remaining powered works fine.

    When reproducing this issue, sometimes the detach isn't triggered if it is plugged back in too quickly, so it seems like the reconnect worked. If a minute is given for the detach to complete, it shows the issue.

    Is there a workaround for this?

    Friday, March 24, 2017 3:01 PM

Answers

  • Hi PS800,

    Excellent! Your reseller should be your best path of support as they will know more about your particular set up.

    My question about the services/drivers was around an issue I have seen with things like Modems.  My suspicion is that "LPT1" was designed with a more permanent connection expected (Like Parallel / Serial Ports of old) and only half of the connection is being brought down when you pull the USB device. To debug this you will need to start from zero, add the device, use it, remove the device. Now compare the situation to your original observations at zero. If you see something at this point that is likely what is not allowing the connection to go back to zero.

    If you have access to debug the OS and you really want to dig in, you could try turning on profiling and see what the system is up to while this is all going on.

    Sincerely,

    IoTGirl




    Monday, March 27, 2017 9:34 PM
    Moderator

All replies

  • Hi PS800,

    It sounds like the whole LTP stack and USB stack are not being cleared.  Can you try a few things?

    1.  Watch the services that are launched on initial insertion.  When the USB device is removed, do all of those services stop as well?

    2. If it comes back as "Write Only" what return value do you get from the create file call if you call "Generic_Read" only?  How do you establish that it is write only?

    3. If you are not the OEM of the device you should be working with the OEM to trace the connection teardown and bring up to identify the source of the behavior.  The OEM should reach out to the License reseller for further support.

    Sincerely,

    IoTGirl

    Friday, March 24, 2017 4:30 PM
    Moderator
  • 1. I didn't see any changes when I ran services.exe list in the command prompt. This probably isn't what you were referring to. Can you clarify?

    I did see two of the following pop up in CeLog after reconnect:

    DEBUGMSG: PID=0x052F0062 TID=00400002 WARNING: HcdOpenPipe(): OpenedPipesCache full; increase 'HcdPipeCache' value in the registry.

    I poked around in the registry and saw the default cache size for EHCI was 8. Bumped it up to 64 (we have a ton of devices anyway) by adding the following to platform.reg:

    [$(PCI_BUS_ROOT)\Template\ehci]
       "HcdPipeCache"=dword:40

    The warning went away, but the reconnect behavior is still the same, so no luck there.

    2. Came to the "write-only" conclusion after observing all read attempts timeout and return zero bytes after reconnect. The printer only sends data when it is issued a request, so removing GENERIC_WRITE and leaving it as GENERIC_READ only doesn't yield any information.

    3. I'll reach out to the reseller and see what they say.

    Monday, March 27, 2017 9:00 PM
  • Hi PS800,

    Excellent! Your reseller should be your best path of support as they will know more about your particular set up.

    My question about the services/drivers was around an issue I have seen with things like Modems.  My suspicion is that "LPT1" was designed with a more permanent connection expected (Like Parallel / Serial Ports of old) and only half of the connection is being brought down when you pull the USB device. To debug this you will need to start from zero, add the device, use it, remove the device. Now compare the situation to your original observations at zero. If you see something at this point that is likely what is not allowing the connection to go back to zero.

    If you have access to debug the OS and you really want to dig in, you could try turning on profiling and see what the system is up to while this is all going on.

    Sincerely,

    IoTGirl




    Monday, March 27, 2017 9:34 PM
    Moderator