Jump to content

RWAP

Members
  • Posts

    22
  • Joined

  • Last visited

Recent Profile Visitors

1051 profile views
  1. I have upgraded the image to v4.7.3 with apt-get upgrade
  2. The config file can be viewed at: http://www.rwapservices.co.uk/docs/bpi_config.txt
  3. Unfortunately, I am not sure what settings I used to compile the kernel (it was based on the same download as you used) - I simply enabled what seemed to be obvious requirements for the gadget printer and it worked - I have since tried to recompile it, but could not get the compiled version to install the g_printer device, so there was something I missed. Is there any way of discovering what settings were used? Have you tried reinstalling the printer driver under Windows once you connect the Orange Pi and/or changing the port used for the printer? With the SNBC printer, this seemed necessary - possibly because they install their own virtual printer (instead of using the standard Windows USB0001 virtual printer)!
  4. Which printer are you using? Even more oddly I sent the image dump of my SD card to my customer to try on their computer with similar SNBC printer and it worked. I wonder if it is something in the Windows 10 update which was installed this week which has prevented it working...
  5. Compare that to the USB Treeview for the actual USB printer when connected directly: Device Descriptor: bcdUSB: 0x0110 bDeviceClass: 0x00 bDeviceSubClass: 0x00 bDeviceProtocol: 0x00 bMaxPacketSize0: 0x40 (64) idVendor: 0x154F idProduct: 0x0517 bcdDevice: 0x01F0 iManufacturer: 0x01 0x0409: "BEIYANG" iProduct: 0x02 iSerialNumber: 0x00 bNumConfigurations: 0x01 ConnectionStatus: DeviceConnected Current Config Value: 0x01 Device Bus Speed: Full Device Address: 0x06 Open Pipes: 3 Endpoint Descriptor: bEndpointAddress: 0x02 OUT Transfer Type: Bulk wMaxPacketSize: 0x0040 (64) bInterval: 0x01 Endpoint Descriptor: bEndpointAddress: 0x82 IN Transfer Type: Bulk wMaxPacketSize: 0x0040 (64) bInterval: 0x01 Endpoint Descriptor: bEndpointAddress: 0x85 IN Transfer Type: Bulk wMaxPacketSize: 0x0040 (64) bInterval: 0x01 Configuration Descriptor: wTotalLength: 0x0027 bNumInterfaces: 0x01 bConfigurationValue: 0x01 iConfiguration: 0x00 bmAttributes: 0xC0 (Bus Powered Self Powered ) MaxPower: 0x32 (100 Ma) Interface Descriptor: bInterfaceNumber: 0x00 bAlternateSetting: 0x00 bNumEndpoints: 0x03 bInterfaceClass: 0x07 bInterfaceSubClass: 0x01 bInterfaceProtocol: 0x02 iInterface: 0x00 Endpoint Descriptor: bEndpointAddress: 0x02 OUT Transfer Type: Bulk wMaxPacketSize: 0x0040 (64) bInterval: 0x01 Endpoint Descriptor: bEndpointAddress: 0x82 IN Transfer Type: Bulk wMaxPacketSize: 0x0040 (64) bInterval: 0x01 Endpoint Descriptor: bEndpointAddress: 0x85 IN Transfer Type: Bulk wMaxPacketSize: 0x0040 (64) bInterval: 0x01 Any suggestions as to how I get iProduct to be the same ( I pass a null character for this, in the same way as I do for iSerialNumber)
  6. I have resolved the warning in dmesg by adding a sleep command in my shell script after I call the modprobe g_printer, and before I launch my interceptor program (based on the prn_example). However, I still can't get Windows 10 to recognise the device as the printer (still reports printer not available) like it did on the weekend.... USB Treeview shows: Device Descriptor: bcdUSB: 0x0200 bDeviceClass: 0x00 bDeviceSubClass: 0x00 bDeviceProtocol: 0x00 bMaxPacketSize0: 0x40 (64) idVendor: 0x154F idProduct: 0x0517 bcdDevice: 0x01F0 iManufacturer: 0x01 0x0409: "BEIYANG" iProduct: 0x02 0x0409: "" iSerialNumber: 0x03 bNumConfigurations: 0x01 ConnectionStatus: DeviceConnected Current Config Value: 0x01 Device Bus Speed: High Device Address: 0x05 Open Pipes: 2 Endpoint Descriptor: bEndpointAddress: 0x81 IN Transfer Type: Bulk wMaxPacketSize: 0x0200 (512) bInterval: 0x00 Endpoint Descriptor: bEndpointAddress: 0x01 OUT Transfer Type: Bulk wMaxPacketSize: 0x0200 (512) bInterval: 0x00 Configuration Descriptor: wTotalLength: 0x0023 bNumInterfaces: 0x01 bConfigurationValue: 0x01 iConfiguration: 0x00 bmAttributes: 0xE0 (Bus Powered Self Powered Remote Wakeup) MaxPower: 0x01 (2 Ma) Unknown Descriptor: bDescriptorType: 0x09 bLength: 0x03 03 09 03 Interface Descriptor: bInterfaceNumber: 0x00 bAlternateSetting: 0x00 bNumEndpoints: 0x02 bInterfaceClass: 0x07 bInterfaceSubClass: 0x01 bInterfaceProtocol: 0x02 iInterface: 0x00 Endpoint Descriptor: bEndpointAddress: 0x81 IN Transfer Type: Bulk wMaxPacketSize: 0x0200 (512) bInterval: 0x00 Endpoint Descriptor: bEndpointAddress: 0x01 OUT Transfer Type: Bulk wMaxPacketSize: 0x0200 (512) bInterval: 0x00
  7. I obviously spoke too soon - whilst it was working this weekend, today, it has stopped being recognised as the original printer. We did not install a device controller, but you can see from the dmesg screen dump below, what modules are enabled. The image was based on 4.6.3-sunxi There is also a warning message in dmesg which is puzzling - I am sure that was not there last weekend when the device worked properly (although I might have missed it)...: Any suggestions as to what causes this warning - interceptor is my own C program ?
  8. Yes my application works with the BananaPi connected to Windows - it could of course be a difference between the BananaPi and the Udoo Neo board.
  9. That looks about correct - although the iSerialNum is better in quotes. We then use the capture routine by Craig Nadler which you can find at: https://www.kernel.org/doc/Documentation/usb/gadget_printer.txt I guess your problem is that Linux is not telling Windows that the printer is available for printing....
  10. We have recently got this working on the BananaPi - it takes a lot of setting up to do this. DId you check dmesg | grep printer to see if the g_printer module is correctly set up and running (that is the first issue). What parameters are you then passing (if any) to do the modprobe g_printer command?
  11. Yes I realise pulling the plug is not the best way of doing it and should be avoided - it was more a case of trying to replicate something I had noticed following a power cut. What concerns me is how to safeguard the data against loss in the event of a power cut (or user simply unplugging the device)? There must be a flush command, which is used during the shutdown / reboot process....
  12. Ah - I realised that after I had written it - the writes to the SD card must be buffered somewher - is there a command to flush the buffers to the SD Card? Does anyone know why the relative path in rc.local works if the device is rebooted, but not if the device is started from cold?
  13. I am still having some problems here... a) I have a custom /etc/rc.local which contains two simple lines: sudo /g_printer_define.py exit 0 g_printer_define.py is a Python program which reads and sets the printer parameters Now, I had an error in g_printer_define.py around the lines: filname = '/devicecall.sh' f = open(filname, 'w+') f.write('modprobe g_printer ' + callString +'\n') f.write('./interceptor -read_data') f.close() If I boot the BananaPi having turned it off completely, this gave an error - basically reporting ./interceptor could not be found (it is in the root directory). However, if I turn off the BananaPi (unplug it) and plug it back in, the program runs as expected. Now even more confusing was that having spotted this issue, I altered the above code to read: filname = '/devicecall.sh' f = open(filname, 'w+') f.write('modprobe g_printer ' + callString +'\n') f.write('/interceptor -read_data') f.close() This worked fine, but then having gone away from the system and turned it back on today, I was surprised that the original version of the Python program was back!! How / why does this sometimes happen? I have noticed it when changing the rc.local file for example.... - the file can be returned to an earlier version!
  14. SNBC were actually very responsive and gave me a pointer to the correct solution for this. Basically, their printers support two modes - the API mode and a Windriver mode. You can check which mode it is in by performing a self-test. For unix based systems, the printer has to be in Windriver mode. Once I changed this over, the system correctly inserted the printer as /dev/usb/lp0
  15. I am trying to connect a SNBC receipt printer to my Banana Pi - model number: BTP-r580(II) However, dmesg shows that whilst it is identified as a USB device, it is not identified as a printer (probably not helped by the fact that all of their receipt printers appear to have idVendor = 0x154f and idProduct = 0x154f Whilst their website (http://www.newbeiyang.com) has downloads for linux drivers, once connected there is no /dev/usb nor a dev/ttyUSB0 directory (in case it is recognised as a serial device). The linux drivers appear to be used for CUPs which is not installed, so I have not downloaded them. Someone else has the same problem on the Raspberry Pi with a differernt printer from this manufacturer - https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=119253 Where should I go from here?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines