Connecting a Receipt Printer

[RWAP]

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?

[RWAP]

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

 

[RWAP]

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!

[gnasch]

turning off without using sync first, buffers not written to the sdcard?

[Igor]

turning off without using sync first, buffers not written to the sdcard?

 

If you just cut the power you ask for problems. Issuing a shutdown or reboot is o.k.

[RWAP]

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?

[tkaiser]

is there a command to flush the buffers to the SD Card?

 

For your specific use case (cut the power without shutting down Linux correctly) it would read 'poweroff'. Really, if you just pull the plug you're asking for trouble. Rather sooner than later the installation on SD card will be broken anyway.

 

And your 'strange' behaviour with files reverting to their previous version is simply caused by Armbian using a 10 min write commit interval for the SD card and you obviously pulling the plug too early (use reboot/poweroff instead!)

[RWAP]

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....

[tkaiser]

What concerns me is how to safeguard the data against loss in the event of a power cut (or user simply unplugging the device)?

 

The command is called sync and you could also adjust /etc/fstab contents to change ext4 settings. But if you care about this you fortunately chose the right device (BPi M1 has AXP209 PMIC + solder pads for a LiPo battery). Solder cables to a battery, write a script monitoring battery capacity to initiate a clean shutdown and you're done.

 

Banana Pi/Pro like many other AX209 equipped boards power connected USB consumers also when running on battery so check your consumption requirements first to choose a battery with appropriate capacity.