Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getBluetoothService() called with no BluetoothManagerCallback #16

Open
viktordineout opened this issue May 3, 2021 · 4 comments
Open

Comments

@viktordineout
Copy link

viktordineout commented May 3, 2021

Hi there :)

I'm calling checkStatus on a mPOP Bluetooth printer (POP10-OF).
The tablet is able to connect to it but when ever I check the status I get this message and after a few seconds it times out and crashes.

getBluetoothService() called with no BluetoothManagerCallback

The call looks like this:

await StarPrnt.checkStatus(portName: "BT:xxx", emulation: "StarPrnt");

Checking status on a LAN connected mC-Print3 works great though.

Any idea what could be causing this? Could it because the Android OS has already established a connection with this device and StarPrnt is trying to establish another one? This also happens when calling print on the Bluetooth printer.

P.s. I've also tested other emulation types such as StarPRNT, StarPRNTL & StarLine.

Thank you!

@viktordineout
Copy link
Author

This is very strange. It does not happen when I put a breakpoint into checkStatus in the StarPrnt package 🤔
Then everything returns normally.

@viktordineout
Copy link
Author

I think the culprit could be a loop which I use to call checkStatus periodically.
According to these docs, calling checkStatus while already connected could produce unexpected results:
https://github.com/auctifera-josed/starprnt#check-status

The checkStatus(port, emulation, success, error) returns the current status of the printer, as well as model number and firmware information. Checking status of a printer while connected to that printer can produce unexpected results.

Perhaps checkStatus could be implemented so that it gracefully returns results when already connected? @Eddayy

@Eddayy
Copy link
Owner

Eddayy commented May 4, 2021

Its probably due to the native implementation where it tries to establish a connection each time to check the status. I'll look into implementing the connect and disconnect function from that repo. Should provide a persistent connection instance to better check status.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants