Receipt printing connection close duration.

I'm currently working on an IOS app written in swift to print receipts using the Zebra ZQ520 printer with linkOS v1.4.948. Previously I was facing a problem that the printer sometimes does not print the receipt. The problem seems to be the connection is closed before all the data is sent. So what I did was setting a sleep duration before closing the connection. However this method does not seem to be reliable. Is there any way to check if all the data is sent to the printer before closing the connection? The following is my code:

 

func printReceiptLabel(completionHandler: (Bool) -> Void) {

        dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0)) { () -> Void in

            guard let conn = self.openConnection() else {

                dispatch_async(dispatch_get_main_queue()) {

                    self.displayAlertMessage("No printers found")

                }

                return

            }

           

            let open = conn.open()

            let receiptGenerator = ReceiptGenerator()

           

            if let receiptInfo = self.printReceipt {

                let receiptString = receiptGenerator.createReceiptString(receiptInfo)

                let receiptData = receiptString.dataUsingEncoding(NSUTF8StringEncoding) as! NSMutableData

               

                if open {

                    let blockSize = 1024

                    let totalSize = receiptData.length

                    var bytesRemaining = totalSize

                    var error: NSError?

                   

                    while bytesRemaining > 0 {

                        print("Bytes sent")

                        let bytesToSend = min(blockSize, bytesRemaining)

                        let range = NSMakeRange(0, bytesToSend)

                       

                       

                        let partialLabel = receiptData.subdataWithRange(range)

                        conn.write(partialLabel, error: &error)

                       

                        bytesRemaining -= bytesToSend

                       

                        receiptData.replaceBytesInRange(range, withBytes: nil, length: 0)

                    }

                   

                    NSThread.sleepForTimeInterval(NSTimeInterval(0.5))

                    conn.close()

                    dispatch_async(dispatch_get_main_queue(), { () -> Void in

                        completionHandler(true)

                    })

                } else {

                    dispatch_async(dispatch_get_main_queue()) {

                        completionHandler(false)

                        self.displayAlertMessage("Error connecting to printer")

                    }

                }

 

            }

        }

    }

Anonymous (not verified)
Hi Alexius,The newest version

Hi Alexius,

The newest version of the SDK 1.4.957 does attempt to fix this issue by introducing a standard delay before closing connection but we have had a very hard time testing this to ensure it fixes most of these issues because of the way iOS handles threads, GCD, and Bluetooth communication in general.  My recommendation is to try the new version to see if it fixes your issue.  Let us know if it doesn't.

Robin

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Ryan Killebrew
We are experiencing this

We are experiencing this exact same issue where the connection is closed mid-print. We are using the latest version of the SDK and cannot figure out what is causing the issue. Our app is Zebra approved and is currently in the Apple App Store. We are hearing from our customers that this is causing problems for them. Please help us to resolve this issue!

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Anonymous (not verified)
Hi Ryan, This has been a very

Hi Ryan,

This has been a very difficult issue for us to track down as we have not been able to fully recreate it in our test environment.  It seems to be a timing issue we have a difficult time recreating.  To help us better understand and make the better recommendations and fixes, can you try to get some information for us? 

1. What is the exact OS version(s) they are having the problem on?

2. Are they closing (or navigating away from) the app as soon as they are done printing?

3. Are they in Bluetooth heavy environments? Are there a lot of Bluetooth devices in the area? How many typically?

4. Which printer models are they using?  Can you find out exact part numbers and firmware versions?

5. Is the app heavily multi-threaded?

If you don't feel comfortable sharing this, message me directly.

Robin

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Ryan Killebrew
Hi Robin,1. We have seen this

Hi Robin,

1. We have seen this issue on iOS 8, 9 and 10. Specifically we are seeing the issue on our test device today running 10.0.1.

2. The app is locked into a "kiosk mode" and we even encourage the users to enable Guided Access to disable the home button and lock button. So this is not likely.

3. The app is typically used in a heavy bluetooth environment (church lobbies), however in our testing environment, it is not a heavy bluetooth area and we are seeing the problem consistently.

4. We are exclusively using the ZQ510 bluetooth model. We have encountered the issue on both V76.19.13Z and V76.19.15ZA firmware versions.

5. Yes the app uses quite a bit of multi-threading - server communication utilizing AF Networking, etc.

This morning we were able to find a work around by using a while loop to retry the connection when we detect it was lost. While this seems to resolve the issue, we are still seeing connection drop/reconnects about 75% of the time. This is not a desirable solution as the printing pauses briefly while the connection is restored. Our developer will respond to this thread with the solution we implemented and the errors we get when the connection is lost.

-Ryan

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Anonymous (not verified)
Thanks Ryan, We would

Thanks Ryan, We would appreciate it.

I'll see if I can have our test team focus on these areas.  Also if you are able to consistently see this in your test environment, we may use your app to test with as well.

Robin

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Ryan Killebrew
Robin,We would gladly send in

Robin,

We would gladly send in our app for you to test with. It is definitely easy to reproduce.

-Ryan

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Anonymous (not verified)
Also, How much total data are

Also, How much total data are you sending to print (in bytes)?

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Ryan Killebrew
We are sending between 340

We are sending between 340 and 360 bytes per label.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Anonymous (not verified)
Is this including images?  Do

Is this including images?  Do you often send multiple labels in an batch or within less than a second of each other?  I'm trying to rule out that the download size has anything to do with the issue.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Rodger Wilson
Robin, there are no images.

Robin, there are no images. It is all text that includes a barcode ZPL command. We print labels for a family but, from the printer's standpoint, they are sent individually. Basically, the flow is:

1) create a printer connection  ... _printerConn = [[MfiBtPrinterConnection alloc] initWithSerialNumber:printerSerialNumber];

2) get a pointer to the printer ...  _printer = [ZebraPrinterFactory getInstance:_printerConn error:&error];

3) check the status ...  PrinterStatus * status = [_printer getCurrentStatus:&printerError];

4) set up a loop that iterates for the number of people in the family (usually, 3 to 4) and print the label for each individually ...  [[_printer getToolsUtil] sendCommand:partialLabel error:&error];

About 75% of the time, the connection will disappear in the middle of the loop. We have found that by checking the status between labels we can discover the dropped connection and reopen it. Sometimes, it takes multiple attempts to reopen the connection.

When the connection is lost, we get an error about no connection or an error about malformed status

Error Domain=ZSDK_API_ERROR_DOMAIN Code=7 "Malformed status response - unable to determine printer status" UserInfo={NSLocalizedDescription=Malformed status response - unable to determine printer status}

Error Domain=ZSDK_API_ERROR_DOMAIN Code=0 "The connection is not open" UserInfo={NSLocalizedDescription=The connection is not open}

I can send you the exact language if it would be helpful. I wonder if the SDK is not retaining the connection and iOS is garbage collecting it and therefore it disappears.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Rodger Wilson
(No subject)

Screen Shot 2016-10-05 at 12.48.32 PM.png

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Rodger Wilson
(No subject)

Screen Shot 2016-10-05 at 12.48.46 PM.png

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Rodger Wilson
(No subject)

Screen Shot 2016-10-05 at 12.48.12 PM.png

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Rodger Wilson
(No subject)

Screen Shot 2016-10-05 at 12.47.54 PM.png

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Rodger Wilson
Robin, this stack trace may

Robin, this stack trace may be helpful in pinpointing the Bad Access in the SDK.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Log in to post comments